On Sat, 6 Mar 2010 17:25:18 -0500, Orcan wrote: > On Sat, Mar 6, 2010 at 5:16 PM, Christoph Wickert wrote: > > > > +1, Michał! People who want the latest and greatest have already updated > > to F12 months ago anyway, so there is not much use in pushing new > > versions to F11. +1 > Why? I don't want to update/reinstall all my machines every 6 months. > And I expect the same amount of latestness an greatestness from F-11 and F-12. > And I am not alone. (See the discussions in the devel list for the last 2 weeks. > Those discussions have had only few participants. Don't jump to conclusions. It would be mad to throw away all the efforts that have been spent on preparing F-11 and its choice of components. What has been built and tested over several months, should not be replaced by over-ambitious packagers who want to push upgrades to all released dists. While it would be possible to replace *some* packages without the users noticing any difference, replacing larger package sets (not limited to frame-works) bears much more risks. Not only with regard to changed behaviour [and breakage] at run-time, but also related to changing dependencies in a way that might cause chain-reactions. E.g., suddenly you cannot prepare a bug-fix for an App anymore, because its build requirements have changed too much since F-11 release, and perhaps you would need to run with a development snapshot instead. For some packages there are additional dependencies in 3rd parties, and don't forget users and developers. Any incompatibility an update creates is bad. Interrupting the work-flow of distribution users and developers is _bad_. Even an upgrade of a -devel package might change a directory from /usr/include/foo-1.0 to /usr/include/foo-1.0.1 and require a developer to reconfigure and rebuild a working-copy. Of course there are exceptions, where upgrades may be necessary. With the example of Audacious, it would have been a big mistake to push 2.1 (an official "stable" release that F-12 had been released with) to upgrade F-11 which is still at 1.5.1. It has taken many bug-fixes to make 2.1 usable for the majority of bug-reporters on F-12, only to reach a point where upstream decided to release 2.2 (another "stable" release) including rewritten code and API changes, because of memory corruption which they could not locate, and without ensuring that the problem is fixed. And again, 2.2 resulted in bug-reports only after it hit F-12's stable updates repo. So, once released I want to push bug-fix releases quickly. Without arbitrary hurdles, such as an enforced halt in the updates-testing repo, which doesn't help me with improving the software. My reason to comment on those threads on devel list is really just that I want to retain the freedom to decide when my updates are ready to be released. I'm responsible for giving them adequate testing. Users expect the packager not to release broken crap. I don't want to wait for +N karma that previous updates haven't gotten either while new bugzilla tickets have shown that a problem *is* affecting N>1 users. If there are technical requirements for an update to make a temporary halt in updates-testing for a day, e.g. for scripts to be run (and mind you, repoclosure is run on updates-testing, too), fine. I can live with that. Just no silly rules, please, such as arbitrary "autoqa"-scripts getting veto powers to block updates, if perhaps rpmlint complains about a spec file. No experiments, please, just because some packagers are upgrade-mad. > When version X of a software is supported in F-12, the same version X > can be supported most of the time in F-11. And if it can be supported, > it should be supported. "Can be supported" as in "if it builds, push it as an upgrade"? Wishful thinking. This is exactly why Fedora releases are _not_ supported for two years or more. Most package maintainers ought to focus on one dist release (at most two), as their daily usage only covers one dist, too. [The exception being those packagers who *really* run some software on multiple dist releases in the same way.] -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
