From Fedora Project Wiki
- 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.
- User:jkeating Ok, I think we were confusing what you were proposing. If you just take your last workload, booting to runlevel 5 and logging in as non-root, launching FF, and add to it getting updates, you've already included all the previous workloads and thus defined your critical path. I think we were confused as to why you would list them in three different steps when really the last step includes the previous ones. I also agree that testing should be based on functionality, but at some point we have to track that functionality back to a set of packages (and maintainers) that would require the special treatment.
- --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.
- booting the system into runlevel 3, logging in as root, and executing shell commands:
- 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.
- 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.
- don't forget that modern apps like anaconda and gdm depend on fontconfig fonts. They are provided by the @fonts group which is mandatory for GUI stuff. It's long been split out from the x groups, (the fonts in the x groups is legacy stuff not really useful nowadays but that no one dares cleaning up)
NicolasMailhot 21:50, 23 June 2009 (UTC)
Spins
- 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.
Critical Path Comps Groups
IMHO it is a very annoying idea to use the core group as a critical path group, because it makes selecting all critical path groups more complicated and unintuitive. E.g. on fedora-devel I assumed that all critical path updates can be installed using yum groupinstall critical-path\* and nobody objected. But with using the core group, it has to be yum groupinstall critical-path\* core. Therefore please use a critical-path-core group that contain all the core packages. --Till 08:31, 4 July 2010 (UTC)