Matthew Garrett píše v Po 08. 03. 2010 v 21:59 +0000: > 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: I think first should come the answer on "what problem is this proposal trying to solve?". Is it the plain number of updates? Is it the quality of updates? What updates failed? > 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. Unfortunately this tries to use the "one size fits all" method, but this can't work in the recent Fedora with the number of source packages attacking the 10000 mark. And for sure there are packages with many users (millions?) and on other side packages with few users (dozens or even less). And as others said, sometimes it's hard to get even a response from the reporter on his own bug ... > It should be noted that this does not require that packages pass through > updates-testing. The package will appear in Bodhi as soon as the update > is available. If sufficient karma is added before a push occurs, and the > update is flagged for automatic pushing when the karma threshold is > reached, the update will be pushed directly to updates. > > It is the expectation of Fesco that the majority of updates should > easily be able to garner the necessary karma in a minimal space of time. > Updates in response to functional regressions should be coordinated with > those who have observed these regressions in order to confirm that the > update fixes them correctly. Yes, this can again work for the mainstream packages and not for the rest. And as result the only way to get a newer version of a non-mainstream package will be only to upgrade the whole distro with a waiting time up to 6 months. The new release contains both bugfixes and new features, because the author can't maintain multiple branches at a time and is doing releases every few months - one of the open source principles was release early, release often. So what are the options if the situation is so serious that something must be done: - start automated testing of updates - let the machine work, it can do a lot - divide packages into more tiers - add one(?) level between critpatch and the rest that would require better testing (for example containing libraries used by another package), some statistics how much are packages installed would be needed - start creating personal repos with updated stuff - and I always thought this is the wrong way that is used by other distros and their users ... - improve the updates delivery mechanism so the user can easily consume the regular updates and also test and comment the non-stable ones, this would also require educating the users that there can be a newer version in updates-testing when they are not satisfied with the stable one - every package must have a QA person, well at least 3 ... And yes, there are some not very nice options too ... Dan -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
