accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [VOTE] end of life plan for 1.4 branch
Date Mon, 05 May 2014 19:24:25 GMT
On Mon, May 5, 2014 at 2:26 PM, Christopher <ctubbsii@apache.org> wrote:

> Removing a tag will not necessarily remove it from mirrors, but it
> depends on how it is being mirrored. A git remote prune, for instance,
> will not remove tags.
>
> Further, if removing a tag can be done as a "code change", which
> requires consensus (lazy, but still consensus), not majority, then
> creating the tag should also be considered under those same terms,
> right? Clearly, creating this tag does not have consensus.
>
>
Umm... what?

Creating a tag *cannot* be a consensus action. That implies that a single
person could bomb a release, and we explicitly have those as majority.

I feel like this is taking us down a rabbit hole that is not entirely
productive. Does creating a feature branch require consensus too?

IMO, tagging is not a "code change" - it's a procedural step.


> At the risk of flip-flopping, I'm going to have keep a -1 vote for
> this release plan if it includes the creation of this confusing tag
> name. I really think just dropping the branch is sufficient.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Mon, May 5, 2014 at 1:57 PM, Sean Busbey <busbey@cloudera.com> wrote:
> > You can also push a tag removal to a remote git, which should also get
> > picked up by mirrors, no?
> >
> > -Sean
> >
> > On Mon, May 5, 2014 at 12:26 PM, Christopher <ctubbsii@apache.org>
> wrote:
> >
> >> That would be very problematic. Pushing a tag to git is a more or less
> >> permanent action. If it shows up in mirrors, it can still cause the
> >> same confusion to end users that I was worried about.
> >>
> >>
> >> On Mon, May 5, 2014 at 12:39 PM, Sean Busbey <busbey@cloudera.com>
> wrote:
> >> > Christopher,
> >> >
> >> > I think the initial tag that's included in the vote would have to
> occur
> >> > (presuming the vote passes), but any follow up action based on that
> tag
> >> > (deletion, rename, etc) would just be a code change, so we could
> quickly
> >> > correct things.
> >> >
> >> > While this is practically the same as handling the tagging
> differently,
> >> > there would be a brief point-in-time where the -eol tag would exist.
> Is
> >> > that okay?
> >> >
> >> > -Sean
> >> >
> >> >
> >> > On Mon, May 5, 2014 at 10:42 AM, Christopher <ctubbsii@apache.org>
> >> wrote:
> >> >
> >> >> If the intent is to treat the tagging as a separate action from this
> >> >> plan, then my vote changes to +1 for this plan.
> >> >>
> >> >> I have no objection to just dropping the branch (and mentioning the
> >> >> HEAD commit in the mailing list, in case the branch needs to be
> >> >> resurrected for some reason). My -1 comes from the "-eol" tag, not
> the
> >> >> rest of the plan. I don't see value in creating that tag, and worry
> >> >> about its potential for confusion.
> >> >>
> >> >> --
> >> >> Christopher L Tubbs II
> >> >> http://gravatar.com/ctubbsii
> >> >>
> >> >>
> >> >> 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
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Sean
> >>
> >
> >
> >
> > --
> > Sean
>

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