"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
If anybody wants to start publishing "top ten bugs that must be
fixed
for the release" or "top ten features that should be completed for the
release" lists, that would be a good start. But we don't even have
those lists yet;
We haven't had them for a long time. While desirable, I don't think
this is a good strategy for moving forward - there's just nobody around
to push for that kind of plan.
The reason why I advocated branching after GPLv3 is that I expect more
aggressive development after that. (At least that development is
enabled. If it happens - who knows.) So this is a good time to branch
off for stability. One the other hand, we do want GPLv3 to enable GPLv3
packages.
I'd then suggest moving towards a model more in line what many other
projects have concluded is a good strategy for producing releases:
- branch off a "stable" branch (leaving a "development branch" and
the
"stabe branch"
- set a release *date*
- fix bugs in the stable branch, merge them over to the development
branch
- at that date, branch off the release branch, do n days of release
engineering
- release
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta