Update policies: What about *regular* updates?

[Toshio Kuratomi]

On Tue, Mar 09, 2010 at 08:55:25PM +0100, Christoph Wickert wrote:
> We are talking a lot about update policies recently. While I do (mostly)
> agree with those who suggested a more conservative approach, I wonder
> what will then happen to packages that actually *need* regular updates.
>
Talking about mjg and notting's policies (as discussed in today's fesco) or
the various proposals that broadly fall under Release Lifecycle? Assuming
you mean the latter for now.

> Let me give you two examples:
>      1. openal-soft: Is under steady development and improves a lot.
>         From time to time, I guess once a month, the maintainer pushes
>         an update. Usually this updates fixes at least one bz issue, so
>         I don't think it should be a problem with the new policy. I just
>         want to make sure.

Depends on the policies under discussion.  The current policy says that
a rule of thumb is whether a user has asked for a bug to be fixed or
a feature to be added via bugzilla.  This would fit that bill.

Some of the proposals for update have stated criteria like, only security
bugfixes or only critical bugfixes.  With those criteria, your update might
not fit.

Also note that different proposals have different ways that an update gets
pushed even if it's acceptable to go into the update repo.  That means that
this update might not be stopped but it could require different workflow
like needing to get positive karma or wait for two weeks before going to
stable.

>      2. Parrot/Rakudo: are released once a month. Our parrot feature [1]
>         in F12 not only means to have it in Fedora but to do regular
>         updates each month, because perl developers want to be able to
>         develop for the latest implementation of perl 6 while still
>         having a released version of Fedora as a solid platform.
> 
I can see this being a gray area under the current policy.  There's no
explicit bugzilla submitted but you have a good argument for why people
would expcet and want this.  OTOH, if anyone is silly enough to depend on
the version of rakudo that is released to create a scipt that they depend
on, updates to rakudo could potentially break those... which would fall
under the "prevent regressions" portion of the current policy.

The letter of the current policies I've seen would say no to this as well --
but it should be possible to get an exception under some of those proposals
since there is a reason for it.  OTOH, a policy that explicitly lists this
use case would be better for everyone as it makes it easier for other people
to judge the problem.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20100309/70df6f0e/attachment.bin