[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Draft: simple update description guidelines

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.


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


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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]