Re: Updated proposal for improving the FTP NEW process
Adam Borowski writes ("Re: Updated proposal for improving the FTP NEW process"):
> On Tue, Mar 06, 2018 at 03:17:11PM +0000, Ian Jackson wrote:
> > IMO Debian's rules should require that the revision should be
> > incremented (at least) when you have shared the previous revision with
> > other people as part of your Debian work. That includes people who
> > are processing NEW, sponsors, etc.
> With my one of most active sponsors hat on: the current policy is that a
> version that has never hit the archive must not have a separate changelog
> entry, unless there are non-negligible users (such as a derivative, upstream
> repository or at least the package being deployed to multiple users at a
> workplace). A past history is more acceptable than repeated attempts for an
Certainly in the exceptions you list, a separate changelog entry is a
I don't see where this policy you are implementing is written down.
It doesn't seem to exist in policy or even the dev ref.
> A changelog bloated with every replaced attempt is hard to read; gaps in
> version numbering that come without an explanation also raise an eyebrow
> (thus such a gap needs a comment in the changelog).
How many replaced attempts are we typically talking about ?
When an attempt is replaced, the reviewer would no doubt like not only
the whole new package, but a human-readable summary of what the
submitter has intentionally changed. How do you think that
human-readable summary ought to be communicated to the reviewer ?
I disagree that gaps in the version numbering require an explanation,
but even if they do then that is not a problem.
(Of course that the Debian revision does not need to be a single
integer. If you want to distinguish various attempts from the
accepted submissions one could write -1.1 or something.)
Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.