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/MaintainerResponsibilit...
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.