[lkml]   [2002]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux v2.5.52

On Mon, 16 Dec 2002, Ben Collins wrote:
> How about pointing out some specifics? Maybe make my job easier by
> getting me some patches directly. Trying to track two seperate source
> tree's isn't as easy as you might think.

It's a lot easier if you track them _often_ instead of just occasionally.
That's the main problem I have with other peoples CVS trees - CVS has very
little support for tracking any outside sources, and that coupled with the
fact that people don't track it in a timely manner always generates

With CVS, a simple script like

(a) get current version
(b) diff against the last version you did the merge against
(c) apply the diff to your new tree
(d) _then_ do the diff against the current version
(e) delete "last version merged", make current version that.

will work pretty easily most of the time for subsystems that don't get a
lot of input from outside the "maintainer". Especially if you do it
reasonably often (you can do the back-merge even when you're _not_ ready
to actually send me your stuff), the diff from my tree is often quite
small and thus easily mergible.

If you think that "maintainer" means that nobody else can touch the tree
and that you thus don't need to care, you're WRONG.

Alternatively, never EVER make a patch against the "current kernel
version". Only make a patch against the _last_ kernel that you merged
with, and if I cannot apply it I will tell you so. Making a patch just
between your tree and mine will _always_ end up losing fixes.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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