Updates (was Fedora 23 Final RC10 status is GO !)

Petr Spacek pspacek at redhat.com
Tue Nov 3 08:26:35 UTC 2015


On 3.11.2015 02:13, Kevin Kofler wrote:
> Michael Catanzaro wrote:
>> Yeah, that's the clear disadvantage. The service pack approach
>> sidesteps that problem: everything still goes out, just not so soon, so
>> everything spends plenty of time in testing. All the bugs still get
>> fixed, just not as fast.
> 
> And that's "better" HOW?
> 
>> (This also solves the problem of maintainers releasing individually
>> -good updates too frequently.)
> 
> What problem? "too frequently" according to whom? I don't see any problem 
> here, and I think updates (especially bugfixes) cannot be frequent enough.

+1 again. If you are not comfortable with updating e.g. every day, just
schedule the cron job to do it weekly/monthly instead of daily. It is
end-user's choice, there is not need to delay updates on distribution's side.

Petr Spacek

>> The counterargument is that we keep seeing major version updates that
>> violate our existing updates policy.
> 
> This means the policy is broken, not the updates. I am glad that we are not 
> following that policy to the letter, that's the only reason the system works 
> at all! We need to encourage pushing new versions unless there is a good 
> reason not to, including, but not limited to:
> * incompatibility with existing data (including documents, config files,
>   savegames, etc.),
> * feature regressions (including deliberately removed features and features
>   missing from a rewrite),
> * major UI changes (but a menu item moving to some other place is harmless),
> * new bugs (known in advance or found during testing) unless outweighed by
>   the bugs that are fixed,
> etc. If none of the above hold, then why would we not let the users benefit 
> from the new features in the new version of the package? Upstream clearly 
> considers it stable or they would not have released it as such.
> 
>> Who if not a neutral party charged with upholding that policy should have
>> the final say? Some maintainers who clearly haven't read it?
> 
> I have read it. I just don't interpret it as being in contradiction with my 
> updates. See e.g. Routino, which only went from 2.7.3 to 3.0 because it 
> added a shared library (which in turn allows building new versions of 
> applications such as qmapshack). The changes to the routing software itself 
> are minor and almost entirely bugfixes. It is also compatible with databases 
> from 2.7.3. (I NEVER push an update of Routino that is NOT database-
> compatible!) I don't see any reason why the update would be a problem.
> 
>> If we have another party approving updates, then it's the maintainer's
>> job to write an argument in favor of releasing the update: a quick
>> summary of what the fix is and the regression potential. If the update
>> gets rejected, the maintainer might really be wrong! and if not would
>> have to try again to explain better. I think this would be good
>> regardless of whether or not we do updates packs.
> 
> I think this would just be added bureaucracy and a royal PITA. Bodhi is 
> already painful enough as it stands!
> 
> If you keep making it harder for packagers to do their job, you will find 
> yourself losing packagers rapidly.
> 
>         Kevin Kofler



More information about the devel mailing list