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
Attachment:
pgpeMKoOOyENH.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel