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 17:26:14 GMT
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.

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


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

Mime
View raw message