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
upload.
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.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄⠀⠀⠀⠀ A master species delegates.
Reply to: