-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/05/2014 07:48 PM, Tom Wijsman wrote: > On Wed, 05 Feb 2014 17:05:08 -0500 > "Rick \"Zero_Chaos\" Farina" <zeroch...@gentoo.org> wrote: > >>> >>> Yes, making the newest versions never available because the old >>> versions sink all your time really stops progress to a dead halt. >>> >> >> Your logic isn't flawed here, it's entirely missing. If version Y is >> stable on all arches but one, and that version is still using version >> X that doesn't affect any of the other arches at all. > > Can this be proven? Why are maintainers like WilliamH upset about this? > > Reference: http://article.gmane.org/gmane.linux.gentoo.devel/90063
I've already voiced my concern on his bug: https://bugs.gentoo.org/show_bug.cgi?id=500014 > >> If the maintainer doesn't wish to support version X any longer then >> they can close bugs wontfix. > > +1, but what about stabilization bugs that block other bugs? They stay open as a tracker, bugs track all arches. This doesn't prevent the work being done on the faster arches, all it does is leave bugs hanging around when certain devs think more closed bugs is more better. > >> Removing the last stable version on an arch from the tree is against >> policy. > > The QA policy meant to override this; to avoid confusion, I mean > including the proper workflow involved in this. But this has raised > concerns on IRC today, as it was made clear what the reasons are that I > was asking for; it's good that we do a new vote on this to properly > reflect what we really intend, rather than some poor voting that went > through a quick vote and didn't take everything in consideration. > Nothing in the QA policy says "ignore standard removal policy". Here is the standard removal policy, and I expect it to be followed: https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html When a doctor tells you "go to the hospital as fast as you can" he doesn't mean "steal a faster car, speed as much as possible, and don't stop at red lights". Doing so would obviously be dangerous, and cause additional problems, just like ignoring the standard keyword/ebuild removal policy. >>>> Not the QA team's actions. YOURS. YOUR actions and responses in >>>> this thread. And the fact that the QA team allows you to continue >>>> to be on it, despite your obvious lack of interest in ACTUALLY >>>> having quality assurance. My actions are affected by it because I >>>> have to continue to attempt to discuss the issue with others who >>>> actually give a shit, and you just swoop in and say no, that >>>> absolutely is unacceptable as a solution >>> >>> The policy is made by the QA team; you are attempting to object to >>> the policy, therefore this is the QA team's action. This is their >>> action. >> >> Please don't claim you speak for the QA team when in fact, you have >> not discussed it with any of us, > > We did discuss this QA policy during the QA meeting. > >> and the QA lead told you to cool it on irc hours ago. > > That was minutes ago, you are replying to is written before that; > furthermore, I believe things are cool. Why do you think otherwise? > >> You are speaking for yourself here and no one else. > > I'm quoting QA team policy, agreed on by at least 8 individuals; that > policy can be read at the following URL: > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies > That policy doesn't permit removal of keywords/ebuilds without following gentoo standard policy, standard policy is available here: https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html > If you still think so, can you show me where I did speak for myself? As I am also a member of the QA team, clearly there isn't a consensus on this topic. > >> There is NO policy that allows for dropping a stable ebuild without >> masks, discussion, and significant passage of time. >> >>> It is rather that I ask question to clarify what you are trying to >>> say as to get more useful and meaningful responses; but what I >>> receive in return is "pure and utter bullshit" on a "brick wall", >>> maybe someone else would say "no" here but if you take a closer >>> look this as well as the previous mail contains multiple questions >>> for you. >>> >>> These questions show interest in assuring quality here; it's >>> actually what makes up for a defensive style of discussion, making >>> sure that we keep our quality as opposed to applying the first >>> interesting solution that we come across. If you deem the QA team's >>> policy doesn't do that, and that it has a detriment in quality; can >>> you please let us know why? >>> >> >> Again, there is no policy that allows you to drop a stable package on >> an arch without a whole lot of things that I definitely never say >> happen. Honestly, if I even knew what you two were discussing in >> specific I'd likely be reverting the stupid drop instead of pointing >> out things in this thread which is wasting my time, and everyone >> else's. > > Indeed, there isn't; where did I say there is? > > Now that it has been said so on IRC, I see it can be misinterpreted. > >>>> (even though it doesn't affect me!) because this page here says >>>> that it can't >>>> - we can change that definition if you'd like. Instead of the line >>>> saying: >>>> >>>> The -* keyword is special. It is used to indicate package versions >>>> which are not worth trying to test on unlisted archs. >>>> >>>> Would changing it to read >>>> >>>> The -* keyword is special. It is used to indicate package versions >>>> which are not for use on unlisted archs. >>>> >>>> Would that make it acceptable? >>> >>> Feel free to propose that to the QA team and / or the Gentoo >>> Council. >> >> No changes are required. Everyone with 2 brain cells knows that -* >> means "cannot work on other arches". Things like binary packages, etc. > > And thus -* is not a solution to this thread. Agreed. If "slow arch" is causing issues, it would seem simple enough to drop all the keywords except "slow arch" on the older ebuild. It reduces maintenance burden while not breaking anyway. Amazing how the simple ones elude us sometimes. > >> Now, before you continue "discussing" this issue here on the list, >> perhaps you should turn around and talk to the QA team about what >> needs changed and discussed. > > +1 > The goal of QA is to maintain the quality of the tree. Randomly removing packages that are blocking closing bugs doesn't contribute to tree quality, it degrades it. I think we can all agree we are here to make gentoo better, so let's work together instead of against each other. No one is going to remove a stable ebuild for an arch without discussion with the maintainer and following proper policy outlined here: https://devmanual.gentoo.org/ebuild-writing/ebuild-maintenance/index.html Thanks, Zero -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS8t65AAoJEKXdFCfdEflKuIoQAJ9pzRygpdW18BAZfPX+a73j YrThNkStYSr8Ld9cQIG9tWrnuwbXUlHZt1HbJTprOrbIAIGSvy5gJm3AyoAz4lk+ 0Zka9cjy6rgLGsmsLZ0AM1eJkoHl3Z3Qh+a7vYF8yhB0E5yKtqAOSjYrz9vGPRGD +UO5rnsBfZ5TBasnENZAJtniapsshidgHGQ/zvXwuPHqoMnshhsgP5u2c3LDpSiU 17rrA+m3fkqic6aNvTELOY/a47YmA+gWfq7J0Ahs2/RRdVo6kNeFMKKmoa3o8BG6 AB6v752LfNCFHbZTfmrNPxJvHqm9a2QybFPziAlHin0Truml5ayj90ZCz/0N1pR4 dQTRvwkpX4JWvV5BZj1hXJYEViOY32F62CHeNLfCKxviio5sMxZ168Yvvop66A0+ aY/n4bPa3euSjaMEfiSVOGx0DBaiMaBkiYlcVrcIzaevlrAO+VnvPBYR5HzMehH+ GNgf6r2rOqGwtMe2yU+ilOPVvkPh71KpOS/KXCke/6aEmMTjLZ9/COWmZ5ltnK7H k/52k3Jh6KoKtrT8HS+FHs7+kT6SJj9MwGz9gEG1H2eTE7/VLVnC2JrVvB2SPIJF 5Uk7giW87lgd7cCdZwRMEVR/nKrVAuGysK+EMJxgvhZkYXz9kDCusfFxw3NIvvMO 34VTKxpRaPzeNItzClv0 =ED04 -----END PGP SIGNATURE-----
