Re: Another great update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux