Re: mem=16MB laptop testing

[Dave Jones <davej@redhat.com>]

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