Draft: simple update description guidelines
Mark McLoughlin
markmc at redhat.com
Fri Jan 30 08:19:19 UTC 2009
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.
More information about the fedora-devel-list
mailing list