Fedora Core 2 wishlists

[Bill Rugolsky Jr.]

On Tue, Dec 09, 2003 at 08:37:43PM +0000, Dave Jones wrote:
> On Tue, 2003-12-09 at 16:35, Bill Rugolsky Jr. wrote:
> 
> > o Ext3 online fs growth (may get merged upstream ...)
> 
> This appeared in Arjan's 2.6 RPM, but I chose not to include
> it in the rawhide kernel. The reasoning behind this was the
> 'Stay close to mainline' objective of Fedora.
> 
> At some point before FC2 beta1, decisions are going to have to be
> made to decide how much we want to deviate away from this goal.
> User feedback is an important factor here. A feature 1-2 people want
> is far less likely to get included than something dozens of folks
> are clamouring for.

On the scale from RH9 kernel <---> "close to mainline", I'd like to
argue for a middle ground for patches that are not intrusive to the point
that they break most other patches.  IMHO, the only thing wrong with 100
bugfix or minor enhancement patchlets is that they aren't being merged
into mainline quick enough.  But if they are orthogonal, I'd rather
see them in there.

E.g., in earlier Red Hat kernels, rmap, O(1)-sched, and the inode shrink
patches led to frequent patching headaches, because they touched central
parts of the core (VM, scheduler, VFS) all over the place. No joy applying
NFS and other fixes.  But I persisted in using the Red Hat kernels as a
base, because I *wanted* the benefits of all of that stabilization work.

The numerous cleanups in 2.5 may have seemingly made this type of thing
less of a problem.  (It seems that Linus v. -mm causes fewer headaches
than -ac ever did).

On the specific issue of Ext3 online resizing, I think that if it
is thoroughly tested, it should go into Fedora, even if Andrew Morton
is in no hurry to merge it into 2.6.

  - Technically, the patch seems rather safe and unintrusive.  The
    crucial step -- inform the kernel about the new block groups --
    is well-localized.

  - Device Mapper is going to make volume management attractive,
    if only for the consistent backups and background fsck.

  - The other journaling filesystems have it already.

> IPMI is part of the standard 2.6 kernel already.

Yup, I meant the userland pieces.
 
> > o Regression Test suite.  Ideally, the user could chose to run
> >   (non-)destructive tests, compare with earlier runs, and optionally
> >   mail or POST the results (including a hardware description) to a central
> >   database.
> 
> Someone else on this list (Xose?) suggested this, and I agree it'd be
> good to have some stress test tools/regression suites. However I can't
> help thinking that they'd belong more in Fedora extras.

It probably ought to start in Extras.  Eventually putting it in Core and
plugging it during installation/upgrade could have good "social
engineering" consequences.  Wouldn't it be nice to have results for
thousands of different configurations in a database?

In years past, Alan Cox acted as that database.

Everyone mailed their problems to Alan Cox, or posted them
on innumerable mail lists. Alan would do pattern recognition across
hundreds or thousands of reports, then chime in with something like
"your foobar IDE drive doesn't work with the B1 revision of the
xyzzy IDE chipset when using bios 2.0.  You can work around it by
upgrading to bios 2.0.3 or booting with kernel parameter bar=baz."

Alas, Alan has a life too, and can't always be there to hold our
hands. 8-P

Regards,

	Bill Rugolsky