lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Krupansky" <>
Subject Re: Source Control
Date Sun, 28 Oct 2012 16:25:10 GMT
Can we put a notice on the github page that essentially says “ownership of any code committed
to this repo is implicitly transferred to ASF”?

-- Jack Krupansky

From: Mark Miller 
Sent: Sunday, October 28, 2012 12:01 PM
Subject: Re: Source Control

This has come up in discussion at the ASF. I think a couple people thought the check box was
critical. I think some higher level people said that is bs. The important part still comes
down to the committer committing code that has been properly contributed. You don't need a
checkbox for that, and it's no guarantee for that.

So I don't know the various workflows that have been worked out (a handful of projects are
already using git at apache), but I don't think the check box thing is a huge issue over the
long term.

Some projects are still attaching patches to JIRA for git though. Would have to investigate
to see how far any of these projects have evolved beyond that. Since we don't have something
like github to act as a pull request coordinator (that I know of), perhaps things are not
much better yet. But based on discussion I've seen, I think things could get better.

At the least, I know we get emails about pull requests from github already - and it's probably
easy to pull from their to an Apache git repo. You could probably avoid a patch pretty easily.
Just have to discover what the current rules are with the 'pilot' projects.

- Mark

On Oct 28, 2012, at 8:04 AM, Shai Erera <> wrote:

  What I wish we could do is to truly collaborate on these branches. For instance, when we
create a feature branch today (following an issue), then people are free to commit changes
to the branch, without worrying about breaking the main branch or nightly builds. When it's
time, the changes will be merged to the main branch. But what we lack today is true collaboration
-- allow all those involved to commit changes to the branch, thereby creating a healthier
collaboration atmosphere. When the main people involved are committers, this is not so felt,
but if the main people involved are non-committers, it's not so fun (to them mostly).

  Yet, I don't think that it can work otherwise, from the legal side. When people post patches
in JIRA, there's a little checkbox that they need to tick, granting the ASF rights for this
code. There's no checkbox to tick when changes are committed (well, since committers sign
an agreement with the ASF about code rights, there's like a virtual tiny checkbox that they
tick at commit time).

  So, and without me being a lawyer or anything (!), how would that work if we move to GIT?
If we don't allow other people to commit to "feature branches", because there might be code
licensing issues, what will be the advantage of moving to GIT?

  I'm asking because IMO if we cannot do that (let non-committers commit to feature branches),
there's no strong reason to move away from SVN. We all know it, feel comfortable with it,
and what's most important -- it does the job that we need.


  But throughout the development of a feature, it'd be great if we can let all those involved
to commit freely to the branch, without going through patches. Is that possible with our current
SVN setup (or can we modify it)? Is that 

  On Sun, Oct 28, 2012 at 1:24 PM, Michael Wechner <> wrote:

    Am 28.10.12 10:57, schrieb Robert Muir: 

      On Sun, Oct 28, 2012 at 2:59 AM, Michael Wechner
      <>  wrote:

        I also had/have quite some trouble to get used to the git commandline,
        although or maybe because I used SVN commandline for many years, but I am
        very glad now to be using git on other projects, because in particular the
        process in being able to do feature based branches with git helps so much,
        that I think it's definitely worth the price.

      There's no one on this planet that can convince me git is technically better.

    I am not talking about "technically better" (or maybe I misunderstand this term), but
    I am talking about "process". With git I can do the following:

    - Basically for every change (even in case it might just be a typo inside documentation)
I am creating a branch (which I can a "feature" branch)
    - I can share these branches easily with other people even if they don't have commit/push
access to the master branch and hence collaborate
    - I can merge branches easily and in particular merge the master branch into my feature
branches, and hence keep my feature branches in sync, which greatly simplies merging later
on into the master branch
    - I can commit stuff without having to be online, which is great when doing several steps
on the code, e.g.
         - Commit one: Formatting changes
         - Commit two: Functional changes
    - Because of the above I can use a RTC (ReviewThenCommit) process, because "others" can
commit to feature branches, where I can review the code changes and after successful review
commit/push to the master branch.

    With SVN I couldn't do this that easily and because it wasn't easy, I didn't do it. But
git allowed me/us to change the process and for me personally that is great.

    I think the question is what process do you want and what tool does make this process

    Maybe before argueing SVN versus git you should specify how you want to collaborate and
also specify requirements (as for example you point ou below about speed). Once you have a
clear picture about this, then consider the various tools which exist.



      I've used git on projects before. Its not that i have trouble getting
      used to it, its command line is genuinely horrible.

      And svn is absurdly fast for me:
      rmuir@beast:~/workspace$ time svn co
      real    0m23.454s
      user    0m5.712s
      sys     0m3.232s

      The speed of my internet connection makes git obselete.

      But if other people really like it, i won't stand in the way.

      To unsubscribe, e-mail:
      For additional commands, e-mail:

    To unsubscribe, e-mail:
    For additional commands, e-mail:

View raw message