On Wed, 30 Jun 2004 08:30:05 +0200
"Sven Luther" <firstname.lastname@example.org> wrote:
> On Tue, Jun 29, 2004 at 11:14:02PM +0100, email@example.com 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:
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?
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.
Forking the kernel would actually be missing the interest of our users.
BTW, IMHO that last sentence also applies WRT negative diffs (read:
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+? ;)
> 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
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.
The PA/Linux ESIEE Team