Unhelpful update descriptions

[Vít Ondruch]

Dne 14.3.2013 10:43, Jaroslav Reznik napsal(a):
> ----- Original Message -----
>>> unlike other major distros, other updates have less helpful
>>> descriptions:
>>>
>>> * "Update to latest upstream version"
>>> * "No update information available"
>>> * "Here is where you give an explanation of your update. Here is
>>> where
>>> you give an explanation of your update."
>>>
>>> Perhaps the update policy should have a guideline on the minimum
>>> amount
>> Or maybe the question should be: "should we be pushing this many
>> updates for stable releases?" I was running Fedora 17 on a laptop
>> till
>> a couple weeks back and I kept getting nagged by PackageKit every
>> other evening. Atleast twice a week.
> That's more problem of how we treat our stable releases.
>
> Take Fn-1 - it's almost dead, nearly nobody cares about it anymore
> (as bugfixes/backporting are costly), and I'd say with our ability
> to push security updates... It's non sense to have it as supported
> release.
> Take Fn - some teams are trying to mimic Rawhide-like style, some
> teams are not touching it even with stick and would ban any update,
> so currently it's mix of Fn-1 and the idea how should Rawhide look
> like.
> Take Rawhide - we are now trying to solve how to make it usable for
> developers, not talking about users... The idea during the stable
> craziness was to make it usable and replacement of Fn for people
> who wants live release, it did not happen (yet).
>
> => no flexibility, no way how to make different users happy, more
> way how to make unhappy everyone, as it's really not clear what
> should look like). Yes, you can enforce no updates policy, but
> take a look above...
>
> My idea was (and still is) - use these three levels! Fn-1 supported,
> stable release, updates in batch (where and when it makes sense) +
> make sure security updates lands on time. Fn as a living release,
> slowing down before it becomes Fn-1. So we can release our hands
> trying make Rawhide replacement for alive release and make sure
> it's usable for development. It also makes more seamless transition
> between releases (what Spot wants to solve with different release
> numbering - as we really fail there - we care about not touching
> stable release and then we push on users massive changes with a
> new release). And yes, otherwise it does not make sense to
> have two stable (and mostly stalled and dead releases as written
> in policy). Let's use this opportunity (and no, it's not LTS proposal,
> maybe it sounds a little bit Debianish ;-).
>
> Jaroslav
>
>

It seems to be that you contradict to what update policy suggest [1]. 
Let me quote:

 > we should avoid major updates of packages within a stable release. 
Updates should aim
 > to fix bugs, and not introduce features, particularly when those 
features would materially
 > affect the user or developer experience. The update rate for any 
given release should
 > drop off over time, approaching zero near release end-of-life; since 
updates are primarily
 > bugfixes, fewer and fewer should be needed over time.

I read it in short as "no updates except bugfixes". So if Fn-1 is almost 
dead, it is by Fedora policy, not by non-willingness.

For me, it is fine to do one update to Fn+1 every half year and then 
just get bugfixes. And I believe it is pretty sensible.


Vít


[1] http://fedoraproject.org/wiki/Updates_Policy#Philosophy