[Bug 236152] Re: suggestions for harder access to -proposed repositories

[Brian Murray]

*** This bug is a duplicate of bug 1604705 ***
    https://bugs.launchpad.net/bugs/1604705

** This bug has been marked a duplicate of bug 1604705
   Don't scare users who want to use -proposed

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to update-manager in Ubuntu.
https://bugs.launchpad.net/bugs/236152

Title:
  suggestions for harder access to -proposed repositories

Status in update-manager package in Ubuntu:
  Triaged

Bug description:
  Currently, any user gets exposed to all of hardy-proposed with one
  click. Current examples of why they do this includes (for hardy)
  virtualbox-ose modules for -17 kernel, and firefox3rc1 - both very
  popular, the former currently being broken if you have hardy-updates
  enabled.

  There are several solutions I think would be much better:

  A) Make hardy-proposed similar to debian experimental in terms of
  access. As you may know, unless you know what you're doing, you can't
  access experimental unless you do so explicitely.

  With this example, users should be forced to do things like 'sudo
  aptitude -t hardy-proposed install firefox-3.0 - thus touching nothing
  else in that section. Personally I think this would be the best
  solution.

  (The following solutions are related to updates-manager, but might be
  better - obviously QA is required so making it that hard might be
  bad.)

  B) There could be modifications made to updates-manager that, when
  enabling hardy-proposed, any updates related are automatically
  unchecked, and the user must then explicitly select the packages they
  actually enabled it for. Perhaps there could still be an "enable all"
  in the proposed sections header?

  C) You could simply have updates-manager ignore hardy-proposed, and
  force the user to use tools like aptitude to actually install from it.
  This is for similar reasons as (A) in that it adds complexity to
  accessing the packages, and it might be the easiest to implement. This
  has the nice side effect of being very common to those you want
  performing QA.

  D) You could have update-manager act more like aptitude safe-upgrade,
  not capable of removing packages at all unless explicitly instructed
  (similar to current prompts for distro upgrades maybe?)

  Of course, in an ideal world, no one would use hardy-proposed at all
  if they weren't knowledgeable about the ramifications. In a slightly
  less ideal world, everyone using hardy-proposed for specific reasons
  would be told to disable it when they're done. This of course isn't an
  ideal world though.

  Proposed is a playground for QA for the next hardy point release, its
  reasons are well intended, but something has to be done for users that
  are told to use hardy-proposed and aren't knowledgeable with the
  system. I don't think developers should have to worry about what
  they're uploading to hardy-proposed - it's supposed to break, else QA
  is no fun at all... but it should take more steps to ensure it's not
  breaking peoples systems that do not know how to rectify issues.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/236152/+subscriptions