Hello
Simon, I hope you won't mind me quoting only the last bit of your mail,
it contains many other interesting points and I'll probably have a
second answer to elaborate on other aspects of it, but I'd like to first
clear a misconception that I've found in the last paragraph of your mail.
On 12/25/2011 4:14 AM, osimons wrote:
I really wish the efforts were joined at the hip for now, and I'd have
no reason to feel uncertain about a fork if there were months of
preceding argument about project direction here at trac-dev. I would
be blatantly obvious that a fork was needed, costing what it may.
However, it is my firm belief that a software fork born out of
critical discussion between people that disagree, will be of much
better quality than a fork largely built by consensus in the offices
of a corporate sponsor.
That's not exactly how it happened. Rather, "we" (cboos, rblank, jonas)
suggested the fork as the best way to get things moving forward for
WANdisco. Back in April (2011), they were talking about committing one
or two full-time developers to Trac, and as Remy and me got less an less
time for the project (as everyone could see), we were simply afraid that
our limited capacity of reviewing would be a bottleneck for them. Ok,
considering the very limited amount of contributions they produced so
far, our fears may now seem exaggerated ;-) Anyway, this could still
happen, as they're possibly still into an exploratory phase where
nothing from their side is yet public, so the model still holds: from
our point of view, their fork is potentially just an "external branch"
where they can evolve at their own speed and that we will try to review
at our pace and reintegrate whenever it makes sense. So why an external
branch, and not just a "sandbox" branch, you may ask? This indeed has to
do with politics and David Richards from WANdisco made it quite clear
early on that he was a bit concerned with the somewhat fuzzy status of
Edgewall and that he was much more comfortable sponsoring work under the
umbrella of Apache (so mostly for trademarks and IP concerns, IIUC).
From our side, we felt more comfortable to stick with the informal
Edgewall ways rather than switching to the more bureaucratic Apache
ways. Redoing the work on the infrastructure was not something
especially appealing either, given that after years of patient work we
finally reached a quite satisfying state. And again, before deciding a
move, we wanted to be sure it would be worth it and for that we needed
to "see" something happen.
So the way Ian explained what happened was indeed quite accurate:
On Dec 2, 1:41 pm, Ian Wild <ian.w...@wandisco.com> wrote:
As some of you may already be aware, earlier this year WANdisco[1]
approached members of the Trac development community with a view to working
out how we could most effectively invest development time into the project.
...
The resulting discussions were interesting and culminated in the idea that
we might get the most done in the shortest time by performing a 'friendly
fork' of Trac and running that as a separate FOSS project. It was felt this
would present the least risk for everyone involved while still leaving
options open for future collaboration.
However we didn't say they should start with incubating an Apache
project. That was their call, and at this level I somehow share the
concerns about the risks of possible fragmentation of the community.
Starting with a new project like that may send the signal that they're
taking the Trac code base as it stands today and taking it somewhere
else (where? "as the community says"; but as there's not yet a community
for Bloodhound, there seem to be a bootstrapping issue there ;-) ).
Also there seem to be some discrepancy between the following reassuring
statements from Ian:
I want to be clear that our intention is in no way to undermine the current
Trac project and the progress that is making. We hope there can be
mutual collaboration and a shared journey. This approach gives us both the
freedom to continue with our own strategies while allowing us all to stay
engaged with each other and to achieve what I'm sure all of us desire - To
make Trac the best defect tracker on the planet.
and the wording of the Bloodhound proposal, which rather indicate a
"take over" approach:
- in the "Rationale" [1]:
>>> the current Trac development community is small and reluctant to
accept outside contributions.
Opinions here could diverge, but IMHO that's blatantly wrong. As any
project we're reluctant to accept marginally useful features or
unfinished code, but there's no shortage of good patches and good
contributions from non-committers which have been integrated. Not to
mention this is a bit strong of a statement coming from a party which so
far proposed no code contributions.
And by the way, committer status on Edgewall is usually granted after
seeing enough actual good patches from the contributor and a
demonstrated interest to the project, not when someone says "hey, this
project looks remotely interesting to me, I have no idea if I can or
will contribute but count me in" (slight caricature of an actual
self-appointment as a Bloodhound committer, recently seen in
gene...@incubator.apache.org - any parallel with sOme Other Apache
incubator project would certainly be seen as a stretch ;-) ).
>>> Given the Foundation’s reputation for building and maintaining
communities, we feel a new project, based on Trac but incubated under
the Apache umbrella, would help re-build the developer community, jump
started by developer time donated by WANdisco
"Re-build the developer community" rather than participate, expand or
similar...
- in the "Community" [2]:
>>> The current developers and supporting institution have moved on to
other things, and this has caused stagnation in the existing community.
Grr... we're not yet dead, and... we'll be back! :-)
I think we could continue at length to discuss how things could or
should work out, but from my side I'll take a very pragmatic approach:
if I see good stuff on the Bloodhound side, I'll probably propose to
take it back in t.e.o; if there are simply too many good things coming
from their side, we will probably regularly integrate their code
wholesale or possibly even "join" Bloodhound at some point in the
future; if there's only little activity or things that we don't like, we
will just continue our business as usual...
Nothing that dramatic, there are much bigger issues to tackle, like the
fact that the Trac model is progressively being dragged into the margin
by the advent of the likes of Github, Bitbucket and other Google Code...
-- Christian
[1]
http://wiki.apache.org/incubator/BloodhoundProposal?action=recall&rev=7#Rationale
[2]
http://wiki.apache.org/incubator/BloodhoundProposal?action=recall&rev=7#Community
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To post to this group, send email to trac-dev@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.
