----- 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 > > > Cheers, > Debarshi > > > -- > If computers are going to revolutionize education, then steam engines > and cars > and electricity would have done it too. -- Arjun Shankar > > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
