On Thu, Dec 02, 2010 at 01:16:18PM -0800, Adam Williamson wrote: > On Thu, 2010-12-02 at 12:30 -0800, Toshio Kuratomi wrote: > > On Thu, Dec 02, 2010 at 11:25:03AM -0800, Adam Williamson wrote: > > > On Thu, 2010-12-02 at 14:10 -0500, Doug Ledford wrote: > > > > That being the case, I test the package fairly rigorously myself. But > > > > this process doesn't take that into account. I test far more things > > > > than you get with a few people just doing smoke tests, but the smoke > > > > tests are actually the gating factor. If you changed the process so a > > > > maintainer can indicate they've done their own fairly extensive testing, > > > > that would satisfy me. But that also opens the door for abuse, so you > > > > would have to watch maintainers once you enabled this ability. > > > > > > I've posted in the thread earlier that I'd actually like to do this, > > > others seem opposed however. > > > > > FWIW I'm for it with your explanation and added it to the Update > > brainstorming page last night: > > > > https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Changes_Ideas_Container > > If we go this way, I'd propose adding additional guidelines to the > proventester policy specific to maintainers testing their own packages. > > * Test the actual build that will go out, from Koji - don't test your > own local build of the same spec > > * Try and test in a reasonably user-ish environment, not your own highly > customized one; if this means using a separate user account or a VM, do > Note about this second bullet: I'm not sure this is good advice. There's been quite a few times I've encountered bugs in end-user oriented programs where deleting the config files in my home directory made the bug "disappear". Similarly, I remember there was a bind update a few releases back where the package was trying to rewrite the existing config files which failed when the update was attempted on boxes that had already customized the config. I see what you're trying to get at here but I think what it really boils down to is -- "you should have two sets of eyes look at this." So perhaps, upping the karma requirement to +2 and letting maintainers +1 their own updates helps here. Note that that doesn't help the non-critpath packages get accepted faster but it could help the critpath packages in two ways: 1) If you don't touch the requirements for critpath, it still just needs two +1 and now the packager can give one of those themselves. 2) If the maintainer happens to be a proventester, then they only need to find a regular user to give the other karma point. -Toshoi
Attachment:
pgpHmn6y08RJs.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel