buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: Git forking for fun and profit
Date Thu, 01 May 2008 17:53:56 GMT
On Thu, May 1, 2008 at 9:05 AM, Martijn Dashorst <martijn.dashorst@gmail.com>
wrote:

> On 5/1/08, Matthieu Riou <matthieu@offthelip.org> wrote:
> >  > I'm not keen to restart the git discussion again. Using a DSCM is
> >  > according to a lot of folks within the foundation antithetical to the
> >  > Apache Way. There are others who claim that this Apache Way is based
> >  > too much on the svn workflow. In either case: git is not supported,
> >  > nor will it be anytime this decade for Apache development.
> >
> > Seems to me that you're generalizing the "we stick with SVN" opinion to
> >  "dSCM is always evil". Am I not free anymore to use whatever I want to
> >  develop on my machine?
>
> No, I summarized the discussion's two antagonist opinions: one states
> that dscm is antithetical to the Apache Way, the other states that the
> Apache Way is too constrained by Apache's use of svn (or cvs). Of
> course this doesn't do justice to all opinions voiced in the ~500
> messages that transpired in februari.
>
> You are free to use whatever you want, as long as the Apache related
> stuff works according the Apache Way (tm). According to many, the
> Apache Way is using a centralized repository, with all development
> happening in that repository, open to the public. They fear creating
> block commits, pulling in code without due process (i.e. CLA, SG, or
> JIRA donation) and a community that works the Linux way instead of the
> Apache way.
>

To which I reply: try it and see. It's always easy to fear what you don't
know.


>
> > I tend to agree with you. But sometimes being overly conservative leads
> to
> > sclerosis. There's a balance to find here.
>
> IMHO actively promoting forking is far from being overly conservative.
>

I never said we were trying to be conservative :)


>
> > Of course it's better if things happen in a single and strong community
> but if
> > someone wants to take buildr, extend it to support their own proprietary
> > repository structure and distribute it under whatever license they see
> fit,
> > then so be it.
>
> But buildr is still a podling, which means that there is still a lot
> of work to do before it is a strong community. Otherwise no argument
> here, this is why I like the ASL.
>
> > It's good for buildr and it's good for them.
>
> I don't think this is good for buildr that is trying to build a
> community that works the Apache way. How does forking the
> community/code base foster a meritocratic, open and diverse Buildr
> community at Apache?
>

I think there's a misunderstanding about the meaning of forking code here.
For example I have quite a bit of forks currently on my hard drive. It's
developments that I'm currently on. Eventually I'll commit them, bringing
them back to the central repository. In the meantime, I'm maintaining my
forks. That's what I mean by fork. Which is *very* different to a community
fork.

We're *absolutely not* talking about community fork here.


> Note that I don't consider git-svn to be evil, or want to prohibit it.
> I haven't worked with dscm's so I'm pretty neutral on this point. I do
> think that one should really be careful with promoting forking of code
> bases, especially when you are trying to build a community. I also
> consider the effect on buildr's graduation of a git based workflow. As
> a lot of folks have voiced their concerns regarding the use of dscm's
> within Apache, and those folks are also going to look at buildr's way
> of working in the Apache Way, taking it slow and low profile is my
> advise.
>

Low profile huh? If the incubator is about shutting up until graduation to
play nice with everybody, then what is the value we bring to podlings? What
does this have to do with building healthy communities? The Apache Way is
all about meritocracy, so let the Buildr developers show their merit before
judging them on their git-svn usage.

Cheers,
Matthieu


>
> Martijn
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message