On Wed, 5 Feb 2014 20:50:07 -0500 Rich Freeman <ri...@gentoo.org> 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 : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
