Re: DEP1: Non Maintainer Uploads (final call for review)
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
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 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
> 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.
The change is needed, since the BTS needs to know if the bugs are closed
in that version or not.
Could you propose an alternative wording for the following paragraph?
When a package has been NMUed, the maintainer should acknowledge it in
the next upload. This makes clear that the changes were accepted in the
maintainer's packaging, and that they aren't lost again. For this, you
must first incorporate the changes into your package, as far as you want
to keep them. Make sure to include the NMU's changelog entry (not just
the line describing the changes) in your own changelog. This is
important to allow the BTS version tracking to work.
| Lucas Nussbaum
| firstname.lastname@example.org http://www.lucas-nussbaum.net/ |
| jabber: email@example.com GPG: 1024D/023B3F4F |