FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-09-2010, 06:55 PM
Christoph Wickert
 
Default Update policies: What about *regular* updates?

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

How do these fit into the proposed guidelines? Will maintainers be able
to push these updates without having to explain themselves?

Regards,
Christoph

[1] https://fedoraproject.org/wiki/Features/Rakudo_Perl_6



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 08:56 PM
Toshio Kuratomi
 
Default Update policies: What about *regular* updates?

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 10:54 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org