accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VOTE] end of life plan for 1.4 branch
Date Mon, 05 May 2014 19:51:01 GMT
No, the veto on tag creation would not halt a release. A release is
the source artifact. I can't imagine anybody would veto creation of a
tag to denote the branch from which that artifact was made, though. In
any case, I agree it's not a code change... it's a procedural step. I
was questioning it as a code change, since busbey indicated deletion
of a tag would be one.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Mon, May 5, 2014 at 3:24 PM, Mike Drob <madrob@cloudera.com> wrote:
> 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
View raw message