Tag cleanup

Tag cleanup

[Eric S. Raymond]

The following is a list of tags currently existing in the git repo
with notes on how I think they should be disposed of. Interested 
parties should reply with claims on tags they want kept, or reasons
to dispose of others.

I believe the following tags were automatically generated in CVS to
mark branchpoints, are no longer interesting, and should be removed.
(Some don't look CVSish, apparently because they were renamed during
the move to Bazaar.)

Boehm-GC-base
RMAIL-MBOX-BASE
CEDET_BASE
EMACS_21_1_BASE
EMACS_22_BRANCHPOINT
EMACS_23_1_BASE
emacs-bidi-base
emacs-unicode-2-base
emacs-unicode-base
font-backend-base
fx-branch-base
gnus-5_10-branchpoint
branchpoint-5_8
custom_themes_branchpoint
multi-tty-base
patches_21_0_base
small-dump-base

I believe the following tags were created as temporary markers during
feature branch work and ceased being interesting when the feature
landed in trunk:

after-merge-gnus-5_10
amigados-merge
before-merge-emacs-app-to-trunk
before-merge-gnus-5_10
before-merge-multi-tty-to-trunk
before-merge-unicode-to-trunk
before-miles-orphaned-changes
before-remove-carbon
before-remove-vms
before-thomas-posix1996
emacs-unicode-2-pre-sync
gnus-5_10-post-merge-josefsson
gnus-5_10-post-merge-yamaoka
gnus-5_10-pre-merge-josefsson
gnus-5_10-pre-merge-yamaoka
merge-multi-tty-to-trunk
merge-unicode-to-trunk
remove-carbon
remove-vms
zsh-merge-ognus-1
zsh-sync-ognus-2
zsh-sync-ognus-3

These are real release tags which I intend to replace with cryptposigned
annotated tags.

emacs-19.34
emacs-20.1
emacs-20.2
emacs-20.3
emacs-20.4
emacs-21.1
emacs-21.2
emacs-21.3
emacs-22.1
emacs-22.2
emacs-22.3
emacs-23.1
emacs-23.2
emacs-23.3
emacs-23.4
emacs-24.0.96
emacs-24.0.97
emacs-24.1
emacs-24.2
emacs-24.2.90
emacs-24.2.91
emacs-24.2.92
emacs-24.2.93
emacs-24.3
emacs-24.3-base
emacs-24.3-rc1

The following tags have owners who have claimed them.

ttn-vms-21-2-B2
ttn-vms-21-2-B3
ttn-vms-21-2-B4
v0.1
v0.1.0
v0.1.1
v0.1.2
v0.1.3
v0.2.0
v0.3.0

Disposition of the following tags awaits a maintainer decision on
whether we will continue to use pretest tags:

EMACS_PRETEST_21_0_100
EMACS_PRETEST_21_0_101
EMACS_PRETEST_21_0_102
EMACS_PRETEST_21_0_103
EMACS_PRETEST_21_0_104
EMACS_PRETEST_21_0_105
EMACS_PRETEST_21_0_106
EMACS_PRETEST_21_0_90
EMACS_PRETEST_21_0_91
EMACS_PRETEST_21_0_92
EMACS_PRETEST_21_0_93
EMACS_PRETEST_21_0_95
EMACS_PRETEST_21_0_96
EMACS_PRETEST_21_0_97
EMACS_PRETEST_21_0_98
EMACS_PRETEST_21_0_99
EMACS_PRETEST_21_2_91
EMACS_PRETEST_21_2_92
EMACS_PRETEST_21_2_93
EMACS_PRETEST_21_2_94
EMACS_PRETEST_21_2_95
EMACS_PRETEST_22_0_90
EMACS_PRETEST_22_0_91
EMACS_PRETEST_22_0_92
EMACS_PRETEST_22_0_93
EMACS_PRETEST_22_0_94
EMACS_PRETEST_22_0_95
EMACS_PRETEST_22_0_96
EMACS_PRETEST_22_0_97
EMACS_PRETEST_22_0_98
EMACS_PRETEST_22_0_99
EMACS_PRETEST_22_0_990
EMACS_PRETEST_22_1_90
EMACS_PRETEST_22_1_91
EMACS_PRETEST_22_1_92
EMACS_PRETEST_22_2_90
EMACS_PRETEST_22_2_91
EMACS_PRETEST_22_2_92
EMACS_PRETEST_23_0_90
EMACS_PRETEST_23_0_91
EMACS_PRETEST_23_0_92
EMACS_PRETEST_23_0_93
EMACS_PRETEST_23_0_94
EMACS_PRETEST_23_0_95
EMACS_PRETEST_23_0_96
EMACS_PRETEST_23_1_90
EMACS_PRETEST_23_1_91
EMACS_PRETEST_23_1_92
EMACS_PRETEST_23_1_93
EMACS_PRETEST_23_1_94
EMACS_PRETEST_23_1_95
EMACS_PRETEST_23_1_96
EMACS_PRETEST_23_1_97
EMACS_PRETEST_23_2_90
EMACS_PRETEST_23_2_91
EMACS_PRETEST_23_2_92
EMACS_PRETEST_23_2_93
EMACS_PRETEST_23_2_93_1
EMACS_PRETEST_23_2_94
EMACS_PRETEST_23_3_90
EMACS_PRETEST_24_0_05
EMACS_PRETEST_24_0_90
EMACS_PRETEST_24_0_91
EMACS_PRETEST_24_0_92
EMACS_PRETEST_24_0_93
EMACS_PRETEST_24_0_94
EMACS_PRETEST_24_0_95

