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
