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? > o One tree for each major 2.6 version in maintenance mode, pulls from > related stable branch and I-pipe core (when applicable) > o Only if required: a generic I-pipe core tree for 2.4 It should not be needed. I-pipe for 2.4 is in deep maintenance mode, and the latest 2.6 pipeline core is no more compatible with the 2.4 version anyway, due to several infrastructure changes in the vanilla kernel, e.g. genirq. So from now on, we won't backport much from the 2.6 series to 2.4, except perhaps critical bug fixes. Most (if not all) of the changes on those trees are much likely to be 2.4-specific, as time passes. > o One tree for 2.4 head to maintain x86 > o One tree for 2.4 ELDK to maintain PPC > Yes, we definitely need those. > Quite a lot trees... Do you this this may work? It really depends on what we try to achieve with implementing a new workflow. At least, I can tell why we need a new workflow, which could give us some hint about the one we should pick. Basically, the reason is that I don't scale anymore when it comes to maintain the six I-pipe ports, even if for a few of them, I'm not directly maintaining the arch-dependent parts (just reviewing), but only the generic core. Given that the Xenomai maintenance is now unfortunately done on my free time too, something needs to be done in order to optimize those processes. Now that some recurrent contributors showed up for helping with some ports, it's time to allow the various I-pipe ports to develop at their own pace, while still being reasonably in sync with a reference implementation. There are quite talented people out there who know better than me when it comes to hw platforms they are dealing with on a daily basis, so let them tackle the issue, if they accept to. The bottom-line: - Not all trees are going to be cloned from mainline; some architectures are not even mainline yet (e.g. blackfin). This is why relying on competent people for tracking the right kernel source for any given architecture is critical, and beyond that, people who know enough about the technical trends going on for the Linux port in question (e.g. ppc and arm). - In the new workflow, I'm going to keep working on the generic I-pipe core, and lead the maintenance for the ports which have no better maintainer in sight. - I want this process to add flexibility, by decoupling the evolution of the various ports, without introducing chaos. This should be possible with all the maintainers keeping an eye on the reference implementation I'll be working on, and improving with their input. - Keep it simple. I'm slow, damnit! -- Philippe. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
