Check for hardware regression before upgrade

[Laurent Claessens]

Binary package hint: ubiquity

There should be a verification for critical hardware regression before performing an upgrade.

That should be implemented at two levels.

1. The live-CD should check when launching the Ubiquity
2. The upgrade manager should also check it when it upgrade to a new version.

In case of incompatibility due to a regression, the user should be invited to install a previous version, or not to perform the upgrade.

I think that the verification could be very fast : there are not 1000 open critical bugs due to regressions. One just need to compare the result of lspci with a blacklist of hardwares that are impacted by critical regressions. Each of these have to be associated with the name of the last working version of Ubuntu.

For example, due to bug 359392[1], if someone has the Intel chipset GM965/GL960, he has to be invited to install (or remain on) Intrepid before installing (or upgrading to) Jaunty.

[1]https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/359392

[marco.pallotta (marco-pallotta)]

I think it could be a good idea if the verification is done via network connection to a blacklist that could be subjected to modifications. In fact if a critical bugs, due to regressions, is fixed in a certain distro it shouldn' be considered anymore by either Ubiquity or upgrade manager.

[Vincenzo Ciancia (vincenzo-ml)]

Brainstorm is a better place for this:

http://brainstorm.ubuntu.com/

[marco.pallotta (marco-pallotta)]

Vincenzo, maybe you are right even if it's not very clear the difference between posting a wishlist request via launchpad or propose a new idea via brainstorm.
In fact from https://wiki.ubuntu.com/Bugs/CommonTasks you can read, about the wishlist tag,:

Wishlist: a request to add a new feature to one of the programs in Ubuntu.

    * These aren't always bugs, but can be ideas for new features which do not yet exist.

Personally I think a user should use wishlist request via launchpad when he should have to propose simple new features and he should use brainstorm when he should propose new ideas about ubuntu (not simple new features about one single software).

In this case I agree with you that this is an idea more rather then a new feature.

[Laurent Claessens (moky-math)]

I think that this one is the one we are speaking about :
http://brainstorm.ubuntu.com/idea/17218/

So it is already in the brainstorm. I don't know if there is something more to do. I don't think that we should open a new idea in the brainstorm in order to say that one should not only check for blacklist, but also for critical regressions. Seems trivial to me to do both, isn't ?

[Vincenzo Ciancia (vincenzo-ml)]

I think the wishlist tag was more useful before the introduction of
brainstorm; I saw an e-mail around saying that developers would have
implemented features based on votes on brainstorm, after the success of
the similar idea from Dell, so as far as I understand it is no longer
desired to have wishlist bugs; however linking an idea on brainstorm, a
proposed implementation on blueprints and a bug here may be the most
complete way.

[Vincenzo Ciancia (vincenzo-ml)]

They posted it on the xorg bug: http://brainstorm.ubuntu.com/ideatorrent/idea/17218

[Phillip Susi (psusi)]

A blueprint or the mailing list is the place to discuss such an idea. It also isn't really relevant to ubiquity; the update-manager would be the place to do this.