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 <[email protected]> wrote: > On Mon, May 5, 2014 at 2:26 PM, Christopher <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> 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 <[email protected]> >> >> 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 <[email protected]> >> >> wrote: >> >> >> > Hi Christopher! >> >> >> > >> >> >> > Responses inline >> >> >> > >> >> >> > >> >> >> > On Sun, May 4, 2014 at 12:50 AM, Christopher <[email protected]> >> >> >> 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 >>