I do not have a disposition for the following tags:

Release_5_25
emacs-23/emacs-23.2
lisp-bob
release-0-0
release-0-1
release-1-0
root-libc-2_0_x-branch
sml-mode-6.0
sml-mode-6.1
tmp_pcl_tag_131034C
unicode-post-font-backend
unicode-pre-font-backend
unicode-xft-base
v1_7i
v2007-Sep-10
xwidget-0.2
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

All forms of government are pernicious, including good government.
	-- Edward Abbey

Re: Tag cleanup

[Eli Zaretskii]

> From: esr@thyrsus.com (Eric S. Raymond)
> Date: Fri, 10 Jan 2014 15:06:41 -0500 (EST)
> 
> These are real release tags which I intend to replace with cryptposigned
> annotated tags.
> [...]
> emacs-24.0.96
> emacs-24.0.97
> emacs-24.1
> emacs-24.2
> emacs-24.2.90
> emacs-24.2.91
> emacs-24.2.92
> emacs-24.2.93

The emacs-xx.yy.zz tags are for pretests, and thus should be handled
like the EMACS_PRETEST_* tags.

> emacs-24.3
> emacs-24.3-base
> emacs-24.3-rc1

The -rc1 one also a (kind of) pretest.

Thanks.

Re: Tag cleanup

[Andreas Schwab]

esr@thyrsus.com (Eric S. Raymond) writes:

> I believe the following tags were automatically generated in CVS to
> mark branchpoints, are no longer interesting, and should be removed.
> (Some don't look CVSish, apparently because they were renamed during
> the move to Bazaar.)

Those tags were all already in CVS.

> emacs-23/emacs-23.2

This tags is a workaround for the fact that you cannot have both foo and
foo/bar refs in the same repo in git.  In bzr this is a branch.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Tag cleanup

[Eric S. Raymond]

Andreas Schwab <schwab@linux-m68k.org>:
> esr@thyrsus.com (Eric S. Raymond) writes:
> 
> > I believe the following tags were automatically generated in CVS to
> > mark branchpoints, are no longer interesting, and should be removed.
> > (Some don't look CVSish, apparently because they were renamed during
> > the move to Bazaar.)
> 
> Those tags were all already in CVS.

I guess it's pretty safe to flush them all, then.  I'll do that.
 
> > emacs-23/emacs-23.2
> 
> This tags is a workaround for the fact that you cannot have both foo and
> foo/bar refs in the same repo in git.  In bzr this is a branch.

Should it be retained?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Tag cleanup

[Andreas Schwab]

"Eric S. Raymond" <esr@thyrsus.com> writes:

> Andreas Schwab <schwab@linux-m68k.org>:
>> esr@thyrsus.com (Eric S. Raymond) writes:
>> 
>> > emacs-23/emacs-23.2
>> 
>> This tags is a workaround for the fact that you cannot have both foo and
>> foo/bar refs in the same repo in git.  In bzr this is a branch.
>
> Should it be retained?

It's the same rev as EMACS_23_2, so there should be no need for it.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Tag cleanup

[Alan Mackenzie]

Hello, Eric.

On Fri, Jan 10, 2014 at 03:06:41PM -0500, Eric S. Raymond wrote:
> The following is a list of tags currently existing in the git repo
> with notes on how I think they should be disposed of. Interested 
> parties should reply with claims on tags they want kept, or reasons
> to dispose of others.

[ .... ]

> I do not have a disposition for the following tags:

> Release_5_25

This is a CC Mode tag from 1999.  I say it is no longer needed, and
should be removed (unless Barry Warsaw (who made it) disagrees).

> -- 
> 		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

-- 
Alan Mackenzie (Nuremberg, Germany).

Tag cleanup

[Eric S. Raymond]

Please examine this list of tag names,  I want to know which should 
be thrown out to reduce clutter.

This list is what remains after two steps:

1. As requested on the list, throw out literally hundreds of tags
tracking non-Emacs GNU releases

2. Rename release tags of the form EMACS_[0-9_]* to emacs-\1 with _
   replaced by .

