On Thu, 2009-01-29 at 13:45 -0800, Toshio Kuratomi wrote: > Michael Schwendt wrote: > > On Wed, 28 Jan 2009 12:14:48 +0000, Mark wrote: > > > >> Okay, here's an attempt: > >> > >> https://fedoraproject.org/wiki/User:Markmc/Draft_package_update_guidelines > >> > >> Cheers, > >> Mark. > > > >> = Package Update Guidelines = > > > >> == Maintaining Stability == > > > >> == Update Descriptions == > > > >> == Rate of Updates == > > > > Much better, an effort much appreciated, although this is way beyond > > the subject of this thread. ;) Such a document goes into the right > > direction, since it tries to explain Fedora's fundamental update > > strategy and may come as a surprise to some packagers. It will be very > > interesting to hear what FESCo members think about the contents. > > > +1 > > There's two grounds on which to discuss this: > > 1) The tone and scope of the document. I think this gets that spot on. > It explains what we're trying to achieve with updates rather than how > to achieve it. There are examples of why doing something is good or bad > but leaves the final judgement up to the maintainer and the cases they > need to solve. Thanks. > 2) The philosophy. Do we agree with the goals that are expressed here? > The document is asking that maintainers limit the number of updates > that they do for end user benefit. Others have said that they use > Fedora precisely for the number of updates that are issued. Is one of > these the true goal that represents 90% of our opinions? Do we want to > try to give a place to both sides? By the way, the first and last sections are just an elaboration of: https://fedoraproject.org/wiki/PackageMaintainers/MaintainerResponsibility#Maintain_stability_for_users Basically, I thought the "update description" bit needed the context of the existing philosophy with Fedora updates, so I fleshed out those sections from the only existing text I found. > Myself, I like running a system that gets frequent updates but I'm > willing to curb the number of updates I issue to users. I'd probably > push packages to updates-testing and let them site there without going > to updates without a user request/good reason if that fits into the big > picture. updates-testing could do with some discussion too - I think we need to take more care with updates-testing than with rawhide, for example. Testers of updates shouldn't be subject to completely untested updates. i.e. if you've got a big, potentially very broken re-base to a new upstream it would be a good idea to test locally, then push to rawhide for a while, then updates-testing for another while and, finally, push to updates. This clearly doesn't apply to some packages, though - e.g. if there was a new upstream gcalctool release that fixed some bug, you might even push that straight to updates-testing without testing locally. Again the common sense thing. Cheers, Mark. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
