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