Talk:Critical Path Packages Proposal

• User:Bruno: What do you mean by graphics? A graphical desktop? If so, are you looking at particular ones or is having any one of the desktops work OK? Even without a desktop it isn't that difficult to deal with problems if you can use a vt. If you mean graphics drivers, good luck trying to QA that in a reasonable amount of time.
  • User:Bruno: This was clarified in IRC. It means X + subset of video drivers. This is needed for the anaconda desktop which is required for some languages to be displayed.

• --Dmalcolm 19:29, 10 June 2009 (UTC): proposal: I'd prioritize the packages involved in these three workloads; if these don't work, the system is in an unfixable state for a large subset of users:
  • booting the system into runlevel 3, logging in as root, and executing shell commands:
    • need a bootable kernel, bash, etc
    • if this doesn't work, the system is essentially broken, and the number of components that need to work is relatively low
  • "yum upgrade" and "rpm" from textmode in runlevel 3
    • need a working rpm, python, yum, wired networking
    • if this doesn't work, repairing the system becomes significantly harder
  • booting the system into runlevel 5 and logging in via gdm as non-root, launching firefox, performing a web search
    • builds on the various runlevel 3 components, plus needs some subset of GNOME to be functional, and need X to come up
    • not being able to do this makes repair very hard for a large subset of users (how do you look how to fix an error if your only computer is unable to perform web searches? etc)
    • I'm choosing GNOME and Firefox here because they are the defaults
  • skvidal segmenting this selection of packages doesn't really help. All the critical path packages will have a more stringent set of requirements applied to them. Breaking them up into separate groups doesn't really help us.
    • --Dmalcolm 16:11, 23 June 2009 (UTC): I disagree. I'm not trying to come up with separate groups of packages, I'm trying to come up with (i) justification for which packages should be on the critical list, and (ii) an empirical way of testing whether a candidate package update is "safe". The list would be the union of the packages that can break the 3 workloads. I'm approaching this from the POV of testing: I don't think you can say that "a package works", you can merely say that a particular workload works. i.e. an empirical approach. Otherwise, you'll never be able to draw the line, and the list of critical packages will gradually grow, either making the distinction meaningless, or a clique. The other thing is that if you focus on individual packages, your testing will always be hamstrung. You have to to perform integration testing on specific workloads at some point, or your testing is incomplete.
• katzj It's unclear if the scope here is just updates or rawhide + updates. The dependence on bodhi in various points makes me think the former, but a few other things make me think the other.
  • notting It's for both the pre-release rawhide and for updates. It ties into the 'multiple rawhides' proposal as well.

• markmc How about widening the scope of packages included after we freeze, maybe incrementally widening it as the release comes closer?
  • skvidal The whole point of this is we won't be freezing all packages very often (if at all). The critical packages will have to go through more checks b/c they are the ones that are important to keeping a system running and making sure you can install/update other packages.
    • [[User:Markmc|markmc] 'Packages within the "critical path" have extra requirements on getting tagged for freeze breaks' - my point is that closer to a release, more packages should have these extra requirements imposed on them; e.g. the set of packages that need extra checks before being pulled into rawhide is a subset of the packages that should get extra checks before being tagged post-freeze.

Spins

User:Kanarip

• In the category of Spins, I am sure there is a valuable critical path for us to accomplish, but I'm also sure that there is not enough capacity within the SIG to keep track of every single change all by itself. We currently have 3 active members, which is insufficient to track dependency changes and package changes over x+y packages, I think. Could these packages for the Spins critical path just be included in the main critical path? Should they? What's included in the critical path for, say, the games spin? Not all games, I would assume, right?
  • skvidal We talked about this on wednesday. In short - Spins will have to keep an eye on their own critical path packages. We cannot be responsible for every spin and every package.