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