Re: Debian kernel: various issues to discuss
Hi,
Martin Michlmayr writes:
> Some of the issues we'll have to think about are:
Right. Here's my 2 cents.
> - what kind of version control system are we going to use, how are
> uploads coordinated?
I don't care much, not being particularly familiar with either arch or
svn. If you ask me, it's cvs, but that has become unfashionable of late.
> - [...] I have to remind you to be gentle to each other
On a Debian mailing list? Come on...
> - We should try to have similar kernel config files on different
> architectures (except for arch specific stuff, obviously). We
> should also discuss whether we should move towards using initrds on
> more platforms, and where they'd be useful.
Sven and I implemented both for the 2.6 PowerPC kernel packages. The
.config files are assembled from stubs, the largest of which is used
in all .config files. The kernel are initrd kernels, but need to
support more subarchs - currently they work on pmac and chrp.
> - Regression test suites: [...] I think this is really important
> to have, and I can certainly try getting hardware for this purpose.
What kind of hardware are we talking about? The PowerPC kernel could
in fact use a dedicated system for both testing and building. For the
latter, we are now using a Dual G5 that is actually a Photoshop
workstation, and requires physical access to use Debian. For the
former, IMHO nothing beats a collection of many vastly different
machines.
> - We'll need to figure out how to handle different architectures.
> Can all of them be built from one tree, or is this not possible.
> We had discussions about moving to one tree in the past, but then
> people thought it was too hard and gave up. I think we can only
> experiment to see if it's possible.
I still believe that building all kernel-image packages from the same
source will result in a monstrosity of a source package, slow down
development, and unnecessarily reduce flexibility. However, I'm all
for checking the Debian specific stuff (patches, configs, and debian/)
into one tree, so it becomes easier to review arch-specific patches
side by side, streamline .config files, unify the build structure and
so on.
Regards, Jens.
--
J'qbpbe, le m'en fquz pe j'qbpbe!
Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj!
Reply to: