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] end of life plan for 1.4 branch
Date Mon, 05 May 2014 18:37:10 GMT
On Mon, May 5, 2014 at 12:36 PM, Sean Busbey <busbey@cloudera.com> wrote:

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

Good point.  I just took a quick look in Jira and I do not see anything
that I think is compelling ATM.  Would not want to release as is.



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

I am leaning towards Christophers suggestion of not having a tag and
recording the commit hash on the mailing list.


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