Le 5 mai 07 à 21:29, David Chisnall a écrit :
> At some point, we need to come up with a process that allows
> something to be put into the stable branch. For now, our current
> procedure (i.e. Yen-Ju does it) works, but it's probably not very
> scalable (unless someone can find some more Yen-Jus from somewhere).
>
> Does anyone have any sensible thoughts? Or silly ones that I can
> laugh at?
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).
I think the question was more about stable an trunk branch sync.
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)
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.
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.
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]
If it's just a backport, this isn't needed.
What do you think?
Quentin.
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
