On Mon, Mar 08, 2010 at 06:28:45PM -0500, Martin Langhoff wrote:
> On Mon, Mar 8, 2010 at 4:59 PM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote:
> > The future
> > ----------
> >
> > Defining the purpose of Fedora updates is outside the scope of Fesco.
> > However, we note that updates intended to add new functionality are more
> > likely to result in user-visible regressions, and updates that alter ABI
> > or API are likely to break local customisations even if all Fedora
> > packages are updated to match.
>
> Thanks to you, Fesco and all developers working on this. There is
> something that everyone seems to be missing on this track, and I'd
> like to bring some attention to it.
>
> Distros do integration work, and the main thrust of the QA work around
> a release is that all the packages work nicely _together_, that all
> the subtle interactions interact the right way.
>
> Updates are always risky. There is no doubt that the updated package
> worked fine for the maintainer, and yet we see updates bombing out
> spectacularly relatively often. This is because pushing out a single
> package update is what a maintainer does, but this "package focus"
> undermines what the distro does -- _integration_.
>
> Small, low-risk bugfix updates respect that distro-wide goal. Major
> risky updates disregard that goal -- yes, a specific package is new!
> improved! but the implicit social contrct with your end users ("a
> nicely integrated OS") is broken because the time and effort to shake
> out the subtle integration issues were skipped.
>
There are seveal things to note, though.
* The dnssec update which prompted this policy was not actually a problem of
integration with the rest of the OS.
* The policy doesn't place any value on the types of updates that are made,
therefore it is only making an indirect change to integration. For
instance, KDE updates that have been talked about elsewhere would likely
still go throguh as they enjoy widespread testing as part of the KDE SIG.
> >From an OLPC PoV, major updates are rather troubling. We put together
> two OSs based on Fedora (XO and XS OSs). We test the integrated OS
> quite a bit ("we" being an outstanding team of volunteers around the
> world), and we override a few packages, some of them very tightly
> coupled to the platform (that is -- likely victims of subtle
> interactions that may go haywire on a major update).
>
> Given that, wearing my "XS lead dev" hat, I hope that Fedora focuses
> its "update" policy on the safe, sane, low-risk bugfixes. Otherwise,
> downstream projects that do careful QA are between a rock and a hard
> place -- between taking potentially exploding updates or ignoring
> updates altogether... and missing out on important bugfixes.
>
This is an incomplete look at the picture. If you stop large and complex
bugfix updates for fear of what they do to integration at the Fedora level,
then OLPC will still miss out on the important bugfixes in their derived
distros. If they pull in the bugfixes becausee they deem them worthy
enough, then why shouldn't Fedora have shipped them in the first place and
let OLPC exclude them?
The Fedora maintainers need to judge whether a large and complex update
makes the user's experience enough better (for instance, by fixing a large
number of bugs or enough important bugs) that they should perform the
update. OLPC maintainers can decide whether they have the same values as
the Fedora maintainer. In no case can either Fedora or the OLPC maintainer
abandon their evaluation of the risks and rewards of consuming updates --
it's just a matter of whether the downstream has to package the update
themselves or exclude the update that was provided.
-Toshio
Attachment:
pgp8NLi5UUNoF.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
