accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: [VOTE] end of life plan for 1.4 branch
Date Mon, 05 May 2014 16:36:24 GMT
Bill, Keith,

What already committed development in the 1.4.6 line do you find compelling
for a release?

Is there a different tag name we can use as a place holder for "look here
if you want to work with the last of the 1.4.x development" that you think
will be clearer for users? (and presumably not quite so long as that quoted
expression)

-Sean

On Mon, May 5, 2014 at 11:11 AM, Keith Turner <keith@deenlo.com> wrote:

> I agree.  Having a final 1.4.6 release and not creating a 1.4.7-SNAPSHOT
> branch seems like the path of least confusion.
>
>
>
> On Mon, May 5, 2014 at 11:04 AM, Bill Havanki <bhavanki@clouderagovt.com
> >wrote:
>
> > +1
> >
> > Having a plain "1.4.6" release would be nice (I don't like the "-eol"
> tag),
> > but I'm fine with any other plan that closes out 1.4 with a modicum of
> > clarity for users - for example, a tag off which someone could fork and
> > carry on development if they care to.
> >
> > I can assist with adjusting the site after EOL with moving doc links etc.
> >
> > Bill H
> >
> >
> > On Sun, May 4, 2014 at 4:04 PM, Sean Busbey <busbey@cloudera.com> wrote:
> >
> > > Hi Christopher!
> > >
> > > Responses inline
> > >
> > >
> > > On Sun, May 4, 2014 at 12:50 AM, Christopher <ctubbsii@apache.org>
> > wrote:
> > >
> > > > -1
> > > >
> > > > Summary:
> > > >
> > > > Overall, in favor, but...
> > > > 1. Confusing tag name
> > > > 2. Alt. Option 1: just drop the active dev branch, no tag
> > > > 3. Alt. Option 2: just closeout 1.4 with a quiet administrative 1.4.6
> > > > source release
> > > > 4. Voting under "release" rules is invalid without signed release
> > > artifacts
> > > >
> > > > Exposition:
> > > >
> > > > Overall, I'm in favor of EOL'ing 1.4.x, but I'm not sure what an
> > > > "1.4.6-eol" tag in SCM would mean to users. The "-eol" suffix
> couldn't
> > > > really be documented anywhere for users to understand how that would
> > > > differ from an actual release/tagged version, for users browsing the
> > > > SCM tags. I understand a tag is not a release, but to a user, that
> may
> > > > not be clear. It's also very confusing, because it does look like an
> > > > updated release... it has a 1-up version number over the last release
> > > > (1.4.5), after all. That's very confusing.
> > > >
> > > > To alleviate the confusion, it may be better to call it "1.4-eol" or
> > > > something else to indicate that it's not a newer release than 1.4.5
> > > > (it's not a release at all).
> > > >
> > > > An alternative option to the 1.4.6-eol tag: just drop the
> > > > development/planning branch. (This is the option that was exercised
> > > > when this decision was made for 1.3.x). All the relevant code is
> > > > merged to newer branches anyway, and the outstanding work planned for
> > > > a future 1.4.6 which will never come to pass is not useful to tag
> > > > distinctly. Besides, the HEAD commit of 1.4.6-SNAPSHOT will be around
> > > > indefinitely, as it's merged to master, so we could achieve a similar
> > > > purpose by simply noting its current HEAD commit
> > > > [5bd4465c433860624091b0d97892e02f58154e7a] in a message to the
> mailing
> > > > lists, for archival purposes.
> > > >
> > > > Another option: do an actual release vote on a signed 1.4.6 source
> > > > artifact. It wouldn't be hard to pass, since 1.4.5 passed, and the
> > > > current state of the branch isn't substantively different. We could
> > > > just call this an administrative release... no need for release
> > > > announcements and such, but it would clear up the name confusion.
> > > > 1.4.6 would be an actual thing at that point, voted on and approved
> > > > for release.
> > > >
> > > >
> > > I would really like to avoid doing a 1.4.6 release unless someone both
> > > feels strongly about the need and is also willing to shepherd through
> the
> > > testing process. The issues closed against it to date don't add
> > > substantively to the 1.4.5 release enough to justify the time
> investment
> > in
> > > testing, IMHO.
> > >
> > > I would be fine with either dropping the tag entirely or using
> something
> > > like 1.4-eol. I am inclined to have a tag we can refer to in any
> > > announcements, because they are easier to deal with for casual
> > developers.
> > >
> > > Presuming no one wants to volunteer to handle a 1.4.6 release, could we
> > > handle the tag naming as a follow-on action since it is just a code
> > change?
> > >
> > >
> > >
> > >
> > > > Also, I'm concerned that this is being treated as though it were a
> > > > release vote. A release vote requires signed release artifacts:
> > > > http://www.apache.org/dev/release.html#what
> > > > http://www.apache.org/dev/release.html#approving-a-release
> > > >
> > > > You can't issue a vote under our rules for releasing without
> providing
> > > > release artifacts on which to vote. While it may still be valid to
> > > > have a similar voting mechanism for this kind of thing, what you're
> > > > proposing is certainly not a release vote. And given that I can see
> > > > arguments for treating it as a release plan cancellation[majority],
> > > > though... or code change[lazy consensus]... or even adoption of new
> > > > code base[consensus], I think the bylaws may need some clarification
> > > > on EOL procedures/voting.
> > > >
> > > >
> > >
> > > My apologies for the lack of clarity. I only meant the phrasing "treat
> > like
> > > a release vote" to convey the relative importance I give the topic and
> to
> > > offer some reasoning on why I was looking for stronger committer buy-in
> > > than simple lazy approval. I did not mean to imply that this actually
> *is
> > > a* release vote.
> > >
> > > I agree that the bylaws as they stand could use clarification on EOL.
> > > However, I think planning would go smoother for our users if we
> > > incorporated EOL timing and procedures into a defined lifecycle for
> major
> > > versions rather than leaving it as an independent voting action. Since
> > this
> > > is part of a larger, more involved topic would you be fine with having
> it
> > > handled as a part of our discussions around the 2.0.0 version change
> > rather
> > > than tying up the sunset of 1.4?
> > >
> > > --
> > > Sean
> > >
> >
> >
> >
> > --
> > // Bill Havanki
> > // Solutions Architect, Cloudera Govt Solutions
> > // 443.686.9283
> >
>



-- 
Sean

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