XPost: linux.debian.policy
On Tue 15 Jul 2025 at 12:03pm +02, Otto Kek�l�inen wrote:
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?
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).
went and merged it themselves
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.
On Tue, 15 Jul 2025 at 11:43:01 +0100, Sean Whitton wrote:
The thing about DELAYED is that it's fire-and-forget for the contributor >actually doing the work, which is an advantage.
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)