[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tag cleanup
Eric S. Raymond
Re: Tag cleanup
Thu, 9 Jan 2014 06:24:07 -0500
Eli Zaretskii <address@hidden>:
> I think everything except EMACS_PRETEST_* and emacs-xx.yy (why the
> different letter-case and syntax, btw?) should be removed.
The tags beginning eith uppercase EMACS and containing _ where you would
expect . are inherited CVS tags; . was not a legal tag character in CVS.
After the switchover to bzr, whover was making release tags (probably Stefan)
started using the more natural emacs-xx.yy convention, but did not rename
the old tags.
I renamed the old CVS-style release tags to corresponding emacs-xx.yy
tags because my philosophy about conversions is to use the idioms of the
target VCS wherever possible, making the join between older and newer
portions of the history invisible.
I didn't rename the *PRETEST* tags because I wasn't sure we'd keep them.
I agree with you that if we keep them they would be better renamed
something like emacs-pretest-xx.yy.zz.
> other tags are of no importance once the corresponding features have
> landed on mainline. For example, emacs-bidi-base can certainly go.
The *-base tags are almost certainly automatically generated CVS
artifacts that can be removed, but I am conservative by habit in
making such changes.
> But please wait for the "owners" of those other tags to speak up, I
> don't want to usurp anyone's tags.
I don't either.
> The fate of the pretest tags depends on whether we will continue using
> such tags in the future. Emacs pretests are normally quite long, so a
> pretest emacs-24.3.90 is very similar to a released version, and the
> number of commits between it and the next pretest will generally be
> very large. So, if the git experts say that "git describe" and its
> middle field are important, I'd rather see there a small enough number
> than something of 6 digits.
We have two policy questions:
1. Continue using pretest tags? If so, I will rename as you suggest.
If not, I will delete them. I have no strong preference here.
2. What form do we intend to use for the value of
emacs-repository-version? The choices are raw SHA1 or git describe
format; others are theoretically possible but it is normal git
practice to choose one of those two. I advocate the latter as I think
the format is more informative to humans.
These are not my decisions to make unless everybody yawns and says
"don't care". I would much prefer to see a list consensus or, failing
that, maintainer fiat.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>