The question is what out of the remainder is dispensable clutter.
The *PRETEST* labels seem like obvious candates; so do base
and branchpoint tags.

Boehm-GC-base
CEDET_BASE
EMACS_21_1_BASE
EMACS_22_BRANCHPOINT
EMACS_23_1_BASE
EMACS_PRETEST_21_0_100
EMACS_PRETEST_21_0_101
EMACS_PRETEST_21_0_102
EMACS_PRETEST_21_0_103
EMACS_PRETEST_21_0_104
EMACS_PRETEST_21_0_105
EMACS_PRETEST_21_0_106
EMACS_PRETEST_21_0_90
EMACS_PRETEST_21_0_91
EMACS_PRETEST_21_0_92
EMACS_PRETEST_21_0_93
EMACS_PRETEST_21_0_95
EMACS_PRETEST_21_0_96
EMACS_PRETEST_21_0_97
EMACS_PRETEST_21_0_98
EMACS_PRETEST_21_0_99
EMACS_PRETEST_21_2_91
EMACS_PRETEST_21_2_92
EMACS_PRETEST_21_2_93
EMACS_PRETEST_21_2_94
EMACS_PRETEST_21_2_95
EMACS_PRETEST_22_0_90
EMACS_PRETEST_22_0_91
EMACS_PRETEST_22_0_92
EMACS_PRETEST_22_0_93
EMACS_PRETEST_22_0_94
EMACS_PRETEST_22_0_95
EMACS_PRETEST_22_0_96
EMACS_PRETEST_22_0_97
EMACS_PRETEST_22_0_98
EMACS_PRETEST_22_0_99
EMACS_PRETEST_22_0_990
EMACS_PRETEST_22_1_90
EMACS_PRETEST_22_1_91
EMACS_PRETEST_22_1_92
EMACS_PRETEST_22_2_90
EMACS_PRETEST_22_2_91
EMACS_PRETEST_22_2_92
EMACS_PRETEST_23_0_90
EMACS_PRETEST_23_0_91
EMACS_PRETEST_23_0_92
EMACS_PRETEST_23_0_93
EMACS_PRETEST_23_0_94
EMACS_PRETEST_23_0_95
EMACS_PRETEST_23_0_96
EMACS_PRETEST_23_1_90
EMACS_PRETEST_23_1_91
EMACS_PRETEST_23_1_92
EMACS_PRETEST_23_1_93
EMACS_PRETEST_23_1_94
EMACS_PRETEST_23_1_95
EMACS_PRETEST_23_1_96
EMACS_PRETEST_23_1_97
EMACS_PRETEST_23_2_90
EMACS_PRETEST_23_2_91
EMACS_PRETEST_23_2_92
EMACS_PRETEST_23_2_93
EMACS_PRETEST_23_2_93_1
EMACS_PRETEST_23_2_94
EMACS_PRETEST_23_3_90
EMACS_PRETEST_24_0_05
EMACS_PRETEST_24_0_90
EMACS_PRETEST_24_0_91
EMACS_PRETEST_24_0_92
EMACS_PRETEST_24_0_93
EMACS_PRETEST_24_0_94
EMACS_PRETEST_24_0_95
RMAIL-MBOX-BASE
Release_5_25
after-merge-gnus-5_10
amigados-merge
before-merge-emacs-app-to-trunk
before-merge-gnus-5_10
before-merge-multi-tty-to-trunk
before-merge-unicode-to-trunk
before-miles-orphaned-changes
before-remove-carbon
before-remove-vms
before-thomas-posix1996
branchpoint-5_8
custom_themes_branchpoint
emacs-19.34
emacs-20.1
emacs-20.2
emacs-20.3
emacs-20.4
emacs-21.1
emacs-21.2
emacs-21.3
emacs-22.1
emacs-22.2
emacs-22.3
emacs-23.1
emacs-23.2
emacs-23.3
emacs-23.4
emacs-23/emacs-23.2
emacs-24.0.96
emacs-24.0.97
emacs-24.1
emacs-24.2
emacs-24.2.90
emacs-24.2.91
emacs-24.2.92
emacs-24.2.93
emacs-24.3
emacs-24.3-base
emacs-24.3-rc1
emacs-bidi-base
emacs-unicode-2-base
emacs-unicode-2-pre-sync
emacs-unicode-base
font-backend-base
fx-branch-base
gnus-5_10-branchpoint
gnus-5_10-post-merge-josefsson
gnus-5_10-post-merge-yamaoka
gnus-5_10-pre-merge-josefsson
gnus-5_10-pre-merge-yamaoka
lisp-bob
merge-multi-tty-to-trunk
merge-unicode-to-trunk
multi-tty-base
patches_21_0_base
release-0-0
release-0-1
release-1-0
remove-carbon
remove-vms
root-libc-2_0_x-branch
small-dump-base
sml-mode-6.0
sml-mode-6.1
tmp_pcl_tag_131034C
ttn-vms-21-2-B2
ttn-vms-21-2-B3
ttn-vms-21-2-B4
unicode-post-font-backend
unicode-pre-font-backend
unicode-xft-base
v0.1
v0.1.0
v0.1.1
v0.1.2
v0.1.3
v0.2.0
v0.3.0
v1_7i
v2007-Sep-10
xwidget-0.2
zsh-merge-ognus-1
zsh-sync-ognus-2
zsh-sync-ognus-3


