[Xenomai-core] Re: I-pipe git trees

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2284 bytes --]

Philippe Gerum wrote:
> On Sat, 2006-12-02 at 18:59 +0100, Jan Kiszka wrote:
> 
> [...Resuming the discussion on both interested lists...]
> 
>> Rough idea from my side on a potential organisation of the git trees:
>>
>>  o A generic I-pipe core tree that primarily targets git head (i.e. 2.6)
>>  o One branch for git head, pulls both from Linus' tree and the I-pipe
>>    core
> 
> What would be the purpose of this branch?

Let me first sort the term chaos of "trees" and "branches" I left
behind. Each line in the following ascii graphic represents a git
repository (or tree). The 2.6 repositories may have branches to maintain
I-pipe patches for certain kernel releases.

  ^        ^          ^        ^       ^    ^
  |        | ...      |        |       |    |
  |        |/         |        |       |    |
  |        | 2.6.19   |        | ...   |    |
  |        |/         |        |/      |    |
  |        | 2.6.17   |        | ?     |    |
  |        |/         |        |/      |    |
  |        | 2.6.16   |        | ?     |    |
  |        |/         |        |/      |    |
I-pipe  Mainline   Blackfin [other    2.4  2.4
 Core     Head     CVS HEAD archs?]   x86  ELDK

Except for the 2.4 repositories or if some branch is in maintenance mode
and only tracks bug fixes, all trees pull their generic I-pipe support
regularly from the core tree.

Centre of gravity is the mainline tree. Its head tries to follow Linus'
tree closely (probably best during the last weeks of a -rc cycle).
Meanwhile, it's branches maintain support for official releases. This
support is kept up-to-date until we have a more recent Linux version for
all archs in question. Or we keep it running as a stable branch (I have
2.6.16 in mind here).

If some arch is not in mainline or has a better tree to follow, we need
a separate repository like for Blackfin. Another reason for separation
could be access control, i.e. granting some arch maintainer exclusive
access to a tree.

And for I-pipe support based on vendor-specific board patches,
maintained by people "out-of-tree", we will then have the core + the
mainline repository to cherry-pick I-pipe changes, helping to build
I-pipe patches "from scratch" - when really required.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]