Ticket #9595 (closed task: fixed)

Opened 1 year ago

Last modified 1 year ago

Adoption request

Reported by: ChrisNelson Assigned to: 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

Change History

(follow-up: ↓ 2 ) 12/09/11 17:59:28 changed by anonymous

Yes please :)

/optilude

(in reply to: ↑ 1 ) 12/09/11 19:44:21 changed 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.)

(follow-up: ↓ 4 ) 12/09/11 21:49:15 changed 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

(in reply to: ↑ 3 ; follow-up: ↓ 5 ) 12/10/11 00:12:46 changed by hasienda

  • cc set to otaku42.
  • keywords set to adoption.

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.

(in reply to: ↑ 4 ) 12/12/11 14:02:17 changed 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.

(follow-up: ↓ 7 ) 12/13/11 01:51:36 changed 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.

(in reply to: ↑ 6 ) 12/13/11 13:21:10 changed 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.

12/14/11 03:17:36 changed by rjollos

  • cc changed from otaku42 to otaku42, rjollos.

(follow-up: ↓ 10 ) 12/14/11 23:08:26 changed 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.

(in reply to: ↑ 9 ; follow-up: ↓ 11 ) 12/15/11 22:13:41 changed 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.

(in reply to: ↑ 10 ) 12/16/11 00:06:14 changed 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.

12/29/11 08:51:28 changed by otaku42

  • status changed from new to closed.
  • resolution set to fixed.

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

Add/Change #9595 (Adoption request)




Change Properties
Action