kernel patch/repository status

[Werner Almesberger]

Sven Rebhan wrote:
> If I got you right, you want to track the linus/rmk/ben/whatsoever
> development branch. That's fine for development, but most users don't
> like the buggy -rc (or even inter -rc) states.

Oh, now I understand what you mean. Wouldn't regular "stable" forks
off upstream accomplish the same, without creating the constant
maintenance overhead of a long-lived parallel branch ?

Also, has the occasional upstream breakage really become a
real-life issue for the Openmoko kernel yet ? I thought we were
still by far the biggest threat to ourselves ;-)

Last but not least, this is actually a task that can be easily
outsourced :-) As long as there's one "development" branch that
gets all the fixes and improvements, someone else can maintain
parallel branches with different stability goals. That also
avoids mistakes due to the same person having to work the same
problem multiple times. (Redundancy is my main reason for fearing
development with long-lived branches.)

> As I think we have to submit most of the stuff to linux-arm, we should
> track this branch. The changes we (who else should do them if the code
> is not upstream) make during the review process should be made in
> tracking tree. This way we keep in sync with upstream (at least for

Yup, as long as the changes are made in our repository before
going upstream. Similar for changes in our upstream. Sometimes
things get edited on their way up, e.g., when getting merged or
while sitting in a subsystem maintainer's branch, and it may not
always be obvious to downstream when changes happen.

- Werner