[gentoo-dev] evolution of x86 stabling procedures
I maintain very few packages these days, so it was quite a surprise to me today when I discovered that peer review is now effectively a part of the x86 stabilization process. When I wrote GLEP 40, the problem that I was trying to solve was that of devs stabling packages without ever testing the package on an actual stable system (because most devs run ~arch). As such, the language in GLEP 40 essentially suggests that devs could still stable their own packages, but only if they were properly testing the package on a stable system. That policy has evolved over time to one where devs are actively discouraged from stabling their own packages, thereby ensuring that at least one other person examines and tests the ebuild before it becomes stable. (I'm still not quite sure of the actual procedure, so I'm not sure how many people are generally involved in this peer review process.) From a QA perspective, more eyes can only be a good thing, and this idea has been tossed around on-and-off for years. On the other hand, peer review could potentially really slow things down, which is why we'd always rejected that approach in the past. Are other arch's also requiring peer review? Do we have any statistics or anecdotal evidence for what's improving, and whether or not anything is getting worse as a result? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpcIG0ZQQWuA.pgp Description: PGP signature
Re: [gentoo-dev] evolution of x86 stabling procedures
Grant Goodyear [EMAIL PROTECTED] said: I maintain very few packages these days, so it was quite a surprise to me today when I discovered that peer review is now effectively a part of the x86 stabilization process. When I wrote GLEP 40, the problem that I was trying to solve was that of devs stabling packages without ever testing the package on an actual stable system (because most devs run ~arch). As such, the language in GLEP 40 essentially suggests that devs could still stable their own packages, but only if they were properly testing the package on a stable system. That policy has evolved over time to one where devs are actively discouraged from stabling their own packages, thereby ensuring that at least one other person examines and tests the ebuild before it becomes stable. (I'm still not quite sure of the actual procedure, so I'm not sure how many people are generally involved in this peer review process.) From a QA perspective, more eyes can only be a good thing, and this idea has been tossed around on-and-off for years. On the other hand, peer review could potentially really slow things down, which is why we'd always rejected that approach in the past. Are other arch's also requiring peer review? Do we have any statistics or anecdotal evidence for what's improving, and whether or not anything is getting worse as a result? Well, since you decided to bring this up on here, I guess we'll just try to address everything. I believe almost everyone has been happy with how the x86 team has turned out. I have only gotten positive feedback from people and users. Despite that, we still have some devs, and *teams*, that don't follow proper keywording procedures. Peer review should be part of any stablization process. The glep that *you* wrote even provides for it: For a package to move to stable, the following guidelines must be met: ... * The relevant arch team must agree to it. Maybe it was not what you intended, but we have not been slowing down any process as far as I'm aware, since we get to our bugs as quickly as we possibly can. And every arch team has their own keywording policy. I don't see why x86 can not have the poilcy that we decided on. If you have MIPS hardware and you mark something ~mips, I'm pretty sure they will be pissed if they didn't give you prior permission. Probably the same for a few archs. The x86 team has been asking for months now that everyone files a bug to have their package stablized, and we allow maintainers to stablize their package when it is impossible for us to do so. I'm trying to figure out why this is a problem all of a sudden, because things seemed to be going just fine. Thanks, -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpOD1VY3Mhq5.pgp Description: PGP signature
Re: [gentoo-dev] evolution of x86 stabling procedures
On Mon, Jun 05, 2006 at 03:00:57PM -0500, Grant Goodyear wrote: I maintain very few packages these days, so it was quite a surprise to me today when I discovered that peer review is now effectively a part of the x86 stabilization process. When I wrote GLEP 40, the problem that I was trying to solve was that of devs stabling packages without ever testing the package on an actual stable system (because most devs run ~arch). As such, the language in GLEP 40 essentially suggests that devs could still stable their own packages, but only if they were properly testing the package on a stable system. That policy has evolved over time to one where devs are actively discouraged from stabling their own packages, thereby ensuring that at least one other person examines and tests the ebuild before it becomes stable. (I'm still not quite sure of the actual procedure, so I'm not sure how many people are generally involved in this peer review process.) From a QA perspective, more eyes can only be a good thing, and this idea has been tossed around on-and-off for years. On the other hand, peer review could potentially really slow things down, which is why we'd always rejected that approach in the past. Are other arch's also requiring peer review? Do we have any statistics or anecdotal evidence for what's improving, and whether or not anything is getting worse as a result? The Alpha team does the exact same thing. Requiring devs to file stable bugs even if they can test on alpha hardware themselves or in some cases devs outside the team are allowed to keyword a few packages. I've never put this into system the way the x86 team has, mostly because it's never been much of a problem with few devs having alpha hardware. It's more been a case of me (or other devs from the alpha team) randomly catching other devs in touching our keywords and asking them to abide by our keywording policy. Also, looking at http://devmanual.gentoo.org/archs/index.html you see similar policies for almost all the archs described there. The big difference I think, being how big a hammer arch teams apply and how much attention they pay to the tree regarding their keywords. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] evolution of x86 stabling procedures
Mark Loeser wrote: [Mon Jun 05 2006, 03:25:02PM CDT] Well, since you decided to bring this up on here, I guess we'll just try to address everything. Where else would I have brought this up? Paraphrasing, I noted that the x86 team is now doing peer review, I asked if other arch teams are doing the same thing, and I asked how the new system is working, and whether or not the old fears that peer review would slow things down too much seemed to be valid. If that isn't a question for the Gentoo development list, I don't know what is. Nowhere did I say anything evenly remotely negative about what the x86 team is doing, as far as I can tell. If I did, then I sincerely apologize, as it was definitely not my intention. Peer review should be part of any stablization process. The glep that *you* wrote even provides for it: For a package to move to stable, the following guidelines must be met: ... * The relevant arch team must agree to it. Heh. That'll teach me! Maybe it was not what you intended, but we have not been slowing down any process as far as I'm aware, since we get to our bugs as quickly as we possibly can. And every arch team has their own keywording policy. I don't see why x86 can not have the poilcy that we decided on. If you have MIPS hardware and you mark something ~mips, I'm pretty sure they will be pissed if they didn't give you prior permission. Probably the same for a few archs. I didn't say that the x86 policy was a bad one. I was rather hoping that x86 was doing peer review and at least one other arch team wasn't, since then we could try to make some sort of quantitative comparison. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpVRXLsKvjd5.pgp Description: PGP signature
Re: [gentoo-dev] evolution of x86 stabling procedures
On Mon, 5 Jun 2006 15:00:57 -0500 Grant Goodyear [EMAIL PROTECTED] wrote: Are other arch's also requiring peer review? On SPARC, we normally keyword everything ourselves and get all up in your hizzouze if you keyword something that you haven't asked us about. We normally will let devs keyword their packages once we have an assurance that they have access to appropriate hardware to test things, and keep track of this via a list on the devwiki SPARC page. We have a couple of scripts that email us keyword info on ebuilds so we can watch and see who may be doing bad things. Cheers, -- Jason Wever Gentoo/Sparc Team Co-Lead signature.asc Description: PGP signature
