Hey Christian,
On 30.05.2008, at 11:00, Christian Boos wrote:
>> Using third-party plugin for such essential functionality looks
>> risky.
>> What about migration path and compatibility issues? There is no
>> guarantee
>> on the future compatibility of MasterTickets and Trac.
>> Besides, MasterTickets looks quite limited. Trac is great, I bet
>> you can
>> do better than that.
>>
>> I can't believe that Trac team avoided implementation of such
>> essential
>> feature for so long (this ticket is 4+ years old). I love Trac but
>> it's
>> unusable in large projects because of things like this. Sad.
>
> Nicely put, I can't agree more.
In principal I agree, too. But it should be noted that, while the
ticket is 4 years old, there's exactly ONE patch attached to it (two
if you count the xref branch). Why?
This is an open source project, none of the folks on the "core team"
get paid to work on features other people need. So for such hugely
popular feature requests, we really depend on the people who need the
features to step up and do some of the dirty work, or hire someone to
do it for them.
> Trac has a nice plugin system, and this has led some to think that
> every
> single feature can be implemented as a plugin. It's certainly possible
> from a technical point of view, but when the feature in question is a
> central one, or even more so, when the feature is actually more about
> fixing a (small) defective behavior (which I think is the case for
> this
> particular issue of "fields for missing dynamic vars", in a few mails
> above), creating a plugin for it is the wrong thing to do, IMO.
This I agree with 100%. Another example is ticket deletion and backing
out ticket changes. There's the TicketDelete plugin that kinda sorta
works for this, but it should have been integrated (in improved form)
into Trac proper ages ago.
> Installing a system which requires a dozen of plugins in order to
> function properly is cumbersome.
"Function properly" is of course highly subjective. Many people would
claim that time tracking and/or master/sub-tickets are required
features for an issue tracker to function properly. For many others,
those features would only get in the way. And as the Trac mantra has
always been to "stay out of your way", the *tendency* has been to keep
such features out of the core, but enable their implementation as
extensions.
If by "function properly" you mean that defects such as the one that
started this thread are fixed, then I absolutely agree.
> It simply doesn't give confidence in
> the system, and requires a good deal of expertise in knowing which
> plugins are really necessary and which should be avoided. So why would
> you ever take care to install a plugin for such a small defect like in
> this example, and face the associated risks? For the few people who
> would do it, you'll have thousands which will hit the problem in the
> "base" product and will just think it's not a well polished system
> (and
> they'll be right). I think the time spent in building such a plugin
> would have been better spent in writing a well-tested patch against
> the
> core product. The obvious advantage being that in later releases, no
> one
> will face the defective behavior again, and that the fix "melds" in,
> can
> be tested and verified against any other improvement to come. Also,
> more
> people get to know and work on the code, enabling its continuous
> improvement in quality. By doing it as a plugin, you're on your own
> and
> you build on a weak foundation instead of strengthening it. But of
> course you don't need to wait for someone to check in your patch, and
> you don't have to struggle with an unresponsive (if not hostile)
> development team, so it's the path of least resistance.
Agreed.
> I hope nobody gets me wrong: there's no questions that there are great
> Trac plugins out there, but those are rather adding new sub-systems,
> enabling connectivity with external systems or such things. But
> plugins
> which are addressing base functionality of existing subsystems or are
> merely there for fixing defects in Trac can rather be considered as
> "hacks". I never subscribed to this approach, but apparently I've been
> in the minority and I've given up to try to change this course of
> action.
Again, "base functionality" is subjective, agreed otherwise.
> Now to answer the question "why has the Trac team avoided
> implementation
> of such essential feature (#31) for 4 years", it's quite simple: the
> TracCrossReferences effort which was started (3 years ago) to address
> that issue, among other things, didn't get any "traction", quite to
> the
> contrary, so it ended up in a branch which I stopped maintaining
> after a
> while.
You make it sound like the xref approach was the only way to get
ticket dependencies into Trac. From my point of view, it was a very
broad design ("among other things") bordering on over-engineering.
There was never substantial opposition against implementing ticket
dependencies in a more straight-forward way. In fact, ticket #31 was
created by one of the original authors of Trac in the very early days.
I personally do think we should have ticket dependencies, and some
others have expressed the same opinion.
> People here at one hand are striving for "perfection", so any
> incremental approach is considered very suspiciously,
I don't understand how striving for perfection conflicts with
incremental development. Surely, a patchwork of incremental
enhancements and fixes done without a common vision or design is not a
good approach, and leads to an increasingly convoluted code base. I'm
all for the evolutionary development of software, but it needs to be
guided by design goals and quality standards in terms of API evolution.
> but on the other
> hand, as soon as it's outside of Trac, it's "free for all" and any
> kind
> of crude hack will do... No wonder some are answering "do it as a
> plugin!" to /every/ attempt to raise a discussion about improving the
> fundamentals of Trac itself, to the point there's almost no more
> development discussion on this list.
This I agree with. There are quite a number of things where we should
seriously consider whether they'd be better fixed/enhanced in Trac
proper rather than moved out into a "Trac Hack".
> Well, as you might have guessed by now, I've grown tired of this, and
> 0.11 will likely be my last Trac release, while I'm looking for ways
> to
> build an enhanced, more cohesive solution, in line with my ideas (this
> might succeed or not, but at least I won't have the feeling to bump
> into
> walls).
I find this part somewhat misleading.
By closing #31 and referencing this thread for dramatic effect or some
kind of PR stunt, you make it look like the Trac team does not
actually want to add ticket dependencies, but you do, so you want to
fork. The thing is, there has AFAIK never been consensus that Trac
should *not* have ticket dependencies in core. Noah suggested the
ticket *could* be closed with reference to MasterTickets, but he
didn't actually close it. You did.
While I suppose there's some level of conflict between your preference
to have more things in core, and the preference of some others to keep
the core lean and simple, this is IMHO far overshadowed by the
conflict over the long-term design (xref, GenericTrac, etc).
Any disagreements on core vs plugin can really be sorted out on a case-
by-case basis, as long as we can all agree on the basic mantra that
got Trac so popular in the first place. The following sentences have
been on the homepage of the Trac project pretty much since day one:
"Trac uses a minimalistic approach to web-based software project
management. Our mission is to help developers write great software
while staying out of the way. Trac should impose as little as possible
on a team's established development process and policies."
That mantra does *not* mean Trac should not have ticket dependencies,
or any other feature in particular. It just means that by default, we
want to avoid ending up with a system that is too complex for people
to use comfortably. And we certainly want to avoid imposing too much
process on software projects.
A conflict in the long-term goals or the design approach is much
harder to live with. At some point one side has to give in or give up.
You say you've reached the point where you want to give up and take
your ideas elsewhere.
Seeing how much work and time you've poured into the project in the
past years, that would certainly cause a very difficult time for Trac.
The developer community around the project is IMHO not in a
particulary good shape, with the other "veterans" like Jonas and
myself devoting less and less time to the project, and relatively few
new people coming on board to fill the void. And developer
communication could probably not get any worse than it is right now.
Some of this is probably the result of a lack of a shared vision among
the team and the resulting friction. Some of it may be due to the
project growing beyond our ability to keep up. Etc.
There's a lot more to say on all this, but this mail is already long
enough, so I'll shut up for now.
Cheers,
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
