Re: The new Update Acceptance Criteria are broken (was: Re: Heads Up - New Firefox update)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2010-11-01 at 22:54 +0100, Henrik NordstrÃm wrote:
> mÃn 2010-11-01 klockan 10:09 -0700 skrev Adam Williamson:
> 
> > I disagree. The evidence you cite does not support this conclusion. We
> > implemented the policies for three releases. There are significant
> > problems with one release. This does not justify the conclusion that the
> > policies should be entirely repealed.
> 
> I don't mind the process in general, but have some points where it can
> improve
> 
> 
> Very often the same update is submitted for several releases, and it's
> kind of pointless to require full karma in all releases (to require some
> in each release is ok). If one release has got full karma then it's
> reasonable to require less karma on other releases receiving the same
> update. The risk for non-obvious regression for some release only is
> fairly low, more likely there is very obvious release specific
> regressions like dependency failures when another package have been
> split/merged etc and related fuckups.

This is a reasonable modification of the idea that an update should only
require karma for one release (which would be nice if it were true but
unfortunately isn't). In practice, though, there isn't much wiggle room
for requiring 'less' karma. Non-critpath updates already require only
one +1 to go through without the waiting time requirement. Critpath
updates only require +1 from a proventester and +1 from any other tester
(proven or not).

I think I'd probably support the proposal that if a critpath update
exists in identical form for multiple releases, and it has passed full
critpath karma requirements for one release, it should require only +1
from any tester on the other releases to go out.

> We also need some obvious ways where users in general can subscribe to
> testing updates of stuff that they care about, to expand the userbase
> that performs testing of updates. Generally running a system with
> updates-testing always enabled is scary and not many want to take that
> leap. But I think that if we could give users the ability to subscribe
> to testing packages X,Y,Z of their choics and getting update & testing
> notifications for those packages only from updates-testing would speed
> things up considerably.

That's also a nice idea (though it's somewhat complex given that updates
are *actually* pushed out as sets, and a given update may be affected by
another given update even if they don't have an explicit relationship
through dependencies).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux