accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [DISCUSS] How to generate RC's
Date Wed, 05 Feb 2014 15:15:40 GMT
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" <busbey+lists@cloudera.com> 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 <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