On Mon, Mar 08, 2010 at 09:59:29PM +0000, Matthew Garrett wrote: > This is the policy that I expect to be discussed during the Fesco > meeting tomorrow. This is entirely orthogonal to the ongoing discussions > regarding whether updates in stable releases should be expected to > provide features or purely bugfixes, and I don't see any conflict in > introducing it before those discussions have concluded. > > Introduction > ------------ > > We assume the following axioms: > > 1) Updates to stable that result in any reduction of functionality to > the user are unacceptable. > > 2) It is impossible to ensure that functionality will not be reduced > without sufficient testing. > > 3) Sufficient testing of software inherently requires manual > intervention by more than one individual. > > Proposal > -------- > > The ability for maintainers to flag an update directly into the updates > repository will be disabled. Before being added to updates, the package > must receive a net karma of +3 in Bodhi. I don't think this is ideal. I'm having déjà vu from a lot of these discussions & proposals -- we've been here before. When I created bodhi, it initially disallowed pushes directly to stable. This behavior... didn't sit well with The Community, for a variety of reasons. As you can tell by the uproar in every single one of these threads, if these same restriction are put in place again we will lose a lot of important contributors. Instead of re-implementing old controversial behavior, lets look at some recent behavioral changes in bodhi and see if we can build on top of those to solve these problems. For example, I recently implemented various policy restrictions for critical path/no frozen rawhide updates for pending releases. In order for a critical path update to get marked as 'stable' for a pending release, it must have at least +1 karma from releng/qa members, and at least +1 from an authenticated user. These values, of course, are configurable. I think a much better solution would be to require similar critical path policies, across *all* releases, not just pending ones, while still allowing non-critpath packages to go directly to stable. Requiring a static amount of karma across all updates is not going to be sufficient, especially with the current karma system (which I think needs improvement). Especially now with the easy-karma script, people can +1 dozens of updates at a time, reaching +3 will be almost too easy for certain packages, and yet not not easy enough for others. Having configurable karma thresholds for different packages seems to be sufficient, and it allows package maintainers to use their intuition to tweak these thresholds accordingly to fit their workflow and tester base. For example, the kernel maintainers disable karma automation entirely, and one could argue that this flexibility is important. Regarding the current karma system, I think Doug Ledford brought up some good ideas in the earlier thread 'Bodhi karma feature request', and I know other bodhi developers agree. With an improved karma system, stricter critpath update handling, AutoQA integration, and giving The User more fine-grained control over what types of updates they actually want, I think we'll be much better off than we currently are. luke -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
