On Wed, 2008-11-19 at 12:38 -0600, Callum Lerwick wrote: > So, many pieces of this have been blabbed about by me and others > recently and in the past, but I think a lot of people aren't seeing the > big picture. I think it's time I fit it all together. > > Problem: Fedora is buggy, and updates are rife with regressions. > > Solution: We need more and wider testing. > > Problem: We need more and wider testing. Why don't we get more testing? > Thw reason *I* don't go out of my way to test updates, is if there's a > regression, it's such a pain in the ass to get the system back to a > known good state and keep it that way, and report a bug. If it's a pain > in the ass for me, it's impossible for Aunt Tillie. > > Solution: > > 1) Make it easy to report bugs. Bugzilla is complex, slow, and > inscrutable. We need to put a simpler layer on top of it. Reporting a > bug should require just a few clicks. It should automatically include > all the information needed for the bug report, the distro version, > package version, arch, and things such as how the Xorg team demands your > xorg.conf and Xorg.0.log. Make finding dupes easier. Collect stack > traces system wide and enter them in a database, which bugzilla can > reference and from which bugzilla bugs can be derived. A system wide > kerneloops. (I know this has been talked about, what's the status?) Agreed. Though you're missing thing - automated bug report system generate -huge- amount of noise. Lowering the signal-to-noise ratio to something usable is -very- labor intensive. Far worse, people (who send such report) tend to forget about them (as opposed to manual bug reports) making them far less effective. So, question is: A. Who will do the heavy lifting of developing such system? B. Who will triage 1000's of orphaned bug reports. > > 2) Make it simple to roll back to a known good state. We need a "system > restore". I know what you're thinking, but our vastly superior, > centralized, system-wide package management (and lack of a whole > seperate "system registry" namespace) allows us to make this actually > work. We need per-package rollback. Period. Assuming, of course, that you can pin-point what exactly broken evolution within the 150 package update push. Will you roll back all the updates? Only updates that had -something- to do with the breakage? (Let alone kernel updates that can more-or-less break everything in sight...) Oh, and what do you do when at least 50% of these updates are high-priority security updates? > > 3) Make it so yum will refuse to upgrade the package rolled back in step > 2 until the bug reported in step 1 is fixed. Say-what?!? Are we building a second Vista here? > > 4) For when things go really wrong, we need a rescue image in /boot. All > the above functionality must be available inside the rescue environment. /+100. Though this idea has come up a number of times before. AFAIR it was dropped due to space considerations and possible kernel-version problems. (In theory, you may need a different rescue image for each installed kernel - unless you plan to keep the original kernel) > > 5) So how do bugs get fixed? Make it easy to cherry pick updates from > updates-testing or even direct from bodhi. How useful is it to blindly > follow every update in updates testing? For most users, it's useless. > Such adventurous people should probably just run rawhide... What we > really need is to make it easy to pick a specific release of an update > to try, such as if a user is directed to in a bug report. A user should > just be able to click on a link given in the bug report and have the > update installed. Available updates and the reasons for them needs to be > more discoverable. Don't forget step #2. Not sure what that means. You can always enable updates-testing and selectively install what you need. > > See how these things build upon and support each other? > > Notice here I'm talking purely about user interface, about the end user > experience. The technical infrastructure follows from this, and I'll > save that discussion for another message. Infrastructure supports > functionality, not the other way around. I don't want to hear any "Oh > but we can't do this because blah blah technical objection blah makes > this hard". I hereby dub this the "Hard problem fallacy". Engineers > solve hard problems, that's what we do. I want to hear "To do this we > need to do x y z". The only objections I will accept are of the form > "You are an idiot and your ideas are stupid. We're not doing this." Yes, but in the is case, the UI has a profound influence on the why Fedora works. On a side note, I'm not sure what you're trying to achieve by this last paragraph. But if you intention was to start yet-another-flame-war, I have a bad feeling you're on the right track. - Gilboa > > I should probably put this on the Wiki so it doesn't get lost... > -- -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
