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@xxxxxxxxxxxxxxxxx http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
