Le 6 mai 07 à 18:45, Yen-Ju Chen a écrit : > 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*)?
In this context, 'we' is the maintainer of each module. The last 'we' refers more precisely to core devs. > 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. This choice looks reasonable. >>> 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). If the developer team suddenly grows, it could make sense to have a release engineer. But for now, I think Yen-Ju and I are playing this role together since we are the only ones to have a sufficient bird view by working on key modules (like Azalea, System, EtoileMenuServer etc.) and many different parts of the environment too. >>> 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. The most important point would be to have daily automated test builds. I don't think backing out then would be worth the investment. As it is explained in HACKING document, the repository may build on your system but not on another identical one, simply because you didn't remove your current install that most of time sastifies all dependencies without relying on Build directory (filled by etoile.make). >> At >> leas until around 0.5, we are likely to be recommending new users run >> stable, so having it working is a high priority. Do you mean we should probably ensure to provide packages (like rpm and deb) starting with release 0.5 and until then -stable is the way to go? > 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. Agreed. >> 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. Not sure about this last point since modules are usually quite sandboxed. If we observe -trunk diverging problems in future, we could adopt this rule then… what do you think? >> 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. I agree. >>> 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. I'm fine with your suggestion. May I ask someone to update our release related doc on website about it and probably Etoile/HACKING file too? :-) Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
