I plan to propose the following in the vote thread. Please advise on more details to be added and/or concerns you have so we avoid the overhead of doing this in the vote thread.
1. Migrate from subversion to git for version control 2. Force-push to be disabled on trunk and branch-* branches. Applying changes from any of trunk/branch-* to any of branch-* should be through "git cherry-pick -x". 3. Force-push on feature-branches is allowed. Before pulling in a feature, the feature-branch should be rebased on latest trunk and the changes applied to trunk through "git rebase --onto" or "git cherry-pick <commit-range>". 4. The use of tags stay the same after the migration. On Tue, Aug 5, 2014 at 11:41 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: > By "merge-based workflow", this is referring to branch development and > merging? I don't see much issue with allowing a rebase-based workflow if > we're okay with allowing force-push on feature branches. If anything, the > next step would be disallowing merge-based workflows and mandating rebases > for a clean linear history, but it sounds like we'd rather not for now. > > Also, to state the obvious, for trunk->branch-2->etc backports, I'd expect > us to be doing git cherry-picks. > > I think it'd be good to disable force-push for the main branches as Arpit > recommends, we could include that in the VOTE as well. > > Thanks, > Andrew > > > On Tue, Aug 5, 2014 at 9:27 PM, Arpit Agarwal <aagar...@hortonworks.com> > wrote: > > > If by very same workflow you mean a merge-based workflow that would be > fine > > to call out in the vote proposal. > > > > Separately, do we want to disable force push for version branches > > (branch-x) and point release branches (branch-x.y) in addition to trunk? > > > > > > On Tue, Aug 5, 2014 at 8:18 PM, Alejandro Abdelnur <tuc...@gmail.com> > > wrote: > > > > > I would say we can first move to git and keep the very same workflow we > > > have today, then we can evolve it. > > > > > > > > > On Tue, Aug 5, 2014 at 6:46 PM, Arpit Agarwal < > aagar...@hortonworks.com> > > > wrote: > > > > > > > +1 to voting on specific workflow(s). > > > > > > > > > > > > On Tue, Aug 5, 2014 at 5:49 PM, Karthik Kambatla <ka...@cloudera.com > > > > > > wrote: > > > > > > > > > If we are to start a vote thread, will people prefer a vote thread > > that > > > > > includes potential workflows as well? > > > > > > > > > > > > > > > On Tue, Aug 5, 2014 at 5:40 PM, Karthik Kambatla < > ka...@cloudera.com > > > > > > > > wrote: > > > > > > > > > > > Thanks for your opinions, everyone. Looks like most people are > for > > > the > > > > > > change and no one is against it. Let me start a vote for this. > > > > > > > > > > > > > > > > > > On Mon, Aug 4, 2014 at 4:44 PM, Tsuyoshi OZAWA < > > > > ozawa.tsuyo...@gmail.com > > > > > > > > > > > > wrote: > > > > > > > > > > > >> Thank you for supplementation, Andrew. Yes, we should go step by > > > step > > > > > >> and let's discuss review workflows on a another thread. > > > > > >> > > > > > >> Thanks, > > > > > >> - Tsuyoshi > > > > > >> > > > > > >> On Tue, Aug 5, 2014 at 8:23 AM, Andrew Wang < > > > andrew.w...@cloudera.com > > > > > > > > > > >> wrote: > > > > > >> > I think we should take things one step at a time. Switching to > > git > > > > > >> > definitely opens up the possibility for better review > workflows, > > > but > > > > > we > > > > > >> can > > > > > >> > discuss that on a different thread. > > > > > >> > > > > > > >> > A few different people have also mentioned Gerrit, so that'd > be > > in > > > > the > > > > > >> > running along with Github (and I guess ReviewBoard). > > > > > >> > > > > > > >> > Thanks, > > > > > >> > Andrew > > > > > >> > > > > > > >> > > > > > > >> > On Mon, Aug 4, 2014 at 4:17 PM, Tsuyoshi OZAWA < > > > > > >> ozawa.tsuyo...@gmail.com> > > > > > >> > wrote: > > > > > >> > > > > > > >> >> Thank you for great suggestion, Karthik. +1(non-binding) to > use > > > > git. > > > > > >> >> I'm also using private git repository. > > > > > >> >> Additionally, I have one question. Will we accept > github-based > > > > > >> >> development like Apache Spark? IHMO, it allow us to leverage > > > Hadoop > > > > > >> >> development, because the cost of sending pull request is very > > low > > > > and > > > > > >> >> its review board is great. One concern is that the > development > > > > > >> >> workflow can change and it can confuse us. What do you think? > > > > > >> >> > > > > > >> >> Thanks, > > > > > >> >> - Tsuyoshi > > > > > >> >> > > > > > >> >> On Sat, Aug 2, 2014 at 8:43 AM, Karthik Kambatla < > > > > ka...@cloudera.com > > > > > > > > > > > >> >> wrote: > > > > > >> >> > Hi folks, > > > > > >> >> > > > > > > >> >> > From what I hear, a lot of devs use the git mirror for > > > > > >> >> development/reviews > > > > > >> >> > and use subversion primarily for checking code in. I was > > > > wondering > > > > > >> if it > > > > > >> >> > would make more sense just to move to git. In addition to > > > > > subjective > > > > > >> >> liking > > > > > >> >> > of git, I see the following advantages in our workflow: > > > > > >> >> > > > > > > >> >> > 1. Feature branches - it becomes easier to work on them > > and > > > > keep > > > > > >> >> > rebasing against the latest trunk. > > > > > >> >> > 2. Cherry-picks between branches automatically ensures > the > > > > exact > > > > > >> same > > > > > >> >> > commit message and tracks the lineage as well. > > > > > >> >> > 3. When cutting new branches and/or updating maven > > versions > > > > > etc., > > > > > >> it > > > > > >> >> > allows doing all the work locally before pushing it to > the > > > > main > > > > > >> >> branch. > > > > > >> >> > 4. Opens us up to potentially using other code-review > > tools. > > > > > >> (Gerrit?) > > > > > >> >> > 5. It is just more convenient. > > > > > >> >> > > > > > > >> >> > I am sure this was brought up before in different > > capacities. I > > > > > >> believe > > > > > >> >> the > > > > > >> >> > support for git in ASF is healthy now and several > downstream > > > > > projects > > > > > >> >> have > > > > > >> >> > moved. Again, from what I hear, ASF INFRA folks make the > > > > migration > > > > > >> >> process > > > > > >> >> > fairly easy. > > > > > >> >> > > > > > > >> >> > What do you all think? > > > > > >> >> > > > > > > >> >> > Thanks > > > > > >> >> > Karthik > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> -- > > > > > >> >> - Tsuyoshi > > > > > >> >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> -- > > > > > >> - Tsuyoshi > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > CONFIDENTIALITY NOTICE > > > > NOTICE: This message is intended for the use of the individual or > > entity > > > to > > > > which it is addressed and may contain information that is > confidential, > > > > privileged and exempt from disclosure under applicable law. If the > > reader > > > > of this message is not the intended recipient, you are hereby > notified > > > that > > > > any printing, copying, dissemination, distribution, disclosure or > > > > forwarding of this communication is strictly prohibited. If you have > > > > received this communication in error, please contact the sender > > > immediately > > > > and delete it from your system. Thank You. > > > > > > > > > > > -- > > CONFIDENTIALITY NOTICE > > NOTICE: This message is intended for the use of the individual or entity > to > > which it is addressed and may contain information that is confidential, > > privileged and exempt from disclosure under applicable law. If the reader > > of this message is not the intended recipient, you are hereby notified > that > > any printing, copying, dissemination, distribution, disclosure or > > forwarding of this communication is strictly prohibited. If you have > > received this communication in error, please contact the sender > immediately > > and delete it from your system. Thank You. > > >
