My roadmap for a better Fedora

[Callum Lerwick]

On Wed, 2008-11-19 at 11:46 -0900, Jeff Spaleta wrote:
> 2008/11/19 Callum Lerwick <seg at haxxed.com>:
> > There are many options here.
> >
> > 1) Ban everything that breaks rollbacks. Find some other way to do it.
> 
> these features were implemented for a reason. You grossly oversimplify
> the problem by saying "find some other way to do it."

And I think you're making things out to more complex than necessary.

> > 2) Just refuse to rollback the packages that break rollback.
> 
> How do you know they will break roll back? How do you test rollback in
> an organized way?

With automated regression tests.

> >
> > 3) A combination of both
> >
> > This is an example of where we need specific examples of scripts and
> > such that break rollback to get any farther on this.
> 
> Since noone tests for rollback there are no obvious examples of known
> rollback breakage. We don't look..we don't test... so we don't know
> what currently breaks. You'd have to take each special case...and
> attempt to trigger the condition and test for differences.  But since
> we are talking about scripted actions which could literally do pretty
> much anything...how do you set up a test which attempts to measure
> whether rollback across a trigger boundary put you back to where you
> were? How much of a different in state counts as 'break rollback'?

Well then we start testing...

Make up a copy-on-write VM image containing a stock Fedora release,
upgrade it with all current updates, then roll it all back. Diff the
filesystems before and after. Analyse the differences. Do this test
between release and updates-testing, updates and updates-testing, etc...

This will quickly give us a pretty good idea of the true extent of the
problem.  Of course, this requires developing a rollback mechanism to
test in the first place...

If this ever goes anywhere, we could have an automated system to test
rollback of all updates before they even get pushed in to
updates-testing.

Also note my reply to Ralf, I do not expect this mechanism to work
across releases.

> And then there are obsoletes. How many new obsoletes do we introduce
> in updates? Any idea? a run of repoquery against the f9 release and f9
> updates tree would be able to tell us that. When an obsolete is
> introduced in an update... can we rollback and get what we had?

Well presumably the rollback mechanism would have to keep some kind of
transaction journal anyway, log the obsoletes in the journal, and
reverse them upon rollback. "Undo" is not a new area of computer
science.

> > Is rollback a desireable feature?
> 
> That's a horrible pointless question.

On the contrary, it gives me insight into your motivations. Going in to
technical detail is an unproductive sidetrack if you're not even
understanding why I think it's such a vital feature. Such a feature is
going to require a coordinated effort across the distribution, without
the unanimous support of FESCo and board members like you, the effort is
doomed to failure...

I posted my motivations here:

http://www.redhat.com/archives/fedora-devel-list/2008-November/msg01387.html

I don't know what more I can say than that...

> There are many features which
> are desirable..but not necessary easily compatible with each other.
> Drop dead easy smooth upgrades are not necesssarily going to be
> compatible with rollback.  So the right question is.... is rollback
> more desirable than other packaging features.

Well my argument here is the alternative is getting stuck with a broken
system. A broken system is as undesirable as it gets. A broken system
makes any other feature you can name a rather moot point...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20081124/b0644d45/attachment.sig>