On 15/08/08 at 22:59 -0700, Steve Langasek wrote:
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... :)
Sure, those are only recommended delays.
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.
OK, thank you.
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.
I asked them to comment in a separate email.
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
