Christopher Blizzard wrote: [...] > - need to tell J5 that a new kernel is available? don't need that. > - What else goes into the build? > - OS components that change > - both stable and unstable? > - master == stable, experimental == unstable > - andres, file trac bug for url for j5 to pull into the tree from > master > - any risk here? need to inform [email protected] that they commit to > the right branch >
Here's what I propose: 1) Merge master w/ experimental. Since b2 is done, then we can start using 2.6.20 plus misc other patches we've put into experimental. 2) Immediately branch 'stable'. The autobuilding scripts will be changed, and 'master' will end up in d.l.o/~dilinger/RPMS/experimental, and 'stable' will end up in d.l.o/~dilinger/RPMS. 3) Further development happens on 'master'; we can either cherry-pick patches and stick them into 'stable', or (if we feel master is stable enough), delete and recreate 'stable' based on the current 'master'. 4) OS builds can automatically pull in the latest 'stable' build. Patches and rebases of stable are done manually, with the expectation that the tree is always ready for prime time. 5) We can merge in stable patches (ie, 2.6.20.1) without having to worry about conflicts with linus's tree, since we will end up simply rebasing 'stable' rather than merging it. However, stable patches should not end up in 'master', as that will be tracking linus (and will often be using linus's -rc releases) This can happen as soon as we feel current 'experimental' is good enough to call stable. At the moment, it's at 2.6.20, there are a few known bugs, and the VSA stuff could probably use testing. Dynticks is not in there yet. _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
