On Jul 9, 2010, at 7:39 AM, 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?
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.
I said it before on this thread, but it is apparently worth repeating;
if you have an idea you do not need our (core commiters) permission
for it. Get some people excited, write some code, see what happens. If
you write it nicely modularized chances are it can be released as a
plugin even if it is decided it is too [big, complex, specific, etc
etc] for core.
--Noah
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to trac-...@googlegroups.com.
To unsubscribe from this group, send email to
trac-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/trac-dev?hl=en.
