From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 34AC71380DC for ; Thu, 6 Feb 2014 03:24:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A4660E0C31; Thu, 6 Feb 2014 03:24:09 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A00DFE0C11 for ; Thu, 6 Feb 2014 03:24:08 +0000 (UTC) Received: from [10.159.222.192] (SSID-MASON-SECURE-215.wireless.gmu.edu [192.5.215.215]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: creffett) by smtp.gentoo.org (Postfix) with ESMTPSA id BD7B933F6FB for ; Thu, 6 Feb 2014 03:24:07 +0000 (UTC) Message-ID: <52F30050.5090002@gentoo.org> Date: Wed, 05 Feb 2014 22:24:00 -0500 From: Chris Reffett User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Re: dropping redundant stable keywords References: <52E7DBC1.5020102@gentoo.org> <20140128182304.7d458a17@marga.jer-c2.orkz.net> <20140203062524.GA7467@rathaus.eclipse.co.uk> <20140203104341.2add2760@TOMWIJ-GENTOO> <20140204210319.GA1935@rathaus.eclipse.co.uk> <20140205010833.1bcf8dca@TOMWIJ-GENTOO> <1391559808.3520.2.camel@oswin.hackershack.net> <20140205020742.048cef9f@TOMWIJ-GENTOO> <1391564122.3520.4.camel@oswin.hackershack.net> <20140205024806.7d08cb63@TOMWIJ-GENTOO> <1391570147.3520.7.camel@oswin.hackershack.net> <20140205055544.6c3affea@TOMWIJ-GENTOO> <1391616442.3160.6.camel@oswin.hackershack.net> <20140205224815.70832b2d@TOMWIJ-GENTOO> <52F2B594.5050500@gentoo.org> <20140206014838.054be1ab@TOMWIJ-GENTOO> <52F2DEB9.2000901@gentoo.org> <20140206035009.6812102a@TOMWIJ-GENTOO> In-Reply-To: <20140206035009.6812102a@TOMWIJ-GENTOO> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 39cf77d9-bebd-4228-9625-ed1a3499d0cc X-Archives-Hash: cdb540429546836a2d141cb747a0468c -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/05/2014 09:50 PM, Tom Wijsman wrote: > On Wed, 5 Feb 2014 20:50:07 -0500 Rich Freeman > wrote: > >> So, I realize I'm repeating myself, but the purpose of the >> mailing list isn't to keep reposting the same arguments back and >> forth until everybody agrees. Post your argument once, and once >> it gets dull by all means appeal to QA/council/whatever but the >> bickering really doesn't add any value. For my part I promise not >> to let it be a whoever-makes-the-most-noise-sets-the-policy >> thing. I appreciate the concerns, arguments, and alternatives >> that were raised - they're helpful the first time they come up. > > +1 > >> To add something new, can the QA team please figure out what >> policy they actually intended to make and just communicate it? >> Having QA team members and everybody else openly speculating >> about what the policy is supposed to be on the list also adds no >> value. > > This is a misconception; Rick was absent during the meeting, we've > voted for it with 7 of 10, 1 person abstained, 2 were absent. A > majority thus wants the statement as it was written; which has > appeared fine up until the point that Rick addressed me in public > with a misinterpretation of that policy (or might have been unaware > of it), it's only after that point that it became clear of what I > was asking Steev, that the current policy by the QA team is being > misinterpreted. > >> If the new policy does not in fact override the standard policy >> then I'm not really sure what it is trying to say since it only >> speaks to things that were already spoken to before, just in a >> different way. > > Exactly the point; note though to avoid confusion that there is a > difference between policy and workflow here. We should still use > mask messages, if needed even news and more; and not just plain out > `rm ...`. > > However, just like you, I see no other way to read that policy than > to override our existing policy that reads 'You should also not > cause an unnecessary downgrade for any "~arch" when removing > ebuilds - ...' > > http://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance > > And to this extent I think Rick disagrees with the essence of it; > but then again, there has also been mentions of improving the > wording. Thus I don't really know if Rick wants to see it changed > _or_ removed...; however, that'll become clear with more discussion > and the meeting, which have happened, are happening and will happen > on #gentoo-qa. > >> Thanks for updating the policy webpage with the note that the >> policy shouldn't be followed until clarified. > > +1 for creffett doing that. > >> One thing I haven't really seen in this thread is a better >> understanding of the demand for old version removal. I can >> understand the hypothetical issues having old versions creates. > >> But is just WONTFIXing a bunch of old bugs a large burden in >> practice? > > It upsets stable users; and thinking of it, it doesn't get the > actual stabilization problem across. Furthermore it is odd to show > the user it is not maintained anymore while keeping that stable > keyword and version around. Why mark it stable if the maintainer > doesn't maintain it? Should it still be kept marked stable if the > maintainer considers it to not really be stable? *"Hey you, > maintainer, it acts a bit buggy!"* > >> Before we create new problems by fixing old problems, I'd like to >> get a sense for whether the old problems are actually problems. >> I imagine this becomes a matter of degree - keeping a package >> around for an extra 6-12 months probably isn't a big deal, but >> when half the tree contains 6-year-old versions it is a problem. > > We should reconsider 90 days in this respect, it might be a bit on > the low end; counting in years would indeed be more appropriate. > > Note that maybe (just guessing) those 6-year-old versions don't > really exist; but, if the stable queue continues to grow (it grows > on average) like this over time they eventually will get to exist > in the future. > > And that'll come to be an actual problem; and to avoid scratching > our heads by that time, it is nice to have our response in place in > advance. > > Quoting my meeting agenda questions of last time that reflect > this: > > "How do we evaluate whether future stabilization improves or > becomes worse? How bad is stabilization really at the moment? How > can we make more users and/or developers interested in arch > testing (and/or Gentoo)? Do we want to make a policy change now, or > delay considering it till a later meeting in the future? ...?" > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Meeting_Agenda > > I really didn't want to get involved in this mess, but here goes: - -Due to concerns about the wording of the policy, it is currently on hold pending review at an upcoming QA team meeting. - -Any further input/attempts at interpretation by QA team members at this point would needlessly confuse the issue, therefore, I would appreciate it if the QA team would stop trying to do so. We will have a meeting, argue it there, and vote. Right now, all this arguing just makes everyone more confused about what our opinion is. - -I realize that our policy was unclear and may conflict with existing policy on ebuild removal. I apologize for that, and will keep this episode in mind in the future. Chris Reffett Gentoo QA Lead -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLzAFBfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1T76QCeOCFk8ClakUmKMqD0ldJEFQE2 kxkAn1Zw/6sSOghbc43KC4QEVzolYIvn =+Pmi -----END PGP SIGNATURE-----