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

[James Antill]

On Tue, 2010-03-02 at 10:59 +0100, Kevin Kofler wrote:
> 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.

 Users don't get a constant firehose of updates they are basically
forced to install, a lot more packages should spend a lot more time in
testing (thus. the user can choose to get the updates or updates-testing
versions).
 How is that not more choice than "here's rawhide-12, you are now forced
to test it for me"?

>   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 read them all as trying to solve the "what do we do in the lifecycle
of a release, to make it suck less for users" problem and general stop
users saying "Well I use Fedora in spite of the number/size of updates".
 One way is to just outright ban a lot of updates, but this then becomes
subjective and I'm not sure rel-eng is setup to do that. So I proposed
something that could be objectively implemented, and would give the
packagers the freedom to do the updates the think are best.

> 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?)

 The packagers would classify their bugs, in "make update" mostly as the
do now (although there are more categories). I don't think anyone is
arguing that packagers are actively trying to harm anybody, so I'd
assume they would classify them correctly in the vast majority of cases.
 The problem with leaving it as a SHOULD is the tendency for packagers
to be significant users of their packages, so they tend to be affected
more by bugs and tend to want features ASAP. The desire to say "well
this isn't _that_ big a change, and it's been in testing a couple of
days so it's probably fine" is very big.
 I think may have also missed the fact that DSUT _increases_ (to stop
the practice of having 1 update a month for a package, so the user is
forced to get them all or none) with each push from "updates-testing" to
"updates". I find it less believable that packagers will follow that
(esp. considering the above).

>  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)

 While I admit that I made the numbers up, and so am happy to discuss
changing them slightly ... your opinion that there should be a large
class of updates which go directly to stable, with no testing, is IMNSHO
insane.

> * upstream bugfix releases or other large bugfixes: 7 DSUT
> * upstream feature releases of individual applications (where suitable for 
> an update): 7 DSUT

 You have 21 days of testing for the first update, and over a month for
the second ... really?

> * upstream grouped feature releases, e.g. all of KDE (where suitable for an 
> update): 14 DSUT

 Again, that's over a month for the first update and about 3 months for
the second ... I find it hard to believe you are willingly that
conservative.

-- 
James Antill - james at fedoraproject.org
http://yum.baseurl.org/wiki/releases
http://yum.baseurl.org/wiki/whatsnew/3.2.27
http://yum.baseurl.org/wiki/YumMultipleMachineCaching