Versions and revisions

[Ian Jackson <ian@chiark.chu.cam.ac.uk>]

The removal of the revision field was discussed and agreed in July.  I
note in particular that Bill Mitchell seemed quite happy with the
idea, apart from one issue (arguments to maintainer scripts) that I
answered.

There was two weeks' worth of time for any objections to be raised,
and no significant ones were.  I believe I answered the queries that
appeared to people's satisfaction.  The Guidelines were only amended a
few months later (they were generally in a state of disrepair at the
time).

The separate revision control file field *was* causing confusion
amongst users.  We need to have a single version string presented to
the user and visible in all the relevant contexts.  Asking the user to
copy both a version and a revision into separate fields in bug
reports, for example, is needless extra bureaucracy.

So, in summary:

1. This decision was made several months ago for reasons that are
still valid.  It was made by consensus, not by fiat.

2. It has been partially implemented.  The fact that only some of the
packages have been modified so far (and only most aspects of dpkg's
behaviour) is not particularly surprising and is not a problem.

3. I have not seen any arguments as to why it should be reversed (as
opposed to messages asserting that it should).

4. This is a separate issue from the question of whether
Debian-specific packages should have revision numbers.

5. Unless someone comes up with a convincing reason why we should
change back we won't.

6. Unless 5. comes true or comes close to coming true I do not intend
to discuss this matter further.  I have better things to do than
field a flamewar about a decision taken 7 months ago.

Furthermore, I object to the following:

Bill Mitchell suggests that we reinstate the revision field, and says:
> However, that probably makes too much sense for us to do it.

This kind of snide comment is unhelpful, IMO.

I find it especially galling that he now has the temerity to say that
reversing the earlier decision `makes too much sense for us to do it'
when he didn't present his objections to the decision when it was
being made.

Bill also posted a survey of packages `present on a system [he has]
handy'.  This is not a good test; he should be looking at the
development tree, where the figures will be different.  I have just
written a script to do this and the answers are: 261 .deb files with a
Package_Revision or Revision field, and 119 without.  This means that
31% of the packages have been converted so far, twice Bill's figure.
Many of the others have had no significant modifications for many
months.

Dirk Eddelbuettel writes:
> [Separate fields] was the case until it the new scheme was
> announced, and later imposed, by Ian J.

I did not impose the new scheme.  I suggested it, answered the few
questions there were about it, posted another message saying that I
proposed to implement it unless there were objections, and (some time
later) implemented and announced it.  I don't remember whether Dirk
was around when it was discussed and decided on, but one of the
relevant messages was reposted by me in January.

I'd like to point out that in general this kind of thing (reopening
old decisions with emotionally-loaded messages with little technical
content) is unlikely to make me more open to listening to people when
there are perhaps legitimate technical problems to be solved.  This is
regrettable of course, and I shall try to avoid it, but I'm only
human.

Answering mail like this also takes time away from me doing more
useful things like writing software.

Ian.