Christopher Lenz wrote:
> Hey Christian,
>
Hello Chris,
Nice to see we had many points of convergence here, so I'll skip over
those and go straight to the parts that need a follow-up.
But before doing that, I would suggest that you could perhaps sum up the
position on which we mainly agreed, about the guidelines for what should
rather be done as a plugin and what should rather be contributed as a
patch to Trac proper. This would be an useful addition to the
TracDev/PluginDevelopment page for example, answering the "what"
question in addition to the "how", and you have more authority than I
have to speak on this topic.
> On 30.05.2008, at 11:00, Christian Boos wrote:
>
>> 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.
>
Well, it only explains why I didn't get any further. Also, the xref
branch should have focused on xrefs and relations should have been kept
separate, I guess.
>> 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.
>
We agree in principle. However with Trac, the problem space is kind of
big, and sometimes having a partial, less optimal solution, is better
than no solution at all. As for the design goals, I think I had them,
well exposed and documented, only they were not shared. As for the
quality standards in terms of API evolution, well, we can learn from the
mistakes of the past, can we? Some times ago, I even proposed a few
guidelines for 0.12 and beyond (see
http://groups.google.com/group/trac-dev/msg/4207c000d7c8be9c, more or
less what you're already doing for Genshi, adapted to the idea of
intermediate "reference points").
>> 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.
>
In accordance with what I've said in an earlier discussion on Trac-dev
about this topic, a few months ago. Please read
http://groups.google.com/group/trac-dev/msg/eabd326df35d3eaa
But linking from #31 to this thread was indeed for dramatic effect, as I
think that the Trac project presents a high risk of becoming misguided
by the repeated "write a plugin!" stance, and IMO a kind of "wake up"
call was necessary.
> 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).
>
Well, it is somewhat related. If you have read my numerous e-mails and
wiki pages on the topic, you'd know that I've always defended the idea
that a /rationalization/ of Trac core would not only enable us to have
more features but also to have a much leaner and simpler code base,
instead of N different data models, N different ways of solving the same
problem over and over again. So yes, those are the real reasons where we
differ on the longer term vision.
> Any disagreements on core vs plugin can really be sorted out on a case-
> by-case basis,
>
The problem is not really plugin or not plugin, it's rather about the
foundation on which the plugins should be based. For example, should a
ticket relation feature introduce its own special purpose tables or
should that be based on some higher-level relationship feature? The same
when a plugin wants to introduce some new kind of resource, does it have
to start from scratch or be able to reuse a default storage mechanism
and some base functionalities? I'm even OK to have lots of nice little
plugins (preferably in a kind of standard plugin library), as long as
they don't each re-invent the wheel for base services (and admittedly,
we probably differ in what we see as base service - for me it's anything
related to linking between resources and the ability to trace changes).
> 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."
>
The problem here is with the "minimalistic" approach. Does a
minimalistic approach really always "help developers to write great
software while staying out of the way"? Trac should indeed not impose
too much on a team's established development process and policies, but
it should help those teams to /improve/ their own process and policies.
As such, it has to offer efficient, rich and flexible ways to share and
work on the project-related information. And sometimes a minimalistic
approach can be at odds with this, if you have to fight your way in the
software instead of finding there the adequate support.
I must admit that I always thought that even if Trac's main strength was
in the integration of the base sub-systems (Wiki, BTS and VCS browser),
we should strive to make each of those sub-system a "best-of-breed" one.
Hence my tendency to expect the most of each of those sub-systems.
That's probably naive, sure, but well, this make things go forward ;-)
> 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.
>
Yes, exactly.
> 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.
>
Well, I've not suddenly become "hostile" to Trac and even if we diverge
on some major design issues, that doesn't mean there aren't a lot of
areas where we can keep working together, even after a fork. A change of
name will probably make cross-project sharing of changes a bit more
inconvenient than a simple branching, but not by much. And whenever
possible, I intend to backport fixes (well, actually make them first in
Trac, then propagate those to the other project, in the same spirit we
now fix bugs first in 0.11-stable before porting them to trunk/0.12). So
in the end, I don't think my intention to do a "fast-forward" by taking
an alternate path will be detrimental to the project, and we could
eventually always merge later on, in parts or in whole, if that makes sense.
I need multiple project support, multiple relationships from tickets to
versions and milestones, and have milestones, versions and components as
first-class resources, etc. etc.
I need that /now/, not after some hypothetical 1.0 release, not after an
even more hypothetical time when we would reach an agreement on the design.
Wrong, I actually needed that 2 years ago. So I only hope I'll be able
to catch up the time lost.
> 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.
>
Yes, I share that analysis, but I don't really see a way out,
unfortunately. I'll try to step out of the less technical discussions if
this can help, as I realize I'm not always the coolest tempered voice on
this mailing list.
-- 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
-~----------~----~----~----~------~----~------~--~---
