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 <ctubb...@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 <bus...@cloudera.com> wrote: > > Hi Christopher! > > > > Responses inline > > > > > > On Sun, May 4, 2014 at 12:50 AM, Christopher <ctubb...@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
