My mails came out sort-of in the wrong order, and I'm not sure if I agree with myself on splitting it changes <-> core changes.
There is no technical mandate for this, not even a practical one since establishing mergeability from 2.2.1 -> 3.X turned out to be simple. But as a personal work habit it's smart, because it allows you to change your mind easily. Let's say I want to fix MNG-9999 on 3.X. I make an IT from a submitted sample project and I commit that on the 3.X branch. Now someone really wants that fixed back on 2.2.1, and it turns out the backport is real simple. All they need to do is cherry pick the IT and the core change back to 2.2.1. The IT always cherry-picks cleanly (more or less by definition due to the way we make IT's), but the core change does not, so the fix had to be re-applied on 2.2.1. When we merge 2.2.1 back to 3.X, git will automatically understand that the cherry-picked IT exists "in the future" and it won't trouble me with it. If the core change had been part of the IT commit I would lose this benefit, since the diffs become different (lol). (A diff that already exists in the history won't be reapplied, which is why it's so good to move *complete* commits backwards in time). Kristian 2012/10/12 Arnaud Héritier <aherit...@gmail.com> > "It may still be a good idea to do IT and core-change as two different > commits" > If we merge core and ITs I think it will be important to do it (and thus to > ask it to contributors - or we'll need to do it on our side). > I always see few reasons to merge them and find the process a little bit > complex (especially if the committer isn't a Git Guru) but I admit that I > won't bit impacted by this choice as my core contributions were (and will > probably continue to be) near to nothing. > Even if I really support the Git migration I don't want that we decrease > the ability to contribute (it is already a big issue) > > Arnaud > > On Fri, Oct 12, 2012 at 8:34 AM, Kristian Rosenvold < > kristian.rosenv...@gmail.com> wrote: > > > Btw; this simplifies the overall workflow to: "Check out the oldest > version > > you want to support this feature and add your IT + change there. It may > > still be a good idea to do IT and core-change as two different commits" > > > > Kristian > > > > > > 2012/10/12 Kristian Rosenvold <kristian.rosenv...@gmail.com> > > > > > I could not resist, I made this repo and it works well: git clone > > > https://github.com/krosenvold/maven-rc.git > > > > > > It has reconstructed mergeability between 2.2.1 and 3.X, and the IT's > > were > > > added at 2.2.1 and merged up to 3.X. Which means we have a straight > merge > > > based workflow from 2.2.1 and on. Pre 2.2.1 versions are not supported > > for > > > this mode of operation. > > > > > > Note: Older tags (pre. 2.2.0) will have to be reconstructed by hand > once > > > we flip. Also; the pom.xml and the site in this merged repo contain > only > > > the "core" pom (changes from core-its pom.xml and site will have to be > > > merged by hand) > > > > > > Btw: In this repo, you can checkout trunk (3.X and do "git diff > > ...2.2.X" > > > and see what changes have been added to 2.2.X. Note three ...'s) > > > > > > Kristian > > > > > > > > > 2012/10/12 Kristian Rosenvold <kristian.rosenv...@gmail.com> > > > > > >> NIce use case, this is where things get interesting ;) Initially I'll > > >> just add that this is one of those workflows that might be easier > with a > > >> separate IT repo. This is how the flow would be in a merged single > repo: > > >> > > >> This workflow has two distinct modes of operation: > > >> > > >> 1. You always check out the oldest appropriate branch to make the IT. > So > > >> if the IT should apply to 2.2.1 you should check that out. (If we need > > to > > >> make IT's that go even further back I think it might be easiest to > just > > >> keep the IT's in a separate repo since it gets really hard to actually > > >> *make* that repo.) > > >> > > >> 2 A) You are working in a "properly" branched structure that is > > mergeable > > >> ; i.e. what we might do between 3.0.X and 3.1 or maybe more > > appropriately > > >> between 3.X and 4.X. > > >> > > >> Make all the changes your heart desires, in any kind of commit > sequence > > >> you prefer. The downstream merge to the subsequent version will fix it > > all. > > >> > > >> 2 B) You are working i an unmergable branch structure (2.2.1->3.0) > > >> > > >> Add the IT as a distinct commit on the 2.2.1 branch, make sure any > > >> bug-fix you do is done as a separate commit from the IT. When done, > you > > >> will need to check out the 3.0.X branch and cherry pick the commit > with > > the > > >> IT. From 3.0.X on it will merge properly. cherry-picking is a manual > > >> operation and if you forget it, the IT will be "lost" on 2.2.1 > > >> > > >> While this all may seem a bit complex, it's basically the nuts & bolts > > of > > >> how day-to-day life of a branched workflow functions. When working in > > older > > >> history, it's usually wise to partition work into well-defined > commits, > > >> because sometimes you might end up cherry-picking only parts of the > work > > >> forward. When you're on trunk you usually don't need to worry about > this > > >> stuff. > > >> > > >> {begin Theoretical Technical digression for the git-savy} > > >> Theoretically we should be able to make a single "phoney" merge commit > > >> that re-establishes the mergeability between the 2.2.1 and 3.0.X > branch > > so > > >> that any subsequent changes we make to 2.2.1 can merge directly > > downstream. > > >> I have not done this in practice but I'm sure some others here have. > I'm > > >> thinking something like this: > > >> git checkout maven3.0.X > > >> git merge -s ours origin/maven-2.2.1 > > >> > > >> Now of course I want to test this out before we proceed > > >> {end Theoretical Technical digression for the git-savy} > > >> > > >> > > >> Kristian > > >> > > >> > > >> 2012/10/11 Jason van Zyl <ja...@tesla.io> > > >> > > >>> Say I have the following scenario: > > >>> > > >>> I'm working 3.1-S and creating some new ITs, and then I work on 2.2.x > > >>> and create some ITs. What's the plan with making sure that we have > one > > >>> cohesive set of ITs that we can use across all versions? Just merge > > >>> additions back into every branch? Because we would need to checkout > two > > >>> copies in order to be at one branch for the version of Maven you're > > working > > >>> on and the branch where the ITs are. I understand wanting a > > rationalized > > >>> fork and with unit tests I understand, but did you forks of large OSS > > >>> projects include ITs like this? > > >>> > > >>> If that workflow is sorted out it seems fine. I just don't want it to > > be > > >>> onerous to achieve the discipline of having on coherent set of tests > > that > > >>> work across all versions of Maven. It's pretty easy to make that > > consistent > > >>> right now. There's not a huge number of branches so merging additions > > back > > >>> to each branch is pretty easy. Is that what you had in mind? > > >>> > > >>> > > >>> On Oct 11, 2012, at 4:06 PM, Kristian Rosenvold < > > >>> kristian.rosenv...@gmail.com> wrote: > > >>> > > >>> > 2012/10/11 Arnaud Héritier <aherit...@gmail.com> > > >>> > > > >>> >> Now let's say that someone wants to solve a problem on a > maintenance > > >>> branch > > >>> >> (thus not master) > > >>> >> With git it will checkout this branch to work on the fix, but if > in > > >>> // he > > >>> >> wants to add an IT it will add it on this branch (not on master > > where > > >>> we > > >>> >> should have all ITs ?) > > >>> >> How many chance that one day we forgot to merge back ITs from all > > >>> branches > > >>> >> in master ? > > >>> >> > > >>> > > > >>> > If you make any kind of change on a branch > (bugfix/feature/whatever) > > I > > >>> > would > > >>> > expect to have test updates being done on that branch too, so the > > >>> branch > > >>> > represents a complete "diff" of the change; both feature and tests. > > >>> > > > >>> > When the fix/feature is merged back into master the tests come > along, > > >>> if > > >>> > the feature is > > >>> > never merged to master, the tests stay in their branch - just like > > they > > >>> > should. > > >>> > > > >>> > This is a healthy mode of operation; if you look at the branches in > > my > > >>> > surefire github repo > > >>> > (https://github.com/krosenvold/maven-surefire) I have like 15 > > >>> different > > >>> > branches. > > >>> > Some of them are specific JIRAs and may contain testcases and > partial > > >>> > fixes. Now I will > > >>> > start pushing these to the ASF git repo instead, since they > represent > > >>> work > > >>> > on an issue > > >>> > that is not fully fixed; maybe just a testcase or a test project. > > >>> > > > >>> > I think it's important we acknowledge the existence/intention of > such > > >>> > branches on > > >>> > the corresponding JIRA when we make such feature branches in the > > >>> official > > >>> > repo. > > >>> > If I just push it to my personal github repo it can be as messy as > I > > >>> > prefer, but when > > >>> > I push it to ASF I'd prefer it to have reasonably well-defined > > >>> > responsibility (like test-case, > > >>> > suggested fix or similar) and some value to others. If it's just my > > >>> > personal doodles I'll > > >>> > keep them in my personal github. > > >>> > > > >>> > As for branches that never get merged back; well that's life and > > >>> usually > > >>> > there's a story > > >>> > behind that and we tell it in jira. > > >>> > > > >>> > Kristian > > >>> > > >>> Thanks, > > >>> > > >>> Jason > > >>> > > >>> ---------------------------------------------------------- > > >>> Jason van Zyl > > >>> Founder & CTO, Sonatype > > >>> Founder, Apache Maven > > >>> http://twitter.com/jvanzyl > > >>> --------------------------------------------------------- > > >>> > > >>> In short, man creates for himself a new religion of a rational > > >>> and technical order to justify his work and to be justified in it. > > >>> > > >>> -- Jacques Ellul, The Technological Society > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >> > > > > > > > > > -- > ----- > Arnaud Héritier > 06-89-76-64-24 > http://aheritier.net > Mail/GTalk: aherit...@gmail.com > Twitter/Skype : aheritier >
