9:12 a.m.
So, how are we gonna do this? Looks to me like the only sane way to
go is to declare a commit freeze until the release is complete.
Question ... do I have the needed commit privilege?
No big hurry, I've got other fish to fry this week, but maybe next
week I'll be thinking about 21.5.29.
Comments?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9:41 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
So, how are we gonna do this? Looks to me like the only sane way to
go is to declare a commit freeze until the release is complete.
Why? If you want to stabilize for the release, you just create a
branch pull or transplant things in place.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:04 a.m.
Michael Sperber writes:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> So, how are we gonna do this? Looks to me like the only sane way to
> go is to declare a commit freeze until the release is complete.
Why? If you want to stabilize for the release, you just create a
branch pull or transplant things in place.
Um, no. Stabilize for the release? Surely you are joking. If it
builds on the release machine and I can get it to pop up a window, I'm
going to ship it. The point is I do not want any merge artifacts
around the release tag. It should cleanly separate pre-release
changes from post-release changes. And the same for ChangeLogs. (I
notice you recently committed a ChangeLog in the middle of the log
instead of at the top. Doesn't matter for typical random commits, but
it does matter for the release banner. Mercurial artifact, I'm sure.)
Also I see no good reason why I should have to edit the CHANGES-beta
file and regenerate announcements. And in any case we have the xemacs
repo to buffer any concurrent changes in.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:23 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
>
> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>
> > So, how are we gonna do this? Looks to me like the only sane way to
> > go is to declare a commit freeze until the release is complete.
>
> Why? If you want to stabilize for the release, you just create a
> branch pull or transplant things in place.
Um, no. Stabilize for the release? Surely you are joking. If it
builds on the release machine and I can get it to pop up a window, I'm
going to ship it. The point is I do not want any merge artifacts
around the release tag. It should cleanly separate pre-release
changes from post-release changes. And the same for ChangeLogs. (I
notice you recently committed a ChangeLog in the middle of the log
instead of at the top. Doesn't matter for typical random commits, but
it does matter for the release banner. Mercurial artifact, I'm sure.)
Also I see no good reason why I should have to edit the CHANGES-beta
file and regenerate announcements. And in any case we have the xemacs
repo to buffer any concurrent changes in.
I'm still fuzzy on what exactly you're trying to do. It seems you could
simply do "hg tag", no?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:45 p.m.
Michael Sperber writes:
I'm still fuzzy on what exactly you're trying to do. It
seems you could
simply do "hg tag", no?
No. Current release procedure implies changes to all ChangeLogs
(adding release banners) and to CHANGES-beta (sealing it to start the
next release's changes). I use these very heavily to identify which
changes went into which version when supporting users; I want no
confusion about them. They must obviously come after any changes
required by bugs found during the release process (which has
happened). The easiest way to implement that is to not commit.
Here's the current procedure[1]:
1. Check out tag of previous release.
2. Check out HEAD in separate directory.
Required to make a proper patch using makepatch.
3. Compute ChangeLogs and CHANGES-beta changes, apply to workspace,
and format into announcement drafts.
4. Make patches using makepatch.
5. (optional) Make pristine source tarballs.
6. Configure and build --with-x11 --with-mule.
7. Run "xemacs --eval '(progn (sleep-for 5)
(save-buffers-kill-emacs))'".
8. Run "make check".
9. Commit to HEAD.
10. Tag HEAD.
11. (optional) Make elc-and-info-included tarballs.
12. Sign all products.
13. Upload tarballs to temporary private directory.
14. (By hand) edit announcements (concurrent with 10).
15. mv tarballs into place.
16. Update archive READMEs, LATEST-* stubs in directory, etc.
17. Update website.
18. Post announcements to mailing lists.
19. Download tarballs, unpack into tempdir, configure and
build --with-x11 --with-mule.
For Mercurial, there would be the following changes and additions, I
believe:
2. Update from "xemacs-beta" tip.
9. Commit locally.
9.5. Tag locally.
10. Push to "xemacs-beta" tip.
I want a freeze from 2 to 10. Since I do no work on "xemacs-beta,"
steps 2 and 10 should both be clean fast-forwards; no merge turds. If
everything goes well, that procedure is fully automated and completes
in about 30 minutes.
Strictly speaking 13 and 19 should be done before 9, but that would
add about 4 hours to the procedure based on upload speeds for 21.5.27
and 21.5.28.
Footnotes:
[1] Somewhat idealized; I think actually I make elc-and-info
tarballs only, but do that before step 9. I want to fix that.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:29 a.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Here's the current procedure[1]: [...]
I suggest simply doing all this in a named branch on xemacs-beta.
(That's how I do release engineering, for Scheme 48.)
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
3:35 a.m.
Michael Sperber writes:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> Here's the current procedure[1]: [...]
I suggest simply doing all this in a named branch on xemacs-beta.
(That's how I do release engineering, for Scheme 48.)
Do all what? The tagging and ChangeLogs? If I do that, they won't be
part of the mainline, which defeats one of the main purposes of having
beta releases: providing a timeline for people who are following the
mainline that they can see in the various ways we present history.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:03 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>
> > Here's the current procedure[1]: [...]
>
> I suggest simply doing all this in a named branch on xemacs-beta.
> (That's how I do release engineering, for Scheme 48.)
Do all what? The tagging and ChangeLogs? If I do that, they won't be
part of the mainline, which defeats one of the main purposes of having
beta releases: providing a timeline for people who are following the
mainline that they can see in the various ways we present history.
Not the tagging: You create a named branch, make all the changes you
need to do, cut the beta release from that. *Then* you merge your
branch back into the mainline, and *then* tag on the mainline. (If you
tag in the branch, the tag won't be visible on the mainline.)
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:48 p.m.
Not the tagging: You create a named branch, make all the changes you
need to do, cut the beta release from that. *Then* you merge your
branch back into the mainline, and *then* tag on the mainline. (If you
tag in the branch, the tag won't be visible on the mainline.)
This procedure seems to violate a configuration management
truth-in-labelling; you aren't putting the label on the exact source
code you built from.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:47 a.m.
Benson Margulies <bimargulies(a)gmail.com> writes:
> Not the tagging: You create a named branch, make all the changes
you
> need to do, cut the beta release from that. *Then* you merge your
> branch back into the mainline, and *then* tag on the mainline. (If you
> tag in the branch, the tag won't be visible on the mainline.)
>
This procedure seems to violate a configuration management
truth-in-labelling; you aren't putting the label on the exact source
code you built from.
No, you do. The question is where you're putting the label itself. You
want to put it in the mainline so you can see it from the mainline. It
would still point into the branch.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:30 p.m.
Michael Sperber writes:
No, you do. The question is where you're putting the label
itself. You
want to put it in the mainline so you can see it from the mainline. It
would still point into the branch.
This doesn't make any sense. Tags live outside of the revision DAG
and point at a single revision, which will not be on the "principal
branch" containing the tip of default.
This means that to figure out the difference between tip and any given
revision, you need to compute the DAG back to the most recent common
node.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6130
days inactive
6133
days old
10 comments
3 participants
participants (3)
-
Benson Margulies -
Michael Sperber -
Stephen J. Turnbull