lkml.org 
[lkml]   [2003]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: mem=16MB laptop testing
On Wed, Oct 15, 2003 at 05:38:45PM +0200, Thomas Schlichter wrote:
> Well, as davej submitted his patch he seems to just have missed a Changeset
> applied to the 2.4 tree...:
>
> ChangeSet@1.404.2.2 2002-05-06 21:30:10-03:00 hch@infradead.org

Around June last year was when I didn't have enough spare time to
continue doing the 2.4 -> 2.5 pushes as frequently as I had.
As a result, lots of bits fell through the cracks, and no-one else
really bothered to step up and take over this much needed role.

> So obviously this should be fixed in the 2.6 tree too!

Looks that way.

> P.S.: How can be assured that fixes for the 2.4 tree get into the 2.6 tree
> when they are needed there, too?

There's a number of possible approaches.

The "realtime" method.
As a cset gets merged in 2.4, push it to 2.6 if needed.
This is what I was doing in early 2.5.x in the -dj branch.
It does however require you watch the trees constantly, which is a time sink,
but if you're like me, and you do that anyway...
This method can easily be a full time job depending on the rate of
change happening in both trees. It is however a good way to learn about
many different parts of the tree, and get a good "global" view of whats
going on in the trees.
This method falls apart if you have to take time off for any reason.
Coming back after a month with around a gig of Changesets to sift
through (and more constantly coming in whilst you're sifting) is a
real energy drain. I was probably one of the few people who was glad
when Linus/Marcelo went on vacation, as it was good 'catch up' time.

The "painful" method.
Finding someone to go through every changeset committed since ~2.4.18/.19
which was when I stopped doing the sync and making sure that they got into
2.6 too.

The "less effort" approach.
Do it on an as-needed basis, when issues crop up like this one, check out
the same code in 2.4, see what changed, see if theres anything that got
missed.

The "distributed" method.
Many monkeys make light work. Pick a random driver.
diff -u linux-2.4/drivers/$foo linux-2.6/drivers/$foo
review diff. Make patches if needed.


There are also other problems not covered above.
- Some csets don't make sense to forward port even though they
may look like "obvious fixes".
- Linus has been known to reject patches that made it into 2.4
This is a *real pain* when the cset isn't a 1-2 liner.
- Nothing remains still very long.
Fixes that went into 2.4 may need considerable rewriting and
bending to fit in 2.6. This was incredibly painful for some parts
of the kernel, but again.. is a good learning process.
- Some kernel hacker prima donna's really hate you touching "their" code
despite the fact you're submitting the same patch they pushed in 2.4
Be prepared to deal with assholes, and have to retransmit patches
dozens of times before they make it in via them, (or be prepared to
put up with the abuse when you shortcut them and send to Linus).

It is a very time consuming, laborious, largely thankless process with few
rewards other than satisfaction that you've "done something worthwhile",
and the good learning experience.

> I'd wonder if this missed CS is the only one...

I wish..

Dave

--
Dave Jones http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:1.024 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site