On 7/9/2010 4:39 PM, Carsten Klein wrote:
Am 06.07.2010 21:55, schrieb Remy Blank:
One thing that hold me back of doing that with the ticket system so far
was that I had the impression that my patches would be rejected anyway
as core trac does not *want* to go in this direction.
As Noah said, we're living in an economy of time. I'm willing to spend
some time to implement something incrementally and for some core ticket
parts I pretty much know how this could be done as I've already done that.
However I need at least the commitment that a functionality will be
included into trac core provided that it meets trac's architecture and
the quality standards. I can't risk spending a lot of time (a week of
free time is a lot for me currently) when the feature can not go into
trac anyway.
Putting up Felix's statement, that one cannot be sure of integration of a
proposal being made.
How about moving the trac development process further along the road by
having something like for example PEPs, e.g. TEP?
We already have TracDev/Proposals/... and the mailing list. The former
is more for long term development of an idea, the latter is more for
short term discussions, presenting the idea, gathering initial feedback
or additional feedback after an evolution of the proposal. If the
discussion is not summarized in one form or another into a wiki page,
chances are that the same discussion will be restarted a few months /
years later, with the same arguments ;-)
In addition, one could initiate a TEP by first proposing an idea, and if
that idea takes off (voting), one could propose a solution for that TEP
that is then to be integrated into trac based on code review etc.
That's more or less how the bigger proposals work.
Also, there is nearly always a ticket where the idea was initially
discussed.
A discussion taking place inside an "enhancement" ticket can lead to:
- "resolution -> wontfix"; the proposal is rejected, either because
it's deemed to be a bad idea, or because it's perceived as better
implemented as a plugin, or various other reasons
- "milestone -> unscheduled"; the proposal is not rejected but the
core team is not really convinced about the correctness of the approach
and don't feel like implementing the feature themselves, so it'll be
eventually done when someone proposes a concrete solution in terms of
code. If the code is convincing (read
http://trac.edgewall.org/wiki/PatchWelcome), it can then receive
approval. See the process of providing the code as a "proof of concept"
and a second chance to raise interest on the topic (as in: "I told you
so!").
- "milestone -> next-major-0.1X"; the proposal is accepted, deemed to
be a good idea, a wanted feature, something that we should keep in mind
when we work on other things, as everything is interrelated. There can
eventually be no code at this stage, the difference with the
"unscheduled" above is that here the developers see how well it fits in
the bigger scheme, have an idea about the implementation, and feel like
coding it themselves, time permitting
- "milestone -> 0.1X" (the current milestone); the proposal is an
obvious improvement, the code is ready, looks good, and remains to be
reviewed or applied, or there's a strong commitment from the developers
to work on this feature for the next release
Of course, during its lifetime, the status of a ticket can move in
direction or another.
In any of the last three possibility, depending on the amount of work
required, different things can happen:
- small feature: a patch or even a hint of what needs to be done is
enough; the ticket is self-sufficient
- medium feature: once several patches accumulate and several
iterations of the patches are needed, it's often a good idea to
summarize the work in a branch. We had plenty of temporary ^/sandbox
branches for that purpose in the past, now with the git and hg mirrors,
anyone can fork and create her own branch for exposing a feature
- big feature: a branch is almost mandatory to keep track of all the
needed intermediate changes without disturbing the trunk (trunk *must*
always be production quality). We usually also have a wiki page giving
the overview of the work being done and the work remaining to be done
(e.g. MultiRepositorySupport). That page is eventually backed by some
more "in-depth" wiki page(s) where the idea was first elaborated
(usually the TracDev/Proposals/... pages). If the feature is really big
and involves lots of secondary tasks, if the branch gets eventually used
by people in production and bugs are reported against it, we can even
create a dedicated milestone (e.g. milestone:0.12-multirepos)
This can also eventually start directly by a TracDev/Proposals page, if
there's no ticket representative of the approach as a whole (e.g.
TracDev/Proposals/Announcer).
-- Christian
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
