Re: Updated proposal for improving the FTP NEW process
On Tue, Mar 06, 2018 at 06:15:10PM +0000, Ian Jackson wrote:
> 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
> > upload.
>
> Certainly in the exceptions you list, a separate changelog entry is a
> good idea.
Yeah, but my point is that, except those cases, current consensus seems to
be that there should be no separate changelog entries, no versions and no
tags.
(I say "seems" because there was no formal vote or formal thread, but when a
sponsoree produces such a changelog, no one among usual sponsors ever said
anything to the contrary.)
> 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.
Alas, same applies to most of conventions. It would be good to have such
things documented rather than learned by osmosis, but describing processes
is something no one volunteers for.
> > 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 ?
Ten is a quite extreme case, but 3-4 are common. (Obviously most uploads
get in on the first go.)
> 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 ?
That's what we have RFS bugs. Every publicly reviewed upload has a
permanent trail. The majority of uploads go this way.
There's no requirement to ask for review publicly, but private channels also
allow adequate communication with the reviewer. Heck, as someone who
sponsors ~10× as many uploads as I do myself, I tend to use the same routine
I do for sponsoring for my own uploads. In this case, the communication is
entirely within my brain!
And, the summary is not what's being checked. I for one tend to skim over
RFS mails with so little attention I sometimes miss remarks from the
sponsoree -- looking only at debian/changelog. This is what I read
carefully, comparing what's written there with what's in debdiff vs the last
version in the archive.
Comparing debdiffs is the main manual part of review. And why would I care
that the shed got repainted red then blue, if it was black the last time it
was in the archive and is pink now? This kind of details is ok for untagged
commits in git, but neither the reviewer nor the end user are interested in
changes that have been superseded between tags/uploads. The process that
led you to decide on pink might be interesting but it's not what is being
reviewed.
The less _irrelevant_ information, the less work for us. If the talk is
archived on the RFS bug, there's no information loss either.
> I disagree that gaps in the version numbering require an explanation,
> but even if they do then that is not a problem.
Gaps can be useful, but most of the time they're unintentional, that's why
there's a need for a comment.
> (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.)
Uhm, that's reserved for NMUs.
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: