Web lists-archives.com

Re: Updated proposal for improving the FTP NEW process

On Tue, Mar 06, 2018 at 03:17:11PM +0000, Ian Jackson wrote:
> Scott Kitterman writes ("Re: Updated  proposal for improving the FTP NEW process"):
> > If you consider it absurd to not increment the revision due to
> > changes that never made it in the archive, then I don't know where
> > it stops.
> 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

This is what I was taught, and what I not only recommend but also require of
sponsorees.  There seems to be a concensus on -mentors that this is the
right way.

I'm not arguing that a change here is unacceptable, merely describing
currently agreed upon convention.

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

You can have private history published publicly in git, but it's best to
refrain from pushing a tag until the version has been accepted.  That's why
git doesn't push tags by default when you push the branch they apply to.

⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄⠀⠀⠀⠀ A master species delegates.