On 5/6/07, David Chisnall <[EMAIL PROTECTED]> wrote: > 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 would say developers should sync their component from time to time because they are the only ones know when is good time to sync. But now, we can see it as a releasing cycle where someone has to be sure that everything in stable can compile and run. That is why you notice a lot of commit in svn just for that. Once this releasing phase passes, we should let developers do their own sync. If you look at the change from 0.1 to 0.2, this is really a big one. That is why there are so many small bugs here and there just for building. All of them are fixed, I hope, and it will be much smoother in the future. So everyone can do the releasing sync. > > > 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. I agree. stable should always work. Bugs in -stable should have higher priority than bugs in trunk. Developers should put more time on bug-fixing than introducing new features. > > > 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. I would say the criteria of sync with stable is when the components are stable. It solely depends on developers and tester. If they want to add new features or experimental stuff in -trunk, they may want to sync with -stable before that happens. So it is up to the developers and stability mostly, not time. When it is time to make a release, developers should pick a revision suitable to be in stable. Syncing stable from time to time has an advantage that it allows users to run it. It is a good source of bug reports. So if the components always works in the trunk, it should be sync with stable regularly. Again, stability is the first priority. > > > 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 > _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
