Will __devexit_p() be appearing in 2.5.1-preX soon so
that the latest binutils can bu used for 2.5.1? It seems
to work very well for the 2.4.17-preX series. Thanks for
any info.
Jordan Breeding
This brings up a more generic issue. It would really be nice to have
someone who syncs up 2.5.X with the bug fixes going into the 2.4.x
series. It really is needed, and it really is a boring and thankless
job :-)
On Wed, 12 Dec 2001, David S. Miller wrote:
>
> This brings up a more generic issue. It would really be nice to have
> someone who syncs up 2.5.X with the bug fixes going into the 2.4.x
> series. It really is needed, and it really is a boring and thankless
> job :-)
And the reason said boring thankless job can't be done by an automated
revision control system is??
--
M. Edward Borasky -- [email protected] -- http://www.borasky-research.net
Q. How do you tell when a pineapple is ready to eat?
A. It picks up its knife and fork.
From: "M. Edward (Ed) Borasky" <[email protected]>
Date: Wed, 12 Dec 2001 19:39:03 -0800 (PST)
On Wed, 12 Dec 2001, David S. Miller wrote:
> This brings up a more generic issue. It would really be nice to have
> someone who syncs up 2.5.X with the bug fixes going into the 2.4.x
> series. It really is needed, and it really is a boring and thankless
> job :-)
And the reason said boring thankless job can't be done by an automated
revision control system is??
Because it requires a human brain to deal with the conflicts.
Any fixes to the block layer is going to have this problem,
and once we go to kbuild 2.5 these kinds of conflicts will
be even larger.
I use a revision control system, and have done so for 6 or more years,
and I have to merge a lot of things by hand. It's not because I'm and
idiot, or that my revision control system sucks, it's simply because
interfaces and config/makefile format changes require by hand work.
>
> On Wed, 12 Dec 2001, David S. Miller wrote:
>
> >
> > This brings up a more generic issue. It would really be nice to have
> > someone who syncs up 2.5.X with the bug fixes going into the 2.4.x
> > series. It really is needed, and it really is a boring and thankless
> > job :-)
>
> And the reason said boring thankless job can't be done by an automated
> revision control system is??
> --
>
> M. Edward Borasky -- [email protected] -- http://www.borasky-research.net
>
> Q. How do you tell when a pineapple is ready to eat?
> A. It picks up its knife and fork.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Wed, 12 Dec 2001, David S. Miller wrote:
> This brings up a more generic issue. It would really be nice to have
> someone who syncs up 2.5.X with the bug fixes going into the 2.4.x
> series. It really is needed, and it really is a boring and thankless
> job :-)
Something tells me I'll regret this later, but here goes..
I'll keep an eye on 2.4 pre's and resync with 2.5's as and
when a new one appears in either branch.
http://www.codemonkey.org.uk/patches/2.5/patch-2.5.1pre11-dj1.diff.bz2
o Merge with 2.4.17pre8
Drop devfs changes. (Newer version in 2.5)
o Make ncr53c8xx bio aware. (me).
regards,
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
I've already asked Linus about that and he told me that he is giving
higher priority to core changes now and wants to do the merges later...
On Wed, 12 Dec 2001, David S. Miller wrote:
>
> This brings up a more generic issue. It would really be nice to have
> someone who syncs up 2.5.X with the bug fixes going into the 2.4.x
> series. It really is needed, and it really is a boring and thankless
> job :-)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
From: Marcelo Tosatti <[email protected]>
Date: Thu, 13 Dec 2001 14:14:18 -0200 (BRST)
I've already asked Linus about that and he told me that he is giving
higher priority to core changes now and wants to do the merges later...
That is going to be a lot to accumulate whenever the code change
priority goes back down, really.
To me it makes more sense to do a release or two making one of the
core changes, and fixing it up, then do a sync pass to get the bug
fixes piling up in 2.4.x
I think Linus's scheme is going to result in either a lot of missed
fixes or a lot of unnecessary work and headaches for some poor
person. :-)