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

Re: Bug#219582: ITP: linux -- Linux 2.4 kernel

On Fri, Nov 07, 2003 at 10:20:25PM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Fri, Nov 07, 2003 at 04:22:27PM -0500, Daniel Jacobowitz wrote:
> > Then how do you suggest maintaining a kernel 2.4.20 for one
> > architecture and a 2.4.22 for another architecture, when you can't even
> > test on either of them?  And how do you expect to ever upgrade the
> > result without duplicating all the work done by all the existing kernel
> > package maintainers for all Debian architectures?
> > 
> > This doesn't even make any sense.  Might as well just set Architecture:
> > i386.
> Situation when 2.4.22 does not work on architecture in question is a *bug*,
> plain and simple.  Same as when 2.3.2 doesn't work on the same architecture.
> And correct way to deal with that is to report these bugs upstream and/or
> submit patches fixing them.
> BTW, is there any reason why kernel-patch-2.4.22-powerpc-2.4.22 exists?

Nowadays?  No particular reason, but when I maintained it I simply
tracked the PPC BK tree.  Lately, it's been a nice small patch, and I
didn't have a chance to examine it (part of why I gave up the package).

It used to be more like 100K gzipped, around 2.4.14 or so.

> I'm looking through the splitup of that patch right now (and by $DEITY,
> it should've been split from the very beginning - what with it being
> pulled from ppc BK tree).  There we have:

It's a diff between two different lines of development, one of which
gets periodically merged into the other.  Splitting it by csets
wouldn't give you anything useful, because you'd get a few small
patches for changes since the last merge, and one patch representing
the merge cset.  It's a hard or impossible problem to preserve cset
boundaries across such a merge.  So, no, there is no easy way to split

Especially, as I said, when the package used to be a whole lot larger
:)  I don't have time to merge-monkey for that tree, and it's not my
business to, since the maintainers do it quite well overall.

Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Reply to: