Modify

Opened 3 years ago

Closed 3 years ago

#9595 closed task (fixed)

Adoption request

Reported by: ChrisNelson Owned by: optilude
Priority: normal Component: TeamCalendarPlugin
Severity: normal Keywords: adoption
Cc: otaku42, rjollos Trac Release: 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?

Attachments (0)

Change History (12)

comment:1 follow-up: Changed 3 years ago by anonymous

Yes please :)

/optilude

comment:2 in reply to: ↑ 1 Changed 3 years ago by ChrisNelson

Replying to anonymous:

Yes please :)

/optilude

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: Changed 3 years ago by optilude

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.

Martin

comment:4 in reply to: ↑ 3 ; follow-up: Changed 3 years ago by hasienda

  • Cc otaku42 added; anonymous removed
  • Keywords adoption added

Replying to optilude:

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 3 years ago by ChrisNelson

Replying to hasienda:

Replying to optilude:

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: Changed 3 years ago by hasienda

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 3 years ago by ChrisNelson

Replying to hasienda:

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:8 Changed 3 years ago by rjollos

  • Cc rjollos added

comment:9 follow-up: Changed 3 years ago by hasienda

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: Changed 3 years ago by ChrisNelson

Replying to hasienda:

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 3 years ago by hasienda

Replying to ChrisNelson:

Replying to hasienda:

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 3 years ago by otaku42

  • Resolution set to fixed
  • Status changed from new to closed

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

Add Comment

Modify Ticket

Action
as closed The owner will remain optilude.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.