buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Git forking for fun and profit
Date Thu, 01 May 2008 17:13:33 GMT
On Thu, May 1, 2008 at 9:22 AM, Martijn Dashorst <martijn.dashorst@gmail.com>
wrote:

> On 5/1/08, Assaf Arkin <arkin@intalio.com> wrote:
> > Absolutely, and that's why I recommend forking with Git.
>
> I'd rather folks *DON'T* fork, but supply patches through JIRA.
>
> >  It's possible to use Git responsibly for open development.  You can
> check
> >  the SVN commit log (we're all working with Git since a while), tell me
> if
> >  you think we're holding back on sharing with the community:
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-buildr-commits/200804.mbox/browser
>
> I see a lot of commits coming from two committers. I'm not a mentor,
> but I do subscribe to this list to see how buildr is evolving
> (possibly as a replacement for maven on projects). And I see very
> little discussion on the dev@ list when compared to the activity in
> the repository.


The last set of commits are for a) the release process, which was discussed
at length on -dev, and was refactored based on that decision, and b) change
in the way we handle artifacts, because we got requests (mailing list and
JIRA) to support versioning of extensions.



>
> Perhaps it is too soon to call, but how does git promote discussion
> between developers on the dev list?


Git allows anyone, not just a committer, to work on something, bring it up
for discussion and show us the code.  I can quickly check it out, maybe send
them a patch or two.

Outside of Apache, in communities that already made the switch to Git, you
can see that in action.  Instead of patches coming out of left field,
usually handled by one committer before inclusion, you get e-mails from
people working on something and pointing you to their repository.  And you
get a lot more people involved in making that patch happen.

You can literally see the SVN isolation walls crashing down.



>
> >  What about non-committers?  They can only check code out of SVN, but
> they
> >  can't do development in the open because there's no way to share what
> >  they're working on.  It's all tucked away in some SVN working directory
> on
> >  their computer.
>
> Patches. This is the best way to track new committers. It provides the
> best way to track the provenance of the code. Attach patch to JIRA
> issue, check the box and you can incorporate the code into buildr.
> There is no other way, except by making people committers. And you do
> that by getting tired of committing their patches.


"No other way" is the problem we're trying to solve.  Everyone gets the same
power, and responsibility, we committers have to make a big change out in
the open, with the participation of others.

Assaf


>
>
> Martijn
>

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