On Wed, 2008-11-19 at 23:42 +0200, Gilboa Davara wrote: > 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. I don't even think we should be sending people directly to bugzilla in the first place. That's a whole other rant for another message... :) > So, question is: > A. Who will do the heavy lifting of developing such system? Dunno. Whoever feels motivated to do so. :) If I'm the only one who thinks this all is a good idea, so be it. > B. Who will triage 1000's of orphaned bug reports. We already have that problem... Stale bugs get auto closed when the release goes EOL... > > 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. You *already* have to do that to get a bug fixed. It's not a new problem. > Will you roll back all the updates? The "Aunt Tillie" answer would be yes. > Only updates that had -something- to do with the breakage? If the user has some idea of such, they should have this option. > (Let alone kernel updates that can more-or-less > break everything in sight...) How do you mean? There's a reason I said we need a rescue image in /boot... :) > Oh, and what do you do when at least 50% of these updates are > high-priority security updates? Only rollback the non-security updates. If that doesn't work, then roll those back too. Yes, security updates are a bit of a confounding issue, but this is exactly why I say it needs to be per-package rollback. So you can have this kind of selectivity, rather than being forced to roll back the entire transaction. We could split the transaction in the first place. First do only security updates, then upgrade everything else. Then you have two clear points to roll back to. Think of this as a "git bisect" for your entire system. Roll the system back and forth until you figure out what update broke things... > > 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? I avoid vista like the plague so I don't know what you mean here. The idea is to hold the system in a known good state, avoiding a known bad state. As it is now, if I manually "roll back" a package, yum will gleefully upgrade it again unless I remember to put an --exclude on every yum command line or go muck about in the repo files. This is all about simplifying and automating laborious crap I'm *already* doing manually. > > 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) I do believe it was my idea. :) I don't know what you mean by kernel compatability. My whole idea behind the rescue image in /boot is to be exactly like booting a rescue CD. Ideally they should be byte-for-byte identical. The rescue image is set in stone at the beginning of a release. The advantages are: - It's automatically kept up to date with the distribution version. - It's automatically matches the architecture. - A number of my systems don't even have CDROMS, and aren't capable of booting from USB. It would be so nice for a rescue image to just BE THERE when I need it... > > 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. Yeah, it's technically possible but the user interface needs integration and improvement. :) > Yes, but in the is case, the UI has a profound influence on the why > Fedora works. PARSE ERROR? > 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. Actually it was intended to anticipate certain unproductive tangents and nip them in the bud. It seems to have worked.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
