-----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 <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 > > 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-----
