Hi,

The delayed/deferred queue mechanism is documented in section 5.6.3
(Delayed uploads). However
https://lists.debian.org/debian-devel-announce/2008/09/msg00006.html has
more details about queue handling, that should be integrated in
developers-reference.

I will try to provide a patch/MR, but feel free to beat me to it.

Lucas

+1 to clarifying the DELAYED queue section. Please also include an
example dcut command on how to remove a package from the DELAYED queue
if the maintainer does not want to have it.

Personally I would much rather see a contribution being submitted to
my packages as a Merge Request on Salsa, than as a NMU via DELAYED. If
I am active, I can immediately engage in discussion about the change.
If I am really busy I can just merge it without discussion, or comment
that I am fine with it but don't have time to review deeper. If I am
completely missing, I would be fine if somebody posted a MR and then
after a few weeks went and merged it themselves and uploaded. This
would still feel more collaborative than noticing a new package
version as NMU in DELAYED. Does this resonate with others?

Hello,

Yeah, me too (though I'd prefer a BTS bug to an MR, but it's the same).

The thing about DELAYED is that it's fire-and-forget for the contributor
actually doing the work, which is an advantage.

Expanding a little on what Sean said, let's suppose your foobar_1.2-3
package has a sufficiently bad bug to justify a NMU, and I have some
time available and I want to fix that bug.

What I would often want to do as the contributor, if I have limited
time, is:

* ensure there is a bug open with a solution-neutral problem statement
   about the bug I'm fixing (open it if necessary)
* make and test the change
* send a MR (and/or a patch in email), either versioned as
   "1.2-4 (UNRELEASED)" or without touching the changelog at all, with
   the change that I'm proposing you should make
* mention in the bug/MR that I'm going to NMU it to DELAYED to make sure
   that a fix will land in a timely way
* locally adjust the changelog to be a NMU versioned as 1.2-3.1 or
   1.2-3+nmu1, and build and re-test it
* upload my NMU to some appropriate DELAYED queue
* send the nmudiff to the bug because devref says I must, but point to
   the MR as the "canonical" version

That way, if neither you nor I act on it further because we're both
busy, the "default" will be that my NMU reaches the archive a few days
later and the bug gets fixed; and getting a fix into the archive doesn't
depend on me remembering to come back to this bug several days later, by
which time I might have become distracted by some other priority.

If one of us *does* have time later, the maintainer can preempt the
DELAYED change by either converting it into a higher-version-numbered
maintainer upload if they approve, or uploading a better solution if
they do not approve; or the other contributor can cancel their delayed
NMU if it becomes clear that it shouldn't be accepted, or re-upload
without delay if they're given permission to do so (or even without
permission, if they find out that fixing the bug is more urgent than
they had previously thought).

Hopefully that's a workflow that everyone could be reasonably happy with?

If I happen to have the time available at the time that my delayed NMU
hits the archive, *then* I could optionally come back and merge the MR
(although I would personally tend to just update it with the NMU's
changelog entry at that point, leaving it up to the maintainer whether
they want to merge it as-is or do something completely different,
because that way the maintainer gets to control their package's
"official" history).

The contributor doesn't necessarily have commit/merge access to every
repo where they might find themselves stepping in and fixing a nasty bug
(especially if they are a non-DD who needs to get their NMU sponsored),
but they certainly have the ability to send patches-in-email, and
hopefully MRs as well.

I agree that when the contributor doing the work can only spend a
limited amount of time and attention on it, there is value in grouping
together all of the work to be done the same day (make the change, send
to BTS, send MR if desired, upload to DELAYED) so that in the absence of
any other action being taken, the proposed fix will reach the archive
without the contributor needing to actively herd it through the process.

I'm not sure that I see a situation where it would be rational to use
DELAYED, but unacceptably slow to open BTS bugs or MRs?

For any upload to DELAYED, I would usually expect a bug in the BTS
whatever else happens: an uploader should only use DELAYED in cases
where it's acceptable for there to be a delay of a few days before the
fix actually reaches the archive, and if that's the case then opening a
BTS bug before uploading is not going to have a significant impact on
the time-to-fix. I'd personally prefer the actual proposed change to be
in the form of a MR rather than patches-in-email, but I think there's
often value in reporting a solution-neutral problem statement to the BTS
before (or at the same time as) proposing a solution, because sometimes
the first solution proposed is not actually the best answer to the
stated problem, and we should make it as easy as possible for a
maintainer to be able to say "yes, this is a good solution" or "no, this
isn't a good solution" (or even "no, this isn't a valid bug").

In cases where the time taken to open a BTS bug or a MR would be
unacceptable, like a very bad regression or an actively-exploited
security vulnerability, surely the time delay of DELAYED would not be
acceptable either? In this case I'd expect the uploader to NMU first
(very carefully!) without using DELAYED, and then open a BTS bug with
the nmudiff afterwards, again accompanied by a MR if they're feeling
helpful.

     smcv

Hello,

It's not about speed, but about being able to set the bug aside.
I.e., the "forget" is the key word.  I track everything meticulously in
Org-mode tasks but many volunteers are keen not to have personal to-do
lists for work done in their free time.  Fire-and-forget enables that.

Right

Maybe it would be better to focus this bug for discussing how to improve
the section of developers-reference that describes DELAYED queue
handling, and move the discussion about MR-based workflows elsewhere?

We can improve the current process and discuss a new process at the same
time (in different fora), and drop the current process when the new
process is ready and widely accepted.

Lucas

I definitly prefer an MR for such a change.

(For more controversial changes I prefer to have a BTS track record, because
salsa can go away, while the BTS will stay with us forever...)

I think that Otto and Sean are discussing the merits of DELAYED vs MR vs
bugs for NMU-like contributions, while you are discussing how this
particular contribution (improving doc) should be handled.

Lucas

ah, lol, thanks Lucas. Please ignore what I said then :)

that said, me likes NMUs via DELAYED.

Yes, I was agreeing with you - like I said, grouping together all the
work into one "transaction" has value, and DELAYED enables that.

When I said "unacceptably slow" I meant something more like latency
rather than time taken: it seemed to me as though there was a suggestion
that we should be choosing between proposing MRs (or patches) *or* doing
a delayed NMU, but in the scenarios where DELAYED is relevant, I'd prefer
contributors to consider sending a MR (or patch) *and* doing a delayed NMU.

     smcv

Hello,

Right.  Sounds like we don't disagree at all.

hi,

I see a bit of a discrepancy between the original request (which, judging by the
link to 87skrun5j4.fsf@vorlon.ganneff.de, seems to be mostly about technical
details) and the ensued discussion (which is mostly about NMU/coordination
norms).

Lucas, what exactly did you have in mind when you filed this bug? is there
anything in gannef's email that's not captured in dput/dcut manpages and config
defaults that you think would be useful to include in devref?

on coordination norms: section 5.13.1 ("When and how to do an NMU") seems to
cover all aspects discussed in this bug (e.g. report a bug to BTS, use DELAYED)
with the only exception being an explicit statement that it's okay to file a bug
with a patch (or MR) and _at the same time_ upload to DELAYED so that one can
fire and forget -- which does seem like a worthwhile addition.

thanks,
serafi

tags 1109323 + patch
thanks

Lucas, friendly ping.

everyone: please see attached patch.

thanks,
serafi