Given the general amount of attention that the community gives core changes, I think there is little reason to fear uncontrolled IT changes.
Simply put; my fear of IT's *not* getting updated/maintained far exceeds my fear of an erronous update creeping in (which is why in surefire the IT's run by default with no option to turn them off other than -DskipTests ;) It seems to me we've covered all the important bases on this one; I'll summarize breiefly in a separate mail. Kristian 2012/10/12 Igor Fedorenko <i...@ifedorenko.com> > Although I understand we can make the merged repository work, at least > with some discipline from developers, I think merged source repository > makes changes to the integration tests perceptually "okay", which imho > is rarely the case. I actually maintained fork of maven ITs for > awhile, and personally I did not find it too much trouble. At least as > long as I was only adding new ITs, not changing existing ones. > > Just my 2c. > > -- > Regards, > Igor > > > On 12-10-12 3:47 AM, Kristian Rosenvold wrote: > >> 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<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<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 >>> >>> >> > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org> > For additional commands, e-mail: dev-h...@maven.apache.org > >
