On 6 May 2007, at 09:45, Quentin Mathé wrote: > Well, we put a new module in -stable when we are quite sure when it's > not anymore in rough development state and we will use it in future > (without too many doubts).
There is a slight question of who 'we' are in this context. The maintainer? The core devs? Some subset of the core devs who we designate for this rôle (*looks at Yen-Ju*)? > I think the question was more about stable an trunk branch sync. That's probably going to happen more than adding new stuff to stable (I hope, anyway), so it needs to be relatively easy. > Personnally I think once the release sync has been done (we do it > three weeks or one month before release), each maintainer should be > in charge to backport to stable any bug fixes committed to trunk. If > it's really critical a maintainer may backport new features (this > could be useful for early releases like 0.2, 0.3) That sounds sensible. A feature-freeze in -stable in the run-up to a release. For each release, I suggest we designate a release engineer, who is the final arbiter of any new features individual maintainers think should be added (the release engineer should judge whether they are likely to impact stability. They should be allowed only if they are vital in frameworks that are used in a lot of other places). > Outside of this release period, any maintainers is free to sync > stable and trunk versions of his modules or backport bugs fixes if he > feels it necessary. I think we should make a commitment that stable will always build (serious bug if it doesn't), and should always work (bug if it doesn't). Changes to stable that break the build should be backed out (automatically?), and so should those that break the system. At leas until around 0.5, we are likely to be recommending new users run stable, so having it working is a high priority. > When no release happens, we might want also to synchronize stable and > trunk every three or four months on a common agreement of all > maintainers. I'm not sure about this. I think it is likely to make stable a lot less stable than we want. We should possibly say new code should not stay in trunk for more than six months without being either sync'd with stable or moved into a branch. That would stop trunk diverging too far from stable without being actively forked off into a branch. We also need to consider dependencies. If A in trunk depends on new features in B, then A can't go into stable until B does, so we might need to sync large chunks of the tree at once. > When a commit is directly done in a branch like stable, ChangeLog > entry should include branch name inside brackets like that: > > 2007-03-22 Quentin Mathe <[EMAIL PROTECTED]> > > * setup.sh: > * setdown.sh: > Modified to set GWorkspace related defaults as suggested in bug > reports > #8618 and #8668 > [stable] Sounds sensible. I'd prefer the branch to go in big letters at the start though, and possibly have changes to stable automatically sent to this list. David _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
