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
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
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
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org