On Mon, 22 Nov 2010 16:01:49 +0100, Kevin wrote: > I think it's a big mistake to provide only second-class support for > Fn-1. The assertion that that's what the people on Fn-1 want is just > unfounded, based on a misunderstanding of why people use Fn-1. There are not enough [human] resources to update Fn-1 in any way it would be close[r] to the current release. You can observe it everywhere (even by drawing conclusions about ABRT reports) that Fn-2 is abandoned by our users months before its EOL date. Anybody who disagrees is welcome to sign up as a proventester and focus on Fn-2, particularly the base packages (ex-"Core"). Same applies to Fn-1. Where are its users? Some perform an upgrade to Fn-1 very late, because they are overly pessimistic and think the current release is not ready yet. Those are not users, who would enjoy taking a look at updates-testing. If they did, they would abandon Fn-1 and upgrade to the latest greatest, which is the [only] way forward. > > this could help, but it's not always possible to add these test cases. One > > example: imap server package - new bug that can corrupt mail folders in > > some circumstances. Maintainer updates package and sets 'type=bugfix' in > > bodhi, but not always it's possible to write down any test case. It's > > still a bug fix and it's better to be delivered sooner than wait if anyone > > out there get's his mail folders corrupted. Actual policy does not help > > proactivity. > > Right, and the big point there should be that a bug which can corrupt mail > folders should be fixed IMMEDIATELY, i.e. with a direct stable push! ANY > testing requirement there is a failure. True. > >> Other concrete ideas? > > > > let maintainer decide, punish (enforce any policy) only those maintainers > > who breaks something, not all innocent group > > +1! Nothing I would back up without learning about the _details_, please. How to determine when to blame the package maintainer? What would your rule set look like? -- If a nightmare bug affects a significant number of users, it should be easier to find at least _one_ such user, who would block the update while it's in updates-testing, right? But how long to wait for that user to allocate time for the testing? What piece of the puzzle am I missing? -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