-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Courage is resistance of fear, mastery of fear, not absence of fear.

Re: Tag cleanup

[Eli Zaretskii]

> From: esr@thyrsus.com (Eric S. Raymond)
> Date: Thu,  9 Jan 2014 00:37:29 -0500 (EST)
> 
> Please examine this list of tag names,  I want to know which should 
> be thrown out to reduce clutter.

I think everything except EMACS_PRETEST_* and emacs-xx.yy (why the
different letter-case and syntax, btw?) should be removed.  Those
other tags are of no importance once the corresponding features have
landed on mainline.  For example, emacs-bidi-base can certainly go.

But please wait for the "owners" of those other tags to speak up, I
don't want to usurp anyone's tags.

> The question is what out of the remainder is dispensable clutter.
> The *PRETEST* labels seem like obvious candates

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.

If we leave those pretest tags (I think we should), then they are
better renamed to something like emacs-pretest-xx.yy.zz.

Re: Tag cleanup

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

() Eli Zaretskii <eliz@gnu.org>
() Thu, 09 Jan 2014 09:00:12 +0200

   wait for the "owners" of those other tags to speak up

Please keep ttn-* for now.  I will resolve those after the switch.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Tag cleanup

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> 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.

>                                                          Those
> 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>

Re: Tag cleanup

[Ulrich Mueller]

>>>>> On Thu, 9 Jan 2014, Eric S Raymond wrote:

> 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.

In Gentoo, we have a "live" ebuild for Emacs that fetches from the
upstream VCS repository. When fetching from git, we use shallow clones
by default, because history is not interesting for this use case.

Obtaining the raw SHA1 (with "git rev-parse HEAD" or similar) will
still work for shallow clones, while "git describe" won't.

There's a related downstream bug: https://bugs.gentoo.org/489100
Quoting from there: "Is this really worth non-shallow fetches? We're
talking about increasing overhead seriously for the sake of pretty
version string." I'm passing this question on to you. ;-)

Ulrich

Re: Tag cleanup

[Eric S. Raymond]

Ulrich Mueller <ulm@gentoo.org>:
> In Gentoo, we have a "live" ebuild for Emacs that fetches from the
> upstream VCS repository. When fetching from git, we use shallow clones
> by default, because history is not interesting for this use case.
> 
> Obtaining the raw SHA1 (with "git rev-parse HEAD" or similar) will
> still work for shallow clones, while "git describe" won't.
> 
> There's a related downstream bug: https://bugs.gentoo.org/489100
> Quoting from there: "Is this really worth non-shallow fetches? We're
> talking about increasing overhead seriously for the sake of pretty
> version string." I'm passing this question on to you. ;-)
> 
> Ulrich

Thank you.  I consider that this resolves the describe-vs.-SHA1 question.
Not in a way that I like, mind you, but that's life.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Tag cleanup

[Yuri Khan]

On Thu, Jan 9, 2014 at 12:37 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Please examine this list of tag names,  I want to know which should
> be thrown out to reduce clutter.

I think there should be a question which tags should become annotated
cryptographically signed permanent part-of-history tags (my guess is
at least all release and point-release tags, and probably pretest tags
if they are to stay), and which should remain lightweight transient
just-pointer-to-commit tags (I guess all private)

Re: Tag cleanup

[Eric S. Raymond]

Yuri Khan <yuri.v.khan@gmail.com>:
> On Thu, Jan 9, 2014 at 12:37 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> > Please examine this list of tag names,  I want to know which should
> > be thrown out to reduce clutter.
> 
> I think there should be a question which tags should become annotated
> cryptographically signed permanent part-of-history tags (my guess is
> at least all release and point-release tags, and probably pretest tags
> if they are to stay), and which should remain lightweight transient
> just-pointer-to-commit tags (I guess all private)

That question was going to be phase two after I got the list decluttered.

(I agree witn your guess, as far as that goes.)
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Tag cleanup

[Glenn Morris]

I don't want to see any tag related to Emacs removed of renamed.
I just want the libc* etc junk gone.

Re: Tag cleanup

[Glenn Morris]

Glenn Morris wrote:

> I don't want to see any tag related to Emacs removed of renamed.

s/of/or