FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

[Kevin Kofler]

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