software call agenda notes 02/06/2007

[Andres Salomon]

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 devel at laptop.org 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.