6:25 p.m.
Michael Sperber 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.
This means that in the case in point (a concurrent commit to the
mainline) the tagged revision *will* be a merge turd and *will*
include code that is undocumented in the release (at best, and in the
process you suggest, the tag *will* include code that is not in the
tarballs).
No, thank you.
I really don't understand what your point is. We have the free fire
zone over on the xemacs branch. Why does it matter if the xemacs-beta
branch has a ceasefire for a few hours? It only affects you and Vin.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:49 a.m.
New subject: Releasing from Mercurial repo -- procedures?
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber 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.
This means that in the case in point (a concurrent commit to the
mainline) the tagged revision *will* be a merge turd and *will*
include code that is undocumented in the release (at best, and in the
process you suggest, the tag *will* include code that is not in the
tarballs).
No, thank you.
You could do all that at once in your local copy, and then push.
I really don't understand what your point is. We have the free
fire
zone over on the xemacs branch. Why does it matter if the xemacs-beta
branch has a ceasefire for a few hours? It only affects you and Vin.
I guess I don't understand what your point is. Weren't you asking how
to avoid the "cease-fire"? I have no objection to not doing anything
with xemacs-beta while you're cutting the release---I'm currently
stalled anyway because of the search crash.
--
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:27 p.m.
New subject: Releasing from Mercurial repo -- procedures?
Michael Sperber writes:
You could do all that at once in your local copy, and then push.
I plan to do it that way, but it does require a freeze to avoid a
concurrent commit AFAICS.
In the case of a concurrent commit, that doesn't meet the desiderata
of (a) tagged revision is in the tarballs, (b) all contents are
documented in CHANGES-beta, and (c) tagged revision is not a merge.
I guess I don't understand what your point is. Weren't you
asking how
to avoid the "cease-fire"?
No, I wanted to know if anybody objected to a normally short freeze on
the xemacs-beta repo. If so, yes, I'd like to know how to do this in
a way that both meets my desiderata and avoids a freeze.
I also wanted to know if I have commit access to it, which question
has sorta been ignored. :-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:38 p.m.
New subject: Releasing from Mercurial repo -- procedures?
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Michael Sperber writes:
> You could do all that at once in your local copy, and then push.
I plan to do it that way, but it does require a freeze to avoid a
concurrent commit AFAICS.
In the case of a concurrent commit, that doesn't meet the desiderata
of (a) tagged revision is in the tarballs, (b) all contents are
documented in CHANGES-beta, and (c) tagged revision is not a merge.
I think it meets all of your desiderata, but as I said, no problem with
holding off. It even works without a named branch: If you just pull the
version you want, make your changes, tag the version you want, make the
tarballs, pull again, merge, and push, then (a) (b) and (c) are all met.
> I guess I don't understand what your point is. Weren't
you asking how
> to avoid the "cease-fire"?
No, I wanted to know if anybody objected to a normally short freeze on
the xemacs-beta repo. If so, yes, I'd like to know how to do this in
a way that both meets my desiderata and avoids a freeze.
I don't object.
I also wanted to know if I have commit access to it, which question
has sorta been ignored. :-)
Sorry. You do.
--
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
12:31 a.m.
New subject: Releasing from Mercurial repo -- procedures?
Michael Sperber writes:
I think it meets all of your desiderata, but as I said, no problem
with
holding off. It even works without a named branch: If you just pull the
version you want, make your changes, tag the version you want, make the
tarballs, pull again, merge, and push, then (a) (b) and (c) are all met.
Not AFAICS. True, I'll see what I want to see in my repo. But the
*default* output of hg log *at the public repo* will make it appear
that the concurrent commit is included in the release. In any case,
unless we freeze around the release, our developers and users need to
become graph theory/concurrency experts to interpret the output of "hg
log". I don't think that's a good idea.
> No, I wanted to know if anybody objected to a normally short
freeze on
> the xemacs-beta repo.
I don't object.
OK. Once I've ported my scripts to Mercurial I'll make a call for
last-minute APPROVEs to xemacs-beta.
> I also wanted to know if I have commit access to it, which
question
> has sorta been ignored. :-)
Sorry. You do.
Great! Thanks!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6129
days inactive
6131
days old
4 comments
2 participants
participants (2)
-
Michael Sperber -
Stephen J. Turnbull