submitters +1ing their own packages

[Adam Williamson]

On Wed, 2011-09-07 at 18:47 -0600, Kevin Fenzi wrote:
> On Wed, 07 Sep 2011 12:15:56 -0700
> Adam Williamson <awilliam at redhat.com> wrote:
> 
> > On Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote:
> > > On 7 September 2011 01:02, Adam Williamson <awilliam at redhat.com>
> > > wrote:
> > > > Is this a Bodhi bug? Or does FESCo expect voluntary compliance /
> > > > case-by-case enforcement of this policy?
> > > 
> > > I'm guilty of this too; when I file an update that's not getting
> > > enough karma (after a few weeks) then I give it a spin in a *fresh*
> > > VM and test it out like any normal user would do. If this is wrong,
> > > consider my wrists slapped, but otherwise I think it makes sense and
> > > gets things moving.
> > 
> > It's against the current policy. I've argued along the same lines as
> > you in past threads on this list, but I was on the minority side of
> > the debate at the time, it seemed; more people were worried that
> > maintainers would +1 their updates without bothering to test them
> > properly.
> 
> As someone on the other side of this (although not strongly, I could
> be convinced), I don't think thats my concern at all... 
> 
> * As a maintainer you should only be pushing an update you feel
>   works/fixes something anyhow. Shouldn't that be an implied +1 always
>   from the maintainer? 

I've probably responded to those before, but oh well:

this is a bit of a 'physics experiment land' point, for me. In theory?
Sure. In practice? Not really. We have this system because maintainers
*do* push updates which don't work, after all. Sometimes they 'don't
work' in a way the maintainer wouldn't have been able to catch, but
often they 'don't work' in a way the maintainer really should have
caught if they'd tested the package: viz, say, glibc -6, which prevented
all systems from booting properly. I know *I've* submitted updates on
spec, or with very minor testing, occasionally, and I'm a QA person. =)

> * As a maintainer it's easy to have a env that gets out of sync with
>   what a QA or end user would use. Ie, you make 20 iterations of a
>   package to test something, tweak configs to check something, and get
>   it all working, but perhaps your machine is no longer setup the way a
>   fresh install or upgrade of your package would be. Or you tested a
>   version and then changed just 'one little thing' and pushed that and
>   it turned out to break it. 

Both hughsie and myself, and I think everyone else in favour of
maintainer +1s, suggested maintainers should test *in a vanilla
environment*, with the actual package they were submitting, before
+1ing. +1ing on the basis of a test build or in a dirty environment
would be a no-no and could lead to the removal of +1 privileges if
repeated.

> * Even the best of us would like another pair of eyes to confirm
>   something is really fixed/working. 

Yes, indeed, in a perfect world. But it seems quite plain that, so far,
the bodhi system is working pretty well but not perfectly, and we may
have to take pragmatic changes to our beautiful, beautiful Physics
Experiment Land model (where there's no friction, and there are always
100 proventesters running Fedora 14...) in order to keep everything
flowing smoothly.

> anyhow, just thought I would toss that out there... 
> 
> kevin

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net