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
To: dev@lucene.apache.org
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 <ser...@gmail.com> 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.
Shai
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 <michael.wech...@wyona.com>
wrote:
Am 28.10.12 10:57, schrieb Robert Muir:
On Sun, Oct 28, 2012 at 2:59 AM, Michael Wechner
<michael.wech...@wyona.com> 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 simple?
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.
HTH
Michael
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
https://svn.apache.org/repos/asf/lucene/dev/trunk
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
