SGTM. Though, I have one question?

What if there is a bad commit message in 0.12.(z-1)-rcN that you want to
amend in 0.12.z-rc1 ? Would we not allow this? Is the requirement going to
be that a non-fast-forward 0.12.(z-1)-rc(N+1) be released first and then
base 0.12.z-rc1 be based off that?


On Wed, Jun 5, 2013 at 1:22 PM, Benjamin Hindman <[email protected]> wrote:

> Thanks for capturing the discussion Ben. A few thoughts inline.
>
>  The process would be as follows:
>>
>> 1. Tag a candidate: 0.12.0-rc1.
>> 2. Call a VOTE to release RC1.
>> 3. If successful, release and tag 0.12.0 from 0.12.0-rc1.
>> 4. Otherwise, progress with 0.12.0-rc2 by creating a local branch off of
>> 0.12.0-rc1 and applying the necessary commits.
>>
>
> I don't think that 0.12.0-rc2 needs to be branched off of 0.12.0-rc1. For
> example, we might want to fix a commit message from 0.12.0-rc1 for
> 0.12.0-rc2 which means that 0.12.0-rc2 will be divergent from 0.12.0-rc1.
> We should always make 0.12.z-rcN be branched off of 0.12.(z-1), but not
> have that requirement for candidates (they are just a "candidate" after
> all).
>
> Other than that, this all SGTM!
>
>
>
>
>>
>> History can be seen using 'git log 0.12.0-rc1..0.12.0-rc2'.
>>
>> This means tags are immutable, and a source of truth for the RCs and
>> releases.
>>
>> For now, I will be punting on removing the 0.12.x branch, and will simply
>> create a 0.12.0-rc1 tag to call a VOTE with. But I'd like to gather
>> thoughts, +1's or -1's.
>>
>> There's no documentation that I know of. So, yes documenting the
>>> checklist is a great idea.
>>> Also note, that we create branches of the form "0.12.x" instead of
>>> "0.12.0". This makes it easy to cherry pick commits for future bug fix
>>> releases and release candidates.
>>> Also, you might want to checkout the release.sh script (if there are
>>> some updates to it) from the master branch into 0.12.x.
>>
>>
>>
>> On Tue, Jun 4, 2013 at 7:50 PM, Mattmann, Chris A (398J) <
>> [email protected]> wrote:
>>
>>> Looking good, Ben M!
>>>
>>> Thanks for throwing this up! I've prefixed the subject line
>>> with a [DISCUSS] thread. Not a requirement by any means but
>>> makes it nice when looking in mail-archives.apache.org and
>>> other threaded browsers to see like minded discussion threads :)
>>>
>>> So, putting this up on a wiki would be great.
>>> Looking at:
>>>
>>> http://incubator.apache.org/projects/mesos.html
>>>
>>>
>>> We have a confluence wiki here:
>>>
>>> https://cwiki.apache.org/confluence/display/MESOS/Index
>>>
>>>
>>> I don't have karma to edit it (need to remove the docs exist
>>> at Github part). I'm working with infra to get karma. Once I
>>> get it we should add a release process page there that simply
>>> copies the below :)
>>>
>>> Either way +1 to proceed with step #1.
>>>
>>> Cheers,
>>> Chris
>>>
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> Chris Mattmann, Ph.D.
>>> Senior Computer Scientist
>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>> Office: 171-266B, Mailstop: 171-246
>>> Email: [email protected]
>>> WWW:  http://sunset.usc.edu/~mattmann/
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> Adjunct Assistant Professor, Computer Science Department
>>> University of Southern California, Los Angeles, CA 90089 USA
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Benjamin Mahler <[email protected]>
>>> Reply-To: "[email protected]" <
>>> [email protected]>
>>> Date: Tuesday, June 4, 2013 7:23 PM
>>> To: Benjamin Hindman <[email protected]>, Vinod Kone <
>>> [email protected]>
>>> Cc: "[email protected]" <[email protected]>
>>> Subject: Release process.
>>>
>>> >Now that 0.11.0 is out, we should continue freeing up the backlog and
>>> >proceed with 0.12.0. I'll be taking care of this release and I'd like to
>>> >document the release process to make it easier for others to help out
>>> with
>>> >releases in the future. Is there already documentation somewhere? Here's
>>> >what I've inferred:
>>> >
>>> >1. First I'll gather the JIRA tickets for the CHANGELOG.
>>> >
>>> >2. Send out a review / commit the CHANGELOG updates.
>>> >
>>> >3. Cherry pick the CHANGELOG onto 0.12.0.
>>> >
>>> >4. Run 'git checkout 0.12.0 && ./support/release.sh 0.12.0 1'.
>>> >
>>> >5. Mail [email protected] and
>>> >[email protected] a VOTE.
>>> >
>>> >6. After a successful VOTE, add it to the website(s)?
>>> >
>>> >7. Upload the jar to artifactory, I see Vinod is having issues with that
>>> >at
>>> >the moment.
>>> >
>>> >Missing anything?
>>>
>>>
>>
>

Reply via email to