Re: Updated proposal for improving the FTP NEW process
Adrian Bunk writes ("Re: Updated proposal for improving the FTP NEW process"):
> On Mon, Apr 09, 2018 at 02:24:23PM +0100, Ian Jackson wrote:
> > apt-listchanges will present the right section of the changelog
> > anyway.
>
> Assuming your "skip 10 versions and use one changelog stanza"
> suggestion is done.
I could be wrong, but I'm pretty sure apt-listchanges as run by
aptwill show multiple changelog stanzas when that is appropriate.
This is quite straightforward to do since all of the information is
available.
If it oesn't do that then that is obviously a bug, because it will
DTWT if for any reason the system misses an update recorded in the
changelog. For example, on a system tracking when testing updates
straight from version N to N+3 (because N+1 and N+2 didn't migrate for
whatever reason).
> > Furthermore, of it really does get to 10 versions, containing
> > absurdities, then the most-recent-version's changelog stanza can
> > contain a summary of the differences from the previously-accepted
> > upload.
>
> I've had cases where the only thing I criticized in a sponsorship
> request was "this change is not mentioned in the changelog".
>
> What I got was an updated package with an added line in the changelog,
> and that was perfectly fine.
>
> As sponsor, being nitpicky about good packaging becomes less desirable
> if this would result in skipped versions in the uploaded package.
I would have asked the sponsee to bump the version too. I might not
have insisted on a new changelog stanza. (In practice I have very few
sponsees and I feel guilty enough about the poor service I offer to
them that I avoid being picky about this kind of stuff.)
> > > Or a more funny issue:
> > > How would you notice a version reuse in all cases?
> > > A package uploaded to mentors.d.n. adopting a package with
> > > "New maintainer" as only change is usually a reject. If some DD does
> > > the same years later, there is no record anywhere that this version
> > > was already taken by some random person from the internet who once
> > > upon a time uploaded it to mentors.d.n.
> >
> > That a bad practice cannot always be detected by tooling does not make
> > it a good practice.
>
> Imagine tomorrow a random person from the internet noone has ever heard
> of uploads a package dgit 5.0 to mentors.d.n.
>
> It is clear that this would not be sponsored.
>
> "detected by tooling" would mean that this would result in dak
> autorejecting any future uploads of a dgit package version 5.0
> to Debian.
This is a very strange response. I said
That a bad practice cannot always be detected by tooling does not
make it a good practice.
You concluded that I think it desirable for every bad practice to be
completely prevented by tooling. I find it difficult to see how you
think that would follow.
For the avoidance of doubt, I think there are many bad practices
which: (i) cannot always (or ever) be detected by tooling
(ii) if they could be detected, ought not to be completely prevented
(because a human might have a good reason).
Certainly in the scenario you describe I would like something to warn
me, to give me the option to pick a different version number. I would
probably do so the reasons Russ explains.
The reason why I shouldn't be completely _prevented_ is a matter of
proper process and security engineering. Mistakes by lower-privileged
people should not be able to completely block work by
higher-privileged people. That doesn't mean that the
higher-privileged person shouldn't be made aware of the situation so
that they can explicitly choose what the appropriate response is.
.oO{ dgit push --deliberately-collide-version-mentors }
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> 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.
Reply to: