My roadmap for a better Fedora

[Callum Lerwick]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20081124/a0d72f9e/attachment.bin