Opened 6 years ago

Closed 6 years ago

Reported by: Owned by: Chris Nelson Martin Aspeli normal TeamCalendarPlugin normal adoption Michael Renzmann, Ryan J Ollos 0.11

### Description

This plugin seems to be idle. It relates to my project management work and I'd consider adopting it. Is that OK?

### comment:2 in reply to:  1 Changed 6 years ago by Chris Nelson

I'm not sure how to proceed. Do you give me ownership or does someone with more TH permission have to transfer it or?

(BTW, your agreement was anonymous; it might carry more weight if you logged in before replying again.)

### comment:3 follow-up:  4 Changed 6 years ago by Martin Aspeli

I don't know if I can do anything from here, but I've logged in now at least.

Please take it over - I don't use Trac anymore, unfortunately.

### comment:4 in reply to:  3 ; follow-up:  5 Changed 6 years ago by Steffen Hoffmann

I don't know if I can do anything from here, but I've logged in now at least.

No, normally a plugin author/maintainer can't. Cc-ing the site admin is best practice here. He's busy, but generally very responsive at least to requests for adoption or extra permissions, if current maintainer agrees. This is obviously the case.

Please take it over - I don't use Trac anymore, unfortunately.

Wait for reaction of Michael. Btw, proposed procedure and additional supportive actions like posting to th-users mailing-list are already documented for AdoptingHacks.

### comment:5 in reply to:  4 Changed 6 years ago by Chris Nelson

I don't know if I can do anything from here, but I've logged in now at least.

No, normally a plugin author/maintainer can't. Cc-ing the site admin is best practice here. He's busy, but generally very responsive at least to requests for adoption or extra permissions, if current maintainer agrees. This is obviously the case. ...

No particular hurry. I won't have anything worth pushing for weeks.

### comment:6 follow-up:  7 Changed 6 years ago by Steffen Hoffmann

OT: I've just checked the source out of curiosity.

I'd like to see a working example (screenshot?), but in it's current state I can't and won't test this plugin, just because I use the SQLite Trac db backend exclusively here. As a matter of fact the db access code is a MySQL-proprietary mess.

Please make sure to change db schema description and any SQL statement in general to adhere to Trac standards. Nudge me, if you need pointers and further help.

### comment:7 in reply to:  6 Changed 6 years ago by Chris Nelson

OT: I've just checked the source out of curiosity.

I'd like to see a working example (screenshot?), but in it's current state I can't and won't test this plugin, just because I use the SQLite Trac db backend exclusively here. As a matter of fact the db access code is a MySQL-proprietary mess.

Please make sure to change db schema description and any SQL statement in general to adhere to Trac standards. Nudge me, if you need pointers and further help.

I previously put up a patch to let it work with PostgreSQL. I don't know that that makes it work across the board. I don't know the Trac DB API well but I'm working on it. One change I'm considering is storing the dates as seconds, not DB dates, which I understand is the Trac idiom.

### comment:9 follow-up:  10 Changed 6 years ago by Steffen Hoffmann

IMHO Trac has a fine db abstraction. Anything more complicated than very basic WHERE clauses has some wrapper methods to hide db-specific SQL. See t:wiki:TracDev/DatabaseApi for the current state, but beware to stick to the old style as long as backwards-compatibility down to trac-0.11 matters.

### comment:10 in reply to:  9 ; follow-up:  11 Changed 6 years ago by Chris Nelson

IMHO Trac has a fine db abstraction. Anything more complicated than very basic WHERE clauses has some wrapper methods to hide db-specific SQL. See t:wiki:TracDev/DatabaseApi for the current state, but beware to stick to the old style as long as backwards-compatibility down to trac-0.11 matters.

(This may not be the place for this discussion but...)

That's less extensive than I hoped. I hoped I was missing something. My problem is one RDBMS wants single quotes and another wants double so if I do:

cursor.execute("SELECT * FROM myTable WHERE foo='bar'")


It will only work in one of them. Or maybe I'm superstitious because I've gotten burned on weird quoting issues in SQL.

### comment:11 in reply to:  10 Changed 6 years ago by Steffen Hoffmann

IMHO Trac has a fine db abstraction. ...

(This may not be the place for this discussion but...)

Agree, so I suggest to move into another ticket dedicated to db issues like #7115, where I placed my reply to this comment.

### comment:12 Changed 6 years ago by Michael Renzmann

Resolution: → fixed new → closed

@ChrisNelson: plugin maintainership passed over to you now. Please follow the procedure described here to complete the change.

### Modify Ticket

Change Properties