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 7A6F71380DC for ; Thu, 6 Feb 2014 02:51:52 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D9F7BE0B6A; Thu, 6 Feb 2014 02:51:44 +0000 (UTC) Received: from baptiste.telenet-ops.be (baptiste.telenet-ops.be [195.130.132.51]) by pigeon.gentoo.org (Postfix) with ESMTP id BACF6E0AD0 for ; Thu, 6 Feb 2014 02:51:43 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by baptiste.telenet-ops.be with bizsmtp id Nqri1n00M2khLEN01qrich; Thu, 06 Feb 2014 03:51:43 +0100 Date: Thu, 6 Feb 2014 03:50:09 +0100 From: Tom Wijsman To: rich0@gentoo.org Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: Re: dropping redundant stable keywords Message-ID: <20140206035009.6812102a@TOMWIJ-GENTOO> In-Reply-To: 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> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; x86_64-pc-linux-gnu) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 5898e451-1c40-4859-93cb-46874ec38d6a X-Archives-Hash: 2ee611c0794a552d3a05087040f4695d 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 -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D