James Antill wrote: > So I did my proposal, which I think will motivate packagers to do the > right thing (giving lots of choice to the users and a reasonable number > of packages to test) and not removing the ability of packagers to do > what they want (and have the stable firehose): > > https://fedoraproject.org/wiki/Release_Lifecycle(draft)#Choice_.28james.29 This is now at: https://fedoraproject.org/wiki/Release_Lifecycle_Proposals#Choice_.28james.29 I don't really see how this is adding any kind of choice. In particular, it doesn't address the "but they have almost no options if they are happy to stay with the software that they have" "problem" you're presenting in your introduction at all. FWIW, I don't see that as a problem anyway, but that has been discussed elsewhere in this thread already. I'm just noting that your proposal is addressing something entirely different. The other proposals are for the "what kind of updates do we allow" subthread, yours is for the "when do we allow the push to hit stable as opposed to testing" thread. So I think both the naming (Choice) and the location (Release Lifecycle) of your proposal are misleading. I think your proposal makes sense as a purely informative guideline, at most as SHOULD, but NOT as something to be enforced. It is very hard to enforce something like this (who would classify the updates into those categories?) and it would be extremely excessive bureaucracy. But on the other hand, providing such a list to maintainers on an indicative basis makes a lot of sense. In fact, we already do have such an indicative list internally in KDE SIG, the approximate numbers we use: * regression fixes, security updates, trivial bugfixes, new packages (*): may be queued directly to stable, 0 DSUT otherwise * other small bugfixes: 0 DSUT (but should be allowed to hit testing before being queued to stable, and it depends on feedback how long to wait in testing, up to about a week) * upstream bugfix releases or other large bugfixes: 7 DSUT * upstream feature releases of individual applications (where suitable for an update): 7 DSUT * upstream grouped feature releases, e.g. all of KDE (where suitable for an update): 14 DSUT (where those are minimum numbers, usually n DSUT minimum means somewhere between n and n+7 DSUT in practice depending on feedback, also note that "days" here include weekends, i.e. 7 = 1 week, 14 = 2 weeks). Occasionally we push something out faster due to overwhelmingly positive feedback, but usually this is how we work, and it has worked pretty well for us so far. So having that as a general Fedora guideline makes sense to me, but only with SHOULD or indicative status, NOT as an enforced policy! (*) without Obsoletes. A new package which Obsoletes something else is effectively an upgrade for another package and it needs to be handled the same way as if the name were the same. If it's completely different code, it's a feature release. Kevin Kofler -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
