For what it's worth, Hadoop 2.3 rc0 went out today with a 7 day vote. http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201402.mbox/%3CDA05A835-B25D-4922-8573-46BBB8807ABE%40hortonworks.com%3E
On Tue, Feb 11, 2014 at 1:28 PM, Josh Elser <[email protected]> wrote: > I think I mentioned this earlier/elsewhere already, but I'd prefer better > communication by parties interesting in testing so that when the RC is > called, we already have the day+ duration tests already run. > > IMO I don't think the voting time is the right time to be trying to find > "distributed system" level bugs. That should be time focused on judging the > release itself -- packaging (tarball, rpm, debs, etc), ASF requirements > (signing, hashes), scripts (init.d, bin/*), basic user interaction, and the > like. > > > On 2/11/14, 4:17 PM, Mike Drob wrote: > >> One more change that I'd like to see is expanding the voting period beyond >> 72 hours. If I want to test the RC on different hardware/OS/versions than >> the release manager has done, then I need a longer time frame than what is >> currently provided. >> >> >> On Thu, Feb 6, 2014 at 7:54 PM, Christopher <[email protected]> wrote: >> >> I say don't bump until the vote passes or fails. If it passes, either >>> drop the branch, or if there are commits since the RC was made, no-op >>> merge in the tag, bump the version, and rename the branch. The version >>> doesn't matter until later. >>> >>> I believe the release plugin has a goal to bump versions only, so that >>> part is pretty easy. >>> >>> -- >>> Christopher L Tubbs II >>> http://gravatar.com/ctubbsii >>> >>> >>> On Thu, Feb 6, 2014 at 3:49 PM, Josh Elser <[email protected]> wrote: >>> >>>> Changing the tagNameFormat would remove an extra manual step which is >>>> >>> likely >>> >>>> good. I'm not sure about how the local checkout stuff works and if there >>>> >>> is >>> >>>> something easier we can do there. >>>> >>>> One extra thing that I've found that is a little awkward to work with >>>> now >>>> that we're in a vote, is that we almost want to freeze the >>>> 1.5.1-SNAPSHOT >>>> branch. I haven't been able to come up with what we should do with the >>>> branch for the version we're trying to release considering that at least >>>> >>> one >>> >>>> RC will probably fail. >>>> >>>> We *could* bump the 1.5.1-SNAPSHOT branch to 1.5.2-SNAPSHOT in the poms, >>>> >>> but >>> >>>> then we would need to revert that every time we fail a RC. That's >>>> >>> probably >>> >>>> the best solution that doesn't try to work around the >>>> >>> maven-release-plugin, >>> >>>> but it does leave some nice blemishes in the history. >>>> >>>> >>>> On 2/5/14, 5:16 PM, Christopher wrote: >>>> >>>>> >>>>> We should change tagNameFormat for the maven-release-plugin to >>>>> @{project.version}, so you can just hit "enter" at that field to >>>>> accept the default. You may still need to do the rest of what you did >>>>> (or something similar) to push to a different branch or tag, though... >>>>> I'm not sure (I wonder if you could just let it build the local tag it >>>>> creates instead of editing scm.tag), and simply don't push that tag >>>>> until you change its name to one with -rcX. >>>>> >>>>> -- >>>>> Christopher L Tubbs II >>>>> http://gravatar.com/ctubbsii >>>>> >>>>> >>>>> On Tue, Feb 4, 2014 at 11: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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >>
