Typically, if someone wants to run cluster tests against a release, this is done before the RC vote is called due to the obvious time constraints of running a three day test in the span of a three day vote.
You still should have time to run each other test if you so choose. But again, I don't think people typically run tests outside of the unit and functional ones besides the vote caller. I could be mistaken though. On Feb 5, 2014 8:20 AM, "Sean Busbey" <[email protected]> wrote: > One thing I've just realized, the 72 hour window on an RC doesn't give me > enough time to run the full release test suite myself. It seems like that's > going to limit the variety of cluster results we can get included for a > release. > > > -Sean > > On Tue, Feb 4, 2014 at 10:50 PM, Josh Elser <[email protected]> wrote: > > > Some extra notes that I ran into with not working against > > maven-release-plugin. > > > > The plugin will prompt for the release version, the tag name, and the > next > > development version. For 1.5.1, we really want to give 1.5.1, 1.5.1-rcN, > > 1.5.2-SNAPSHOT. However, this will result in 1.5.1-rcN being placed in > the > > pom which is undesirable. > > > > To get this to work, I actually gave 1.5.1, 1.5.1 and 1.5.2-SNAPSHOT > > (which results in the proper values in the pom), created the 1.5.1-rcN > > branch from the release plugin commit for 1.5.1, edited scm.tag in > > release.properties to be 1.5.1-rcN instead of 1.5.1, and then pushed the > > 1.5.1-rcN branch. Then, release:perform will actually build and stage the > > right code. > > > > Not as simple as it might be, but at least it works and semi-aligns with > > what we described originally. > > > > > > On 1/13/14, 11:16 AM, Josh Elser wrote: > > > >> On 1/13/14, 10:17 AM, Mike Drob wrote: > >> > >>> #1 - No strong opinions. > >>> #2 - I want to make the transition for committers from one branch to > the > >>> next as painless as possible. In particular, I'm worried that somebody > >>> will > >>> not realize they need to switch branched and accidentally push e.g. > >>> 1.4.5-SNAPSHOT after we create a 1.4.6-SNAPSHOT branch. I really really > >>> want just a general 1.4 branch to deal with this case. (And similarly > >>> applied to the other lines.) > >>> > >>> What do you mean "put down the info... with the git-archive?" Listing > the > >>> exact command? > >>> > >> > >> Yes, e.g. run cmd1, then cmd2, then cmd3. Making a release (candidate) > >> shouldn't be harder than ensuring you have a GPG created. > >> > >> Another thought I had on this - what kind of tags are we using? > >>> Lightweight? Annotated? Signed? > >>> > >> > >> I think Christopher had recommended a signed tag. ACCUMULO-1468 should > >> have that definitively, but I'm not really up to date on what > >> common/good practices are here. > >> > >> I think 1.4.4 has been the only git release, and I used a lightweight > tag > >>> due to ignorance rather than choice. > >>> > >>> On Fri, Jan 10, 2014 at 11:37 AM, Josh Elser <[email protected]> > >>> wrote: > >>> > >>> For #1, we typically haven't had a need/desire to keep around how we > got > >>>> to a release (the RCs), but just the final release itself. If this is > >>>> something that has merit to it (besides trying to avoid the same > >>>> mistakes > >>>> in future releases), I can't think of a good one. Maybe putting an > RC-X > >>>> note in the commit message would be sufficient? > >>>> > >>>> #2, we could. I think the way Mike has this laid out is a little more > >>>> secure against people working already working on things for the next > >>>> release (or people who are still working on known bugs in a RC), but > >>>> they > >>>> both do the same thing. > >>>> > >>>> Mike -- whatever we finalize on, we can use ACCUMULO-1468 to document > >>>> this. Perhaps we can also put down the info you used for 1.4.4 with > the > >>>> git-archive? We also should transcribe the mvn-deploy info from > >>>> Christopher > >>>> that I have linked in the ticket. > >>>> > >>>> > >>>> On 1/9/14, 9:27 AM, Bill Havanki wrote: > >>>> > >>>> Overall, the process looks good, and I agree with Josh's > clarification. > >>>>> Two > >>>>> pieces of feedback: > >>>>> > >>>>> 1. Step 8 removes a recording of the history leading to the release. > >>>>> For > >>>>> example, suppose rc1 is no good, and it takes three commits to get > >>>>> to rc2, > >>>>> which passes. When we remove the rc1 branch, how do we easily figure > >>>>> out > >>>>> months later which commit rc1 had been based on? (Look at an rc1 JAR > >>>>> manifest for the hash? eww.) On the other hand, I can see a benefit > in > >>>>> removing inactive branches and tags to reduce clutter. > >>>>> > >>>>> 2. We could save a step, namely #7, by applying the increment to > >>>>> x.y.a-SNAPSHOT (the next version) on the tip of x.y.z-SNAPSHOT > >>>>> instead of > >>>>> on x.y.z. However, this would not leave a linear history, so I leave > >>>>> it to > >>>>> the more Git-savvy to decide if that is important in this case. > >>>>> > >>>>> Bill H > >>>>> > >>>>> > >>>>> On Wed, Jan 8, 2014 at 11:39 PM, Josh Elser <[email protected]> > >>>>> wrote: > >>>>> > >>>>> Looks good to me. I don't think it's too much work in the big > >>>>> picture -- > >>>>> > >>>>>> it's what's necessary to get it done properly given the tool. > >>>>>> > >>>>>> The only ambiguity I see is in 3a), "make corrections _on > >>>>>> x.y.z-SNAPSHOT_". > >>>>>> > >>>>>> Let's make sure this (assuming there aren't any objections) gets up > on > >>>>>> the > >>>>>> site. > >>>>>> > >>>>>> - Josh > >>>>>> > >>>>>> > >>>>>> On 1/8/14, 7:58 PM, Mike Drob wrote: > >>>>>> > >>>>>> Taking this conversation from IRC because it probably needs to be > >>>>>> on the > >>>>>> > >>>>>>> mailing list at some point. Also, we'll want to update the site > >>>>>>> when we > >>>>>>> have something we are happy with. Thanks to Christopher and Josh > >>>>>>> for the > >>>>>>> thoughts they've already contributed to the discussion. > >>>>>>> > >>>>>>> We need a standard procedure for generating RCs that is: > >>>>>>> 1) Easily reproducible > >>>>>>> 2) Compatible with ongoing development > >>>>>>> 3) Compatible with our git branching model. > >>>>>>> > >>>>>>> The proposed process is: > >>>>>>> 1) Create an RC branch named x.y.z-rcN from (the tip of) > >>>>>>> x.y.z-SNAPSHOT > >>>>>>> 2) Commit pom version changes to the branch, tag as rc, and push > >>>>>>> 3) Perform testing and voting as necessary > >>>>>>> 3a) If the vote fails, make corrections and start over at 1) > >>>>>>> 4) After a vote passes, tag the release on the same commit that > >>>>>>> was the > >>>>>>> rc > >>>>>>> 5) Apply additional pom changes (i.e. increment to next SNAPSHOT > >>>>>>> version) > >>>>>>> 6) Create a new development branch x.y.a-SNAPSHOT based on the > >>>>>>> current > >>>>>>> tip > >>>>>>> of x.y.z-SNAPSHOT > >>>>>>> 7) Merge tag + version increment into x.y.a-SNAPSHOT branch > >>>>>>> 8) Delete all rc tags, rc branches, and x.y.z-SNAPSHOT > >>>>>>> > >>>>>>> After having typed that all out it kind of seems like a lot of > >>>>>>> steps to > >>>>>>> go > >>>>>>> through, but on the other hand, we're not going to be doing > >>>>>>> everything > >>>>>>> at > >>>>>>> once anyway. > >>>>>>> > >>>>>>> Additional feedback would be awesome. > >>>>>>> > >>>>>>> Mike > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>> >
