accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [VOTE] 1.5.1-RC2
Date Wed, 19 Feb 2014 19:00:56 GMT
On Wed, Feb 19, 2014 at 1:40 PM, Mike Drob <madrob@cloudera.com> wrote:

> I was reading that as "1.4.0->1.5.0" and "1.5.0 changes" were the same
>

Oh right.  I was thinking about the 1.4.0 release notes that were manually
generated.  I thought these were informative, but I suppose that was done
because we did not have the information in jira.   If the issues in jira
are properly marked (as feature, improvement, bug) and have nice subject
lines, then that should be equally informative.


> thing. That is to say, we take the CHANGES file that shipped with 1.5.0 and
> add another section to it, a la the 1.4.x series.
>
>
> On Wed, Feb 19, 2014 at 1:37 PM, Keith Turner <keith@deenlo.com> wrote:
>
> > Breaking 1.5.0 and 1.5.1 out seems like a seperate issue from adding
> > 1.4.0->1.5.0 changes.  Adding 1.4.0->1.5.0 changes seems like a useful
> > thing to communicate, but it was not in 1.5.0.  I am not sure it should
> > hold up 1.5.1.  Maybe something to consider for 1.6.0 or 1.7.0?
> >
> >
> > On Wed, Feb 19, 2014 at 1:28 PM, John Vines <vines@apache.org> wrote:
> >
> > > I prefer per minor release breakout of changes. Such that, the Changes
> > file
> > > should have one block for 1.5.0->1.5.1 changes (for those who are
> > upgrading
> > > from 1.5.0), but also the 1.4.0->1.5.0 changes (for those moving from
> > 1.4.x
> > > to 1.5.1).
> > >
> > >
> > > On Wed, Feb 19, 2014 at 1:23 PM, Mike Drob <madrob@cloudera.com>
> wrote:
> > >
> > > > I went back and looked at our release governance page[1] and it does
> > > > explicitly state that votes will be 72 hours. So I was out of line
> when
> > > > asking you to extend it and I'm not sure that the extension is valid
> at
> > > > this point anyway. Lack of bylaws makes this a messy process.
> > > >
> > > > In light of this I am changing my vote from +1 to +0, since I did not
> > > vote
> > > > in the original time frame.
> > > >
> > > > [1]: http://accumulo.apache.org/governance/releasing.html#releasing
> > > >
> > > >
> > > > On Sat, Feb 15, 2014 at 7:17 PM, Josh Elser <josh.elser@gmail.com>
> > > wrote:
> > > >
> > > > > Alright, given the snow, holiday, and the lack of bylaws stating
> > that I
> > > > > cannot do this:
> > > > >
> > > > > I'm extending the VOTE on 1.5.1-RC2 until 02/19/2014 1900 EST (this
> > > > > extends the original duration to a week for those keeping track).
> > This
> > > is
> > > > > expected to provide an additional two full work days for people to
> > > > inspect
> > > > > the release.
> > > > >
> > > > > Let's get some good feedback before then, folks.
> > > > >
> > > > > - Josh
> > > > >
> > > > >
> > > > > On 2/15/14, 6:29 PM, Christopher wrote:
> > > > >
> > > > >> Either way works for me.
> > > > >>
> > > > >> I was just suggesting a more formal approach in the absence of
> > bylaws
> > > > >> that explicitly permit extensions. The general concern, I suppose,
> > is
> > > > >> that vote extensions could be used to manipulate to a desired
> > outcome
> > > > >> in a majority approval scheme... so having the vote conditions
> fixed
> > > > >> at the time it is announced prevents that. I don't think that's
a
> > > > >> serious concern, though... especially since we all have the same
> > goal
> > > > >> of producing a quality release, and preventing one that falls
> short
> > of
> > > > >> that.
> > > > >>
> > > > >> With the bylaws in place, things are simpler, because we'd have
> > > > >> already agreed on those bylaws, and wouldn't need to do anything
> > > > >> silly, like vote on whether to allow a vote extension in the
first
> > > > >> place (which would get obnoxious).
> > > > >>
> > > > >> --
> > > > >> Christopher L Tubbs II
> > > > >> http://gravatar.com/ctubbsii
> > > > >>
> > > > >>
> > > > >> On Sat, Feb 15, 2014 at 6:00 PM, Billie Rinaldi
> > > > >> <billie.rinaldi@gmail.com> wrote:
> > > > >>
> > > > >>> On Sat, Feb 15, 2014 at 1:57 PM, Christopher <
> ctubbsii@apache.org>
> > > > >>> wrote:
> > > > >>>
> > > > >>>  A somewhat more formal way of "extending" the vote would
be to
> > > simply
> > > > >>>> retract/cancel this vote (or let it lapse with no votes),
and
> just
> > > > >>>> re-issue another vote with identical artifacts at a more
> opportune
> > > > >>>> time. I point this out for two reasons:
> > > > >>>>
> > > > >>>> 1) I don't want to undermine Josh's work to create this
release
> > > > >>>> candidate. He shouldn't have to do that again if nothing
has
> > changed
> > > > >>>> and we just need more time to review. And,
> > > > >>>>
> > > > >>>> 2) The vote was called with a 72hr. notice, and changing
that
> > after
> > > > >>>> the fact is probably a bit questionable. We can achieve
the same
> > > > >>>> effect without modifying the characteristics of the vote,
by
> > simply
> > > > >>>> calling a new vote, identical to this one, later.
> > > > >>>>
> > > > >>>>
> > > > >>> I'm not sure that extending the vote is questionable.  I
think it
> > > would
> > > > >>> be
> > > > >>> fine if Josh just said the vote deadline is extended to X
> (perhaps
> > an
> > > > >>> additional 72 hours, or maybe event one week from the original
> post
> > > > since
> > > > >>> many people have Monday off).  Some Apache projects explicitly
> > > mention
> > > > >>> that
> > > > >>> votes may be extended in their bylaws [1], so that's something
we
> > > could
> > > > >>> consider when we write ours.
> > > > >>>
> > > > >>> But if people would feel more comfortable if Josh reposted
the
> > vote,
> > > > I'm
> > > > >>> sure he could do that.  :-)
> > > > >>>
> > > > >>> [1]: https://hc.apache.org/bylaws.html
> > > > >>>
> > > > >>> --
> > > > >>> Christopher L Tubbs II
> > > > >>> http://gravatar.com/ctubbsii
> > > > >>>
> > > > >>>
> > > > >>> On Fri, Feb 14, 2014 at 6:09 PM, Christopher <
> ctubbsii@apache.org>
> > > > >>> wrote:
> > > > >>>
> > > > >>>> More time would be great. I'll still try to finish up
some
> testing
> > > by
> > > > >>>>> tomorrow, but I can't make any guarantees.
> > > > >>>>>
> > > > >>>>> --
> > > > >>>>> Christopher L Tubbs II
> > > > >>>>> http://gravatar.com/ctubbsii
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> On Fri, Feb 14, 2014 at 12:43 PM, Josh Elser <
> > josh.elser@gmail.com
> > > >
> > > > >>>>>
> > > > >>>> wrote:
> > > > >>>>
> > > > >>>>> If people want some extra time given the impact of
snow, please
> > > > inform.
> > > > >>>>>>
> > > > >>>>> I'm
> > > > >>>>
> > > > >>>>> ok with extending this a few days if it means people
will give
> it
> > > > more
> > > > >>>>>>
> > > > >>>>> love.
> > > > >>>>
> > > > >>>>>
> > > > >>>>>>
> > > > >>>>>> On 2/12/14, 6:50 PM, Josh Elser wrote:
> > > > >>>>>>
> > > > >>>>>>>
> > > > >>>>>>> All,
> > > > >>>>>>>
> > > > >>>>>>> Please consider the following candidate as
Apache Accumulo
> > 1.5.1
> > > > >>>>>>>
> > > > >>>>>>> Git artifacts: The staging repository was
built from the
> branch
> > > > >>>>>>> "1.5.1-rc2" (c810f51b). No accompanying git
tag was created
> yet
> > > (as
> > > > >>>>>>> it
> > > > >>>>>>> would be the same exact thing as providing
the above SHA1).
> > > > >>>>>>>
> > > > >>>>>>> Maven Staged Repo:
> > > > >>>>>>>
> > > > >>>>>>>  https://repository.apache.org/content/repositories/
> > > > >>>> orgapacheaccumulo-1001
> > > > >>>>
> > > > >>>>>
> > > > >>>>>>> Source tarball:
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>  http://repository.apache.org/content/repositories/
> > > > >>>> orgapacheaccumulo-1001/org/apache/accumulo/accumulo/1.5.
> > > > >>>> 1/accumulo-1.5.1-src.tar.gz
> > > > >>>>
> > > > >>>>>
> > > > >>>>>>>
> > > > >>>>>>> Binary tarball:
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>  http://repository.apache.org/content/repositories/
> > > > >>>> orgapacheaccumulo-1001/org/apache/accumulo/accumulo/1.5.
> > > > >>>> 1/accumulo-1.5.1-bin.tar.gz
> > > > >>>>
> > > > >>>>>
> > > > >>>>>>>
> > > > >>>>>>> Changes since 1.5.1-RC1: ACCUMULO-1908, ACCUMULO-1935,
> > > > ACCUMULO-2299,
> > > > >>>>>>> ACCUMULO-2329, ACCUMULO-2331, ACCUMULO-2332,
ACCUMULO-2334,
> > > > >>>>>>> ACCUMULO-2337, ACCUMULO-2342, ACCUMULO-2344,
ACCUMULO-2356,
> > > > >>>>>>>
> > > > >>>>>> ACCUMULO-2360
> > > > >>>>
> > > > >>>>>
> > > > >>>>>>> Changes since 1.5.0:
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>  https://git-wip-us.apache.org/repos/asf?p=accumulo.git;a=
> > > > >>>> commitdiff;h=d277321d176b71753d391f896f09dc9785173cb0
> > > > >>>>
> > > > >>>>>
> > > > >>>>>>>
> > > > >>>>>>> Keys: http://www.apache.org/dist/accumulo/KEYS
> > > > >>>>>>>
> > > > >>>>>>> Testing:
> > > > >>>>>>>
> > > > >>>>>>> Manual testing and verification of fixes
since RC1 and 12hr
> CI
> > > with
> > > > >>>>>>> verification performed. All previously mentioned
testing done
> > for
> > > > >>>>>>> RC1.
> > > > >>>>>>>
> > > > >>>>>>> This vote will be open for the next 72 hours.
> > > > >>>>>>>
> > > > >>>>>>> Upon successful completion of this vote,
a 1.5.1 gpg-signed
> Git
> > > tag
> > > > >>>>>>>
> > > > >>>>>> will
> > > > >>>>
> > > > >>>>> be created from c810f51b and the above staging repository
will
> be
> > > > >>>>>>> promoted.
> > > > >>>>>>>
> > > > >>>>>>> - Josh
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>
> > > >
> > >
> >
>

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