Re: Policy: Versioning Macros In The Archive

[Tom Howard]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Peter,

Peter Simons wrote:
> Tom Howard wrote:
> 
>  >> Peter Simons wrote:
>  >>
>  >> So we really can use any kind of @version tag we want,
>  >> as long as it is different every time -- and date stamps
>  >> serve this purpose exceptionally well.
>  >
>  > Actually in that case it makes no difference (in terms of
>  > patching) what type of version is used.
> 
> Thanks for pointing that out. I almost hadn't noticed.
> 
> 
>  > Well, I can see your sold on date stamps.
> 
> Yes:
> 
>   http://www.gnu.org/software/ac-archive/policy.html#use-of-the-version-tag
> 
> 
>  > In that case, can we name them correctly?
> 
> Tom, please pay more attention to what you are saying when
> talking to me. Asking "Can we name them correctly?" implies
> that the name "@version" would be _incorrect_.

Yes, that was what I was implying ;)

> That may be
> your perception, but it obviously isn't mine. So starting
> the suggestion by saying "your choice sucks, so here is a
> better one" is a great way to start a flame war, but it is
> very unlike to _achieve_ anything.

At no point did I say that "your choice sucks", I just disagreed with
your change and voiced that.  I'm starting to suspect that any form of
dissension regarding the archive is not allowed.

> If you want me to change any aspect of my software or
> policy, you will have to convince me.

That's is exactly what I am trying to do.

> That requires stating
> objective reasons for and benefits of your proposed change.
> If you don't provide those, I won't do it. Just saying "what
> you do is wrong, so let's do what I want" will not suffice.

I am well aware of the concept of constructive criticism, this is why I
have tried to provide reasons why I think such a change is bad, such as
the one you quoted immediately below.

>  > The only reason I suggest this is most people don't
>  > expect a version to be a datestamp, hence (working on the
>  > principle of least surprise) we shouldn't call it
>  > @version
> 
> It is my firm believe that when the average user of the
> archive sees two different copies of the same macro, and one
> of them states
> 
>  @version 2000-04-01
> 
> while the other one states
> 
>  @version 2005-01-26
> 
> ..., then he will know _exactly_ what these tags mean.

Yes, they will know what it means, but it doesn't mean there will not be
some element of surprise when a date stamp is used as a version.

>  > It would do a cvs update, then a cvs diff (I can't
>  > remember the patch compatible flags off the top of my
>  > head) and put the result in something like
>  > $PACKAGE-$VERSION-$USER-$DATE.patch.
> 
> That sounds very nice indeed. I would love to have it. Do
> you think you can set that up _working_ in a branch of the
> repository? Once it does work, I'll happily look at it and
> integrate it into the main CVS trunk together with you.

I'll get it working as part of ax_cvs and then submit that as an updated
macro.

>  > With this kind of feature, the submission process (for
>  > both new macros and fixes) could become:
> 
>  > 1. grab the cvs
>  > 2. do your changes
>  > 3. run make patch
>  > 4. send us the patch
> 
> I am not quite sure whether this approach fits the way our
> users actually use the archive. My guess would be that very
> few people make sweeping changes all over the repository,
> most of them will probably modify only a single macro. Those
> who do make sweeping changes have CVS commit rights to begin
> with.

Your choice, but the above handles both sweeping changes and minor ones
equally well.

> That doesn't mean having "make patch" wouldn't be useful,
> though. The features we provide also shape the way the users
> use the archive.

It might make submission very easy, it might not.  I think is something
that has potential, but it's really something we have to play wait and
see with.

>  > With a version number, at least I can indicate the
>  > severity of the change form version to version.
> 
> What kind of severities does the GNU Autoconf Archive want
> to indicate? Remember that we are distributing a bunch of m4
> files, not an operating system. I cannot imagine any case
> where someone would see
> 
>   autoconf-archive-2.0.tar.gz
> 
> on the web site, and would then download
> 
>   autoconf-archive-1.9.1.tar.gz
> 
> instead because he was afraid of the "major changes". So
> what use does the more complex version number have?

Well, if I rewrite my macros (for whatever reason), I would like to be
able to indicate that via the version number (e.g. bump it from 1.x to
2.0), to indicate a major change.  If they could then be release as a
development snapshot or release candidate, then even better.

> People just want to know which release is the _latest_. And
> dates do that better than anything else, because they
> naturally represent _time_.

Personally I want the latest stable release, not just the latest
release.  I'm not implying that the archive isn't stable, I'm just
stating my preference to software in general, since this is counter to
your opinion of what people want.

>  > Well, the only hint I have left for you is that almost
>  > everywhere else uses version numbers, not version
>  > datestamps. They could all be wrong, but I doubt it.
> 
> I doubt there is any "right" or "wrong" when it comes to
> these kind of decisions, and I have great difficulties
> dealing with people who talk in terms of "right" or "wrong"
> about this kind of stuff. Donald Knuth has been signifying
> the version of his TeX software by converging against Pi.
> Nobody else has been doing that, so according to your logic,
> Donald Knuth was WRONG.

Yes, I think he is, and you can quote me on that.  I will remain
thinking so until I see a convincing argument as to why conversion to Pi
 makes a good versioning scheme.

> So please go ahead and e-email him to let him know that he
> is a prick

I don't see why it would be necessary to attack him personally.

> and that TeX is fundamentally broken and offer
> him your help in getting it fixed with some kick-ass
> Automake script. I bet you wouldn't be doing that. When it
> comes to my project though, you do exactly that.

If I was involved in his project and he suddenly changes the versioning
scheme to one that I disagreed with, without any consultation what so
ever, then yes I would voice my disagreement.

One other thing about the version changes, do you realise that you have
effectively forked every single macro except those maintained by
yourself.  What happens when I update my macro, do I have to keep my
copy in sync with your versioning system, or will you take the burden of
merging the versions?  If the latter, then why do you bother creating
extra work for yourself?  If the former, what if the organisation I work
for has a macro versioning policy that conflicts with yours?

Cheers,

- --
Tom Howard

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x433B299A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+Bljw1G4ZUM7KZoRAt4KAJ9iAWL6G5VDHtJzcOlVIKJSeNaMkgCaA8OD
VN62QFGgRmSLF6rbetS7dHg=
=lQYp
-----END PGP SIGNATURE-----

tomhoward.vcf
Description: Vcard