Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: domain of josh.elser@gmail.com
 designates 209.85.216.169 as permitted sender)
Message-ID: <52FA9606.6020402@gmail.com>
Date: Tue, 11 Feb 2014 16:28:38 -0500
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: [DISCUSS] How to generate RC's
References: 
 <CAFAMeYJi4jNzUCnZ_mfygm-UuTf8b71LZqqLchvHypVDJx4KKQ@mail.gmail.com>
 <52CE281A.3040402@gmail.com>
 <CAD-fFUJ=FZPZQ9CzFoyjaggpJA2vbEakuJWOGEUs8gDfe4MrSg@mail.gmail.com>
 <52D021C7.6050001@gmail.com>
 <CAFAMeY+p4y+dY2qW8x0S6+37UPXOiSfioGjQ=BAb5Mnx9BYtjg@mail.gmail.com>
 <52D4116E.7050707@gmail.com> <52F1C32C.6070708@gmail.com>
 <CAL5zq9Y3_nrAxqRdzEVG+4Js+MLAXO0D-8-wXrZfqoMNZSnzSw@mail.gmail.com>
 <52F3F560.9090609@gmail.com>
 <CAL5zq9YB7L9U0K1WBvtKnwXNamdGg2HsCd52jqc4at7kGZNVWQ@mail.gmail.com>
 <CAFAMeYLDqJGJNmxi56vtnc9s=Qv1OGAj5CpOeDxtXExcZkXBhw@mail.gmail.com>
In-Reply-To: 
 <CAFAMeYLDqJGJNmxi56vtnc9s=Qv1OGAj5CpOeDxtXExcZkXBhw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>