MasterTickets tickets

1 view
Skip to first unread message

Noah Kantrowitz

unread,
Feb 25, 2008, 11:00:08 AM2/25/08
to trac...@googlegroups.com
Are there objections to closing #31 and #886? MasterTickets implements
the feature fairly well I think, and its big enough that I'm not yet in
favor of core inclusion.

--Noah

signature.asc

Emmanuel Blot

unread,
Feb 25, 2008, 11:36:12 AM2/25/08
to trac...@googlegroups.com
+0 : I'm ok with the out-of-core implementation, but I think the
related discussion about "official" vs. "unofficial" plugins must be
discussed first and a decision should be made.

For a plugin as important as this one ("important" in terms of how
many users need/use it - I don't), the Trac project should guarantee
somehow that the MasterTicket plugin will be updated and maintained,
especially when some Trac API is broken.

I'd favor moving "official" plugins back to t.e.o. so they have a
status close to the WebAdmin plugin - before it got merged to the core
- and they can be closely managed through a dedicated Trac ticket
component, along with Trac Core.

From my perspective, there are at least 3 majors plugins out there:
AccountManager, MasterTicket and XmlRpc.
XmlRpc plugin has been broken or half-working for most of the 0.11
development cycle, and this should not happen again (and again) for
0.12.

To sum up: let's take a statement about "official" plugins before
closing those ones.

Cheers,
Manu

--
Manu

Noah Kantrowitz

unread,
Feb 25, 2008, 11:57:41 AM2/25/08
to trac...@googlegroups.com
Emmanuel Blot wrote:
> +0 : I'm ok with the out-of-core implementation, but I think the
> related discussion about "official" vs. "unofficial" plugins must be
> discussed first and a decision should be made.
>
> For a plugin as important as this one ("important" in terms of how
> many users need/use it - I don't), the Trac project should guarantee
> somehow that the MasterTicket plugin will be updated and maintained,
> especially when some Trac API is broken.
>
> I'd favor moving "official" plugins back to t.e.o. so they have a
> status close to the WebAdmin plugin - before it got merged to the core
> - and they can be closely managed through a dedicated Trac ticket
> component, along with Trac Core.
>
> From my perspective, there are at least 3 majors plugins out there:
> AccountManager, MasterTicket and XmlRpc.
> XmlRpc plugin has been broken or half-working for most of the 0.11
> development cycle, and this should not happen again (and again) for
> 0.12.

I've been forced to concede on the XmlRpc front (as my plans for the
ninja branch will require effectively exposing the ticket API over
JSON-RPC). I would also add IniAdmin to that list, as I think a lot of
people expect total web admin stuffs.

> To sum up: let's take a statement about "official" plugins before
> closing those ones.

Fair enough. If its just an issue of PR, I don't care where the code sits.

--Noah

signature.asc

Christian Boos

unread,
Feb 25, 2008, 12:31:29 PM2/25/08
to trac...@googlegroups.com

I'd be OK for #31, but certainly not for #886.

#886 / SubTickets is more about having a way to compose hierarchical
groups of tickets and show the progress on them, in a more flexible way
than just the 2-level hierarchy of Milestones and Tickets. AFAICT, by
looking at the plugin code, there's no such thing there, only
blocking/blocked by relationships, which indeed correspond to a simple
form of #31.

For #31, I'm somewhat reluctant to close a ticket discussing a major
feature by a "wontfix / use a plugin instead" statement. But on the
other hand, there are so many open tickets in Trac that this is probably
the best we can do at this point. So +1 from me for closing that ticket
and advising to use MasterTickets plugin (but this is more of a trust
thing than anything else, as I haven't yet tested the plugin myself).

-- Christian

Reply all
Reply to author
Forward
0 new messages