FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Development

 
 
LinkBack Thread Tools
 
Old 12-20-2008, 08:29 AM
Alberto Milone
 
Default #1 Complaint about Ubuntu: Updates break things

On Friday 19 December 2008 21:09:01 Cody A.W. Somerville wrote:

> For example, I remember one time an update to the nvidia binary blob

> drivers caused the xserver to fail to start in certain cases. It didn't

> affect the *right* people or *enough* people for it to get the attention it

> deserved. I asked someone about it because I did happen to hear about it

> from one of my friends who I converted to Ubuntu and was told that by

> whoever uploaded it that they had heard about cases where that was

> occurring but there were no plans for remedial action.

>

> Pushing updates to -updates is so much riskier than people realize due to

> the massively different amount of QA resources invested in -updates

> compared to testing the development release. Often times, breakages only

> affect a subset of people using Ubuntu or it causes a problem and a lot of

> folks are savy enough to work around it or know someone who is. However,

> people get fed up and tired of having to fix things after updates and turn

> away from Ubuntu; an undesirable conclusion to say the least.



As regards the Nvidia binary drivers, I agree with Bryce. There's very little QA the SRU team can do apart from checking the packaging and from reading the feedback that the packages receive when they are in -proposed.



I am aware of the fact that with every update there's a risk of regressions for specific hardware configurations (i.e. not only the graphics card but also the BIOS, etc.) therefore I would like to propose using -backports instead of SRUs to update binary drivers in stable releases. This means that users won't get new releases of the drivers unless they enable the backports and therefore they will be (by default) less exposed to regressions. SRUs should be used when there's a bug in the packaging or when there's a known security flaw in the driver (this could cause regressions too as we couldn't separate the security fix from other changes in the driver).



This approach has at least one drawback though. Do we really want users to keep the backports enabled all the time? It would be nice if users had an easy way to tell Update Manager to update only binary graphics drivers from the backports as I'm convinced that many users want a stable environment (i.e. no other backported packages) with extended hardware support (e.g for the latest card models) or with increased performance or simply with bugfixes in the graphics driver.



What do you think?



Regards,



Alberto Milone
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 12-20-2008, 11:33 AM
Mario Vukelic
 
Default #1 Complaint about Ubuntu: Updates break things

On Fri, 2008-12-19 at 14:23 -0600, Justin Dugger wrote:
> Normally, I'd cite something about anecdotal evidence and whatnot, but
> if I remember correctly, this is the case that led to the creation of
> -proposed. That would be remedial action, no?

>From my experience as a user, I do not think that -proposed suffices. I
do enable it in order to check for issues in an effort to help, but ...

* From what I see on the -users list, very few people do the same,
even those with a clue. If that is a correct assumption, then
-proposed still offers little testing.
* The real update often comes *very* soon after hitting -proposed.
I ran into several cases where an update in -proposed caused me
a subtle issue, but by the time I noticed and figured out enough
details to write a bug report, the update had already been
pushed out to everyone.


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 12-20-2008, 04:50 PM
Kees Cook
 
Default #1 Complaint about Ubuntu: Updates break things

On Fri, Dec 19, 2008 at 08:57:58PM -0500, Cody A.W. Somerville wrote:
> To start the ball, I'll throw an idea out: the introduction of multi-tier
> system that would classify an update based on an agreed set of quantitative
> and qualitative criteria such as where the component falls in the stack (ie.
> distinction between the kernel, desktop environment, and an application),
> popcon score, etc. etc. Each tier would demand a different degree of
> testing, verification, time in -proposed, sign off from different parties,
> etc. That way we ensure appropirate people are looking at the SRUs,
> appropriate testing is occuring, and appropriate happiness is occuring!

Regressions are avoided by a larger variety of people doing testing.
Not enough people currently give feedback on -proposed. Adding tiers
to -proposed would reduce the number of people testing each tier. I think
this would result in a net loss.

I would propose that increasing the number of people giving feedback on
-proposed would be the better solution. I don't have a specific plan
for how to implement that, but it seems that a tighter communication loop
between people using -proposed, LP, and a log of what they've installed
and when (some kind of additional bug-filing wizard) could reduce the
technical knowledge needed to provide useful feedback on proposed.
And let them revert/blacklist an update easily.

--
Kees Cook
Ubuntu Security Team

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 12-21-2008, 09:06 AM
"Timo Jyrinki"
 
Default #1 Complaint about Ubuntu: Updates break things

2008/12/19 Cody A.W. Somerville <cody-somerville@ubuntu.com>:
> For example, I remember one time an update to the nvidia binary blob drivers
> caused the xserver to fail to start in certain cases. It didn't affect the
> *right* people or *enough* people for it to get the attention it deserved.

This reminds me of another problem:

A friend of mine upgrade 8.04 LTS with latest stable updates, but one
download did not succeed. Update-manager asked if to continue or not
despite this, and she answered Yes because there was no indication it
would be potentially harmful (not taking into account that most people
would not read the dialog carefully anyway). It turned out the one
not-downloaded file was (probably) fglrx/linux-restricted-modules, but
otherwise the kernel was upgraded, and the next boot (and the
following) ended in compiz white screen of death. Dunno why compiz did
not fallback to metacity, but system basically became non-functional
for the ordinary user (I knew to press Alt-F2 and start metacity).
Probably even recovery so that "ati" would be used would not have
helped since there is some weird problem with the card and the NVIDIA
motherboard so that only fglrx really seemed to work.

I think it's relatively common that because of some network problem
(on ubuntu servers or otherwise) one or more packages fail to
download, and it might cause severe breakage. Should the
update-manager actually disallow installing packages if not everything
was downloaded, or at least default to No much more with more
indicative warning that system might break?

Maybe also apt should be configured to be more fault-tolerant and
retry a couple of times each failed package later on in the process.

-Timo

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 12-21-2008, 04:27 PM
"Cody A.W. Somerville"
 
Default #1 Complaint about Ubuntu: Updates break things

On Sat, Dec 20, 2008 at 12:50 PM, Kees Cook <kees.cook@canonical.com> wrote:

On Fri, Dec 19, 2008 at 08:57:58PM -0500, Cody A.W. Somerville wrote:

> To start the ball, I'll throw an idea out: the introduction of multi-tier

> system that would classify an update based on an agreed set of quantitative

> and qualitative criteria such as where the component falls in the stack (ie.

> distinction between the kernel, desktop environment, and an application),

> popcon score, etc. etc. Each tier would demand a different degree of

> testing, verification, time in -proposed, sign off from different parties,

> etc. That way we ensure appropirate people are looking at the SRUs,

> appropriate testing is occuring, and appropriate happiness is occuring!



Regressions are avoided by a larger variety of people doing testing.

Not enough people currently give feedback on -proposed. *Adding tiers

to -proposed would reduce the number of people testing each tier. *I think

this would result in a net loss.
It would be a net loss if it were to work the way you describe. -proposed would not be tiered, the classification of an SRU would be. The classification would dictate the amount of testing required before being deployed to -updates, that way we can ensure that riskier SRUs *do* get the right people and the right number of people looking at them.

*I would propose that increasing the number of people giving feedback on

-proposed would be the better solution. *I don't have a specific plan

for how to implement that, but it seems that a tighter communication loop

between people using -proposed, LP, and a log of what they've installed

and when (some kind of additional bug-filing wizard) could reduce the

technical knowledge needed to provide useful feedback on proposed.

And let them revert/blacklist an update easily.
Improved tools is an excellent idea.
*




--

Kees Cook

Ubuntu Security Team


Cheers,
--
Cody A.W. Somerville
Software Systems Release Engineer
Custom Engineering Solutions Group
Canonical OEM Services
Cell: 506-449-5899
Email: cody.somerville@canonical.com


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 12-21-2008, 10:41 PM
Martin Pitt
 
Default #1 Complaint about Ubuntu: Updates break things

Bryce Harrington [2008-12-19 12:44 -0800]:
> When did this happen? I cannot recall ever seeing a binary X driver
> update accepted by the SRU team.

That was actually the case twice in intrepid so far (for
nvidia-graphics-drivers-{96,177}. Due to the nature of these drivers,
there are often regressions for particular cards between Ubuntu
releases, and then dozens of people start yelling "OMG how can you not
update this, it's working perfectly". And Bryce is right, we can't do
much else than rely on broad testing, since we can't control the
changes to those drivers. Proprietary driver updates haven't happened
to hardy yet.

As a general explanation about the frequency of updates: Intrepid was
such an exceptionally buggy release again, mostly because it just got
3 months of attention from many core devs (many were involved fulltime
for working on 8.04.1). So it was the counterpart to edgy, and many
bugs were so bad that they fulfilled the SRU filter without any
problems. Due to many people still being on intrepid, we have allowed
more SRUs right after the release than usual. It will go back to normal now.

If updates really cause so much grief, we should indeed move to a more
strict SRU practice again. However, a general comment "SRUs suck"
isn't helpful at all. We have never pushed anything to -updates with
at least one third party confirming that the update still works, and
we do have quite a bunch of people testing -proposed (which can be
seen from the number of bug reports we get if something in -proposed
actually reportedly breaks, which fortunately is very rare from my
perspective).

So I do appreciate the general feeling that SRUs have to become
stricter again, and we have to resist the urge of people wanting their
latest bug fixes in. But for actual regressions we need much more
detailled feedback.

Thanks, and Merry Christmas!

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 12-21-2008, 10:46 PM
Martin Pitt
 
Default #1 Complaint about Ubuntu: Updates break things

Martin Pitt [2008-12-22 0:41 +0100]:
> So I do appreciate the general feeling that SRUs have to become
> stricter again, and we have to resist the urge of people wanting their
> latest bug fixes in.

... speaking of which, this hit -discuss just two hours after your
post:

https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-December/006475.html

While the tone certainly leaves something to be desired, and I don't
agree to Thomas' attitude nor proposal, he is right in the sense that
some bugs *are* major regressions, and absolutely need to be fixed in
stable releases.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 12-29-2008, 05:06 AM
Philip Wyett
 
Default #1 Complaint about Ubuntu: Updates break things

On Sat, 2008-12-20 at 09:50 -0800, Kees Cook wrote:
> On Fri, Dec 19, 2008 at 08:57:58PM -0500, Cody A.W. Somerville wrote:
> > To start the ball, I'll throw an idea out: the introduction of multi-tier
> > system that would classify an update based on an agreed set of quantitative
> > and qualitative criteria such as where the component falls in the stack (ie.
> > distinction between the kernel, desktop environment, and an application),
> > popcon score, etc. etc. Each tier would demand a different degree of
> > testing, verification, time in -proposed, sign off from different parties,
> > etc. That way we ensure appropirate people are looking at the SRUs,
> > appropriate testing is occuring, and appropriate happiness is occuring!
>
> Regressions are avoided by a larger variety of people doing testing.
> Not enough people currently give feedback on -proposed. Adding tiers
> to -proposed would reduce the number of people testing each tier. I think
> this would result in a net loss.
>
> I would propose that increasing the number of people giving feedback on
> -proposed would be the better solution. I don't have a specific plan
> for how to implement that, but it seems that a tighter communication loop
> between people using -proposed, LP, and a log of what they've installed
> and when (some kind of additional bug-filing wizard) could reduce the
> technical knowledge needed to provide useful feedback on proposed.
> And let them revert/blacklist an update easily.
>
> --
> Kees Cook
> Ubuntu Security Team
>

On the help server and team wiki each have pages that deal with
sru/proposed updates.

https://help.ubuntu.com/community/UbuntuUpdates
https://wiki.ubuntu.com/StableReleaseUpdate

Detail via these pages into what packages are being tested at a given
time or are even available to be tested is zero let alone on the bugs
that are being tested as fixed.

The most valuable page I visit daily that is not linked on either of
these pages and maybe should be is:

http://people.ubuntu.com/~ubuntu-archive/pending-sru.html

Also adding a links to subscribing to the <distro name>-changes lists
may also help in increasing traffic and testers.

Regards

Phil
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 12-29-2008, 06:35 AM
Martin Pitt
 
Default #1 Complaint about Ubuntu: Updates break things

Alberto Milone [2008-12-20 10:29 +0100]:
> This approach has at least one drawback though. Do we really want users to
> keep the backports enabled all the time? It would be nice if users had an easy
> way to tell Update Manager to update only binary graphics drivers from the
> backports as I'm convinced that many users want a stable environment (i.e. no
> other backported packages) with extended hardware support (e.g for the latest
> card models) or with increased performance or simply with bugfixes in the
> graphics driver.

That's actually possible if you enable *-backports only for
restricted, but not for main/universe.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 
Old 12-29-2008, 02:43 PM
Alberto Milone
 
Default #1 Complaint about Ubuntu: Updates break things

On Monday 29 December 2008 08:35:21 Martin Pitt wrote:

> Alberto Milone [2008-12-20 10:29 +0100]:

> > This approach has at least one drawback though. Do we really want users

> > to keep the backports enabled all the time? It would be nice if users had

> > an easy way to tell Update Manager to update only binary graphics drivers

> > from the backports as I'm convinced that many users want a stable

> > environment (i.e. no other backported packages) with extended hardware

> > support (e.g for the latest card models) or with increased performance or

> > simply with bugfixes in the graphics driver.

>

> That's actually possible if you enable *-backports only for

> restricted, but not for main/universe.

>

> Martin



Yes, I was thinking of the options available in the UI of "Software Sources" which currently allows users only to enable the whole backports:

http://albertomilone.com/ubuntu/software_sources.png



Maybe another option (a checkbox) could be added to the UI e.g. "Unsupported proprietary drivers updates (jaunty-backports restricted)" or something more intelligible.



If there's enough interest I can provide a patch for this.



Regards,



Alberto
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
 

Thread Tools




All times are GMT. The time now is 04:05 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org