accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [DISCUSS] How to generate RC's
Date Tue, 11 Feb 2014 21:30:52 GMT
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 <josh.elser@gmail.com> 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 <ctubbsii@apache.org> 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 <josh.elser@gmail.com> 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 <josh.elser@gmail.com>
>>>>>
>>>> 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 <josh.elser@gmail.com>
>>>>>>>> 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 <josh.elser@gmail.com
>>>>>>>>>> >
>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message