incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Date Tue, 10 Jan 2012 03:02:43 GMT
On Jan 9, 2012, at 9:42 AM, Hyrum K Wright wrote:

> On Sat, Jan 7, 2012 at 4:10 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>> On Jan 7, 2012, at 1:49 PM, Greg Stein wrote:
>> 
>>> On Jan 7, 2012 4:24 PM, "Roy T. Fielding" <fielding@gbiv.com> wrote:
>>>> ...
>>>> The original developers are not ambivalent to this fork.
>>> 
>>> Untrue. Christian and Remy are, and always have been, supportive. They were
>>> the ones to suggest the fork, rather than trying to make the changes in
>>> trunk.
>> 
>> I read the trac-dev mailing list.  To say that they are supportive is a huge
>> stretch of the imagination.  They are sadly resigned to see a potential
>> contributor decide to fork the code instead of working with them directly.
>> And the rest of the community (which is far larger than the core) thinks
>> the idea stinks.
> 
> If you read trac-dev, you will also notice that the discussion about
> the so-called "fork" has more responses than all other threads in the
> last three months *combined*.  Lots of navel gazing, not much work.
> (Though surprisingly, discussion *has* picked up in the past couple of
> weeks, so maybe this is a Good Thing all around.)

Yes, that is a common side-effect of introducing a sense of awareness
to a project that is otherwise in stasis.  I have no doubt that Trac
needs new blood and a driving force capable of energizing the community
that developed on top of it.

>>> What you have is a vocal minority that disagree. Ethan is not even a core
>>> committer, as far as I can tell.

It isn't a vocal minority.  Not a single person outside of WANdisco
considered it a good idea.  Not one.  Yes, most of the people commenting
were the implementers of plug-ins, but they are also supposed to be
part of the Bloodhound proposal.

>>> 
>>> Edgewall, the copyright holder, is a defunct shell. That is a primary
>>> reason WANdisco wanted to move to the ASF: a home with actual backing and
>>> longevity.
>> 
>> Then we should be able to convince Christian and Remy to join the initial
>> committers list and bring the rest of the TRAC community with them.
>> Why has that not been done?
> 
> It has been.  They have essentially said "we've moved on, best of luck."

I don't follow that.  Is Edgewall still a formal organization capable
of owning copyright?  If not, who owns the copyright?  Have Christian
and Remy stopped all work on Trac, or are they just busy with their $jobs?

And, no, the discussion has not been with the Trac community -- it was
in private with a few individuals; as far as Apache is concerned,
it never happened.

Yes, there are many reasons to prefer that it is under the ASF.
Many, many, many reasons.  That doesn't change the fact that Apache
only accepts voluntary contributions.  Before you import code to
the ASF, you have to get some indication from the authors that
they either *want* us to maintain that code or that they have
completely abandoned it.  Not just a sigh and a statement that
the BSD license is forkable -- they have to want Apache to build
a community for maintaining that code.  Otherwise, we don't, for
social reasons that have little to do with licensing.

>>> WANdisco has definite problems in how they approach and work with open
>>> source communities. They discussed this stuff with the Trac principals
>>> privately, rather than with the broader community. But my read is that the
>>> Trac leads are supportive of Bloodhound.
>> 
>> They are supportive of people doing work on Trac.  They did not support a
>> fork at the ASF.  What they told WANdisco was that, rather than come to some
>> artificial agreement on how they should work together before WANdisco
>> had contributed anything, that WANdisco should fork the code and start by
>> making contributions.  That's it.  The only reason that Christian has not
>> directly opposed Bloodhound is because he believes the BSD license gives
>> permission to fork the code.
>> 
>>> My interest here is seeing Trac revitalized, improved, and delivered as an
>>> awesome open source issue tracker. I'm tired of Bugzilla and (non-OSS)
>>> Jira. I like the Google Code tracker, but I'm biased there :-P
>> 
>> There is no evidence to suggest that cannot be done on trac-dev.
> 
> I'm not sure I agree with this statement.  Trac has a singular and
> well-defined philosophy built around a small core and an environment
> of plugins.  This isn't the place to debate the merits of that
> architecture, but suffice it to say that such a system can often
> require a lot of work to get to a usable state.
> 
> The goals of Bloodhound are separate from that: create a full-featured
> issue tracker which is easy to deploy and use for end users and
> administrators both.  Honestly, Trac is a good product, and is an
> excellent choice as the core for Bloodhound, but the community goals
> differ.  Significantly.

Those sound like the goals for a commercial distribution of an
open source project.  In any case, there is no evidence that it
cannot be done on trac-dev because it wasn't attempted.

> Bloodhound won't happen on trac-dev because the Trac community is
> philosophically opposed to the direction the nascent Bloodhound
> community wants to take.  That's okay: people are allowed to have
> different goals.  And the great part about open source is we all don't
> have to reinvent the wheel to implement those different views of the
> world.  Bloodhound can be a derivative of Trac with its own community
> and goals [1].  There's room enough in the world for them both.

There is no Bloodhound community, Hyrum.  There is one company with
a few employees ready to start producing a unified distribution of
what is currently some other group's work product.  And I don't see
how you can say that the Trac community is philosophically opposed
to one direction or another when you haven't been discussing it in
public.

> I think the Trac community sees this as a zero-sum game: if people are
> contributing to Bloodhound, they *aren't* contributing to Trac.
> "Instead, we should try to convince the Bloodhound people that our
> philosophy is best, and they should just come over here."  Resolving
> such philosophical differences and technical goals is difficult at
> best, and I don't see it happening soon.  But that's okay, there isn't
> a globally optimal solution to issue tracking, and we can agree to
> experiment with different paths.

I would agree that, if there was some evidence of sustained contribution
in a direction that is being blocked by the existing Trac community,
then such a block would make for the basis of a community fork.  However,
that has not even been attempted yet, and we don't do those forks
at Apache.  If someone wants to fork a community here, they have to
start with only the code that they own or that has been deliberately
submitted to the ASF as contributions.

Just to be clear, if WANdisco had approached one of the ASF's projects
in the same way, suggesting significant changes in our decision-making
process before making any significant contributions of their own, we'd
tell them to piss off.  Actually, that would be the polite translation.
It is not a measure of the project's "activity" or "philosophy".
It is a measure of the respect we have for non-contributors who want
to tell us how to build software.

....Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message