[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel-patch-amd64



On Wed, Jun 30, 2004 at 09:08:18AM +0200, Thibaut VARENE wrote:
> On Wed, 30 Jun 2004 08:30:05 +0200
> "Sven Luther" <sven.luther@wanadoo.fr> wrote:
> 
> > On Tue, Jun 29, 2004 at 11:14:02PM +0100, viro@parcelfarce.linux.theplanet.co.uk wrote:
> > > On Tue, Jun 29, 2004 at 06:23:21PM +0200, Jens Schmalzing wrote:
> > > > I would suggest that you subscribe to debian-kernel, prepare
> > > > kernel-patch-amd64-2.6.7 packages based on the example of the other
> > > > 2.6 kernel-patch packages (right now, this means the powerpc patches,
> > > > so please let me know if you find a better way of doing it) , and
> > > > upload them as soon as amd64 enters sid.
> > > 
> > > Bad idea.  Split the patch and get as much as possible merged upstream.
> > > Note that large parts are simply "Lindent that file" and they certainly
> > > should not be mixed with the rest.
> > 
> > And ? Is that incompatible with making a kernel-patch-amd64 package and
> > building a kernel from it ?
> > 
> > What i really dislike about this politic of submitting stuff upstream,
> > is that we are going all stupid and rigid about it, and totally loosing
> > the interest of our users from our minds.
> 
> I don't think so.
> Getting the patch upstream has several reasons IMHO:

And where did i say it should not go upstream ? The only thing i am
saying is that _IN THE MEANTIME_ there is nothing stopping us from
releasing a kernel-patch-amd64 so users can benefit and test, while we
do the splitting and merging job behind the scene.

> 1) We're applying an opensource scheme: "if you're making changes, send
> feedback upstream so that everyone can benefit of it". We're not willing
> to fork the Linux kernel and make a "Debian kernel", are we?

Who took that decision ? And even then, how would it be all that
different from the many alternative trees out there, like the -mm one
Christoph refered to me recently.

Nothing is stoping us from presenting usefull stuff to our unstable
users while we are still working on it, is this not how free software
works ?

> 2) Getting the patch upstream allows upstream kernel hackers to review
> it. This is of real interest to our users, since we ensure that they
> will have a verified and accepted (read: supported) kernel.

Except that it doesn't always work, often the upstream kernel hackers
don't even care to read the patch and you wait forever for comments.

> Forking the kernel would actually be missing the interest of our users.
> BTW, IMHO that last sentence also applies WRT negative diffs (read:
> removing files)...

Stop being stupid and actually read what i said, and not what you think
i am saynig. I am not speaking about forking, but about making the in
development stages available to our users, and seriously to a compiled
kernel-image user which is what we are speaking about here, the
monoliticness or amount of white space is hardly a consideration.

> I know that we've been having kernel packages rather "different" than
> pristing source (at least for 2.4), and I'm not quite sure that is a
> Good Thing (tm), especially when it comes to arch-dependent bits. (who
> said hppa patch was 700k+? ;)

Well, and ? What is the problem with that, and more importantly, how is
this relevant to the topic at hand. I am _NOT_ against merging stuff
upstream, on the contrary, but am just saying that we should also make
the intermediary steps available to our users while we work on it, a bit
like you kernel guys make the bitkeeper repo available, and are not
stopping people from compiling those versions. 

The main difference is that debian deals with compiled binaries, and not
with source only releases.

> > So what if it is a monolitic patch ? The kernel-patch package gets first
> > prepared, uploaded to svn, and built and uploaded to the archive. Our
> > users wouldn't care less if the patch is monolitic or lot of small
> > files, but they do benefit from having an amd64 kernel. Once that is
> > done, it is easy enough to modify the patch by splitting it or whatever,
> > and merging stuff into the kernel-source package for later inclusion
> > into the main packages, but at least there will be a package available
> > now.
> 
> I do agree that we need to provide our users with good software in a
> timely fashion. "Good" here means "good quality", and that's very
> important as well.

Well, and how do you weight software which is available and of average
quality over software which is perfect but unavailable ?

I still feel that all you kernel gurus, apart from being less than
polite to the remaining of the debian-kernel team in general, don't have
a real feel of what is important for debian. Hell, most of you didn't
even pass the debian maintainer process, and you would dictate to us how
things should be going ?

Friendly,

Sven Luther



Reply to: