"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 < [email protected]> 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 <[email protected]> > > > 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 <[email protected]> > > > >> 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 <[email protected]> > >> > >>> 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 < > >>> [email protected]> wrote: > >>> > >>> > 2012/10/11 Arnaud Héritier <[email protected]> > >>> > > >>> >> 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: [email protected] Twitter/Skype : aheritier
