Re: DEP1: Non Maintainer Uploads (final call for review)
On Fri, Aug 15, 2008 at 01:22:28AM -0300, Lucas Nussbaum wrote:
> > > o Upload fixing only release-critical bugs older than 7 days:
> > > 2 days
> >
> > > o Upload fixing only release-critical and important bugs: 5
> > > days
> >
> > > o Other NMUs: 10 days
> > Not consistent with my own recommendations, FWIW; if I'm doing an upload
> > that fixes /any/ RC bug, I consider other verifiable bugs to be fair game in
> > the same time frame regardless of their severity.
> At this point of the discussion, I'm not going to re-discuss those
> delays.
That's fine, I'll just continue doing my own thing then... :)
> > BTW, one thing that appears to be missing here is a warning against NMUing
> > for bugs you yourself have filed. I have seen developers file bugs, set a
> > high severity on their own, and declare an NMU without any evidence that the
> > bug has been confirmed or reviewed by a third party. IME these make for
> > some of the worst NMUs that are most likely to be reverted, because they are
> > almost always some other developer's pet issue, which tends to induce a lack
> > of perspective.
> That's indeed a problem. On the other hand, with the above delays in
> use, it's not that easy for the NMUer to move forward without being
> noticed.
If the only delay required is 10 days, a maintainer could miss commenting
within that window from being busy even if they're not on vacation; or the
one email sent by the submitter (the bug submission and NMU declaration)
might have failed to reach the maintainer. Besides which, saying that the
maintainer will notice is IMHO putting the burden in the wrong place; if
someone has a pet bug that they need fixed this badly, they should make the
effort to find someone else (either the maintainer, or another NMUer) who
can fix it for them and provide a sanity check in the process.
> I'd like to move forward with this patch, and amend the
> developers-reference later if it proves to be needed.
I think it is needed and we should already plan on making such an amendment;
but I won't insist that this change should be included in this particular
revision.
> > I'm not really a fan of this bit, and I haven't noticed a whole lot of
> > discussion of it. It does guarantee a consistent sort order between binNMUs
> > and NMUs, so I don't think my non-fandom rises to the level of an objection.
> >
> > Has anyone from the security team commented on whether they intend to /use/
> > this scheme?
> Nobody from the security team commented that they disagree with this
> scheme.
Well unfortunately, nobody from the security team ever commented that they
disagreed with the scheme that was laid out years ago on debian-devel
either, the one that led to the use of +bN for binNMUs; but security uploads
were still being done with an incompatible version scheme well after the +bN
binNMUs were implemented and had started to become commonplace.
I don't imagine the security team are going to notice when this is committed
to the devref, because I think they, like me, probably have other things to
do than re-read new revisions of devref; so I think it would be best to ask
for explicit comment from the security team before publishing an NMU guide
that declares the "right" way for security NMUs to be versioned.
> > "as far as you want to keep them" - but if a maintainer upload /doesn't/
> > want to keep some of the changes, this may mean that some bugs become
> > un-fixed. Is it better then to include the full changelog from the NMU,
> > which means you have to reopen some bugs in the BTS by hand, or to
> > cherry-pick from the NMU changelog into your own changelog, which will show
> > as a branch in the BTS but allow the relevant bugs to be automatically
> > re-closed?
> > Consider also the corner case that you revert some changes from the NMU,
> > include the full NMU changelog as a parent of your upload, and another bug
> > related to the changes you've reverted has been manually marked in the BTS
> > as closed in the NMU version. What process should the maintainer follow to
> > ensure that this bug doesn't remain wrongly closed in the BTS?
> Let's try to stay simple. I really don't want to write a book on NMUs.
> I'd like to assume that the maintainer will do the right thing wrt BTS
> version-tracking. If this proves a problem, we can always detail this in
> the future.
You're giving a concrete recommendation here about /how/ the maintainer
should handle changelog entries, which I'm pointing out leads to suboptimal
behavior in corner cases. This is a question of whether this is the right
recommendation to make, not of whether the maintainer will "do the right
thing wrt BTS version tracking". If the bug that was marked as closed in an
NMU version is archived before the maintainer upload happens, how do you
intend for the maintainer to "do the right thing"? Are maintainers supposed
to look through the full view of all archived bugs on the package, looking
for any that were closed in NMU version, before reverting a change from an
NMU?
So if this isn't the right recommendation to make because it leads to corner
cases that are difficult to detect, we should talk about that instead of
forging ahead with codifying bad advice.
If you prefer not to go through another round of discussion, then I think
this change should be dropped instead, since it makes specific
recommendations about acking NMUs in the changelog that don't exist in the
current revision.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: