Return-Path: X-Original-To: apmail-accumulo-dev-archive@www.apache.org Delivered-To: apmail-accumulo-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1AE9A11137 for ; Mon, 5 May 2014 17:26:28 +0000 (UTC) Received: (qmail 98531 invoked by uid 500); 5 May 2014 17:26:17 -0000 Delivered-To: apmail-accumulo-dev-archive@accumulo.apache.org Received: (qmail 98479 invoked by uid 500); 5 May 2014 17:26:16 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 98467 invoked by uid 99); 5 May 2014 17:26:16 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 May 2014 17:26:16 +0000 Received: from localhost (HELO mail-la0-f53.google.com) (127.0.0.1) (smtp-auth username ctubbsii, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 May 2014 17:26:16 +0000 Received: by mail-la0-f53.google.com with SMTP id b8so4931262lan.26 for ; Mon, 05 May 2014 10:26:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.150.103 with SMTP id uh7mr3586322lbb.30.1399310774356; Mon, 05 May 2014 10:26:14 -0700 (PDT) Received: by 10.114.99.67 with HTTP; Mon, 5 May 2014 10:26:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 May 2014 13:26:14 -0400 Message-ID: Subject: Re: [VOTE] end of life plan for 1.4 branch From: Christopher To: Accumulo Dev List Content-Type: text/plain; charset=UTF-8 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 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 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 wrote: >> > Hi Christopher! >> > >> > Responses inline >> > >> > >> > On Sun, May 4, 2014 at 12:50 AM, Christopher >> 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