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
