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 > >
