Re: How to Move an Issue Forward When there is no Energy
On 9/16/22 1:53 PM, Sam Hartman wrote:
> >>>>> "Chuck" == Chuck Zmudzinski <brchuckz@netscape.net> writes:
>
> Chuck> Debian processes: AFAIK there is no process for a user to
> Chuck> resort to when an important bug has been ignored for over a
> Chuck> year except to make some noise on mailing lists like
> Chuck> debian-user and debian-project. What would you suggest as a
> Chuck> better process to handle cases like #983357?
>
> TL;DR: Maintainers do not have to work on any particular problem, but
> they do not get to block others' work. First step is to figure out the
> fix for a problem, propose the fix, and eventually get to an NMU
> proposal.
>
> Hi.
> I agree with Branden that engaging with Chuck may not be the most
> productive use of my time.
> However, I think the above question is a great one, and regardless of
> whether my answer is useful to Chuck, I think it might be generally
> useful.
>
> The first step is to find a solution for Debian.
> If the problem is an upstream problem, often the best answer for Debian
> is to fix it upstream.
> But until there's someone who believes they know what the solution is,
> the problem is not a process problem, it's a manpower problem.
>
> Sometimes problems with multiple fixes possible are particularly
> difficult as has been pointed out in this thread.
> And yes, relevant maintainers may have opinions.
> But there are no process obstacles to someone else learning about the
> software, learning about the trade offs, and making a recommendation.
> Sure, it might be hard work. Learning Xen, the kernel, and trade offs
> between them isn't going to be a short afternoon task by any stretch.
> But if you have the relevant development skills, and care enough, you
> can learn those things and come up with a proposal.
>
> If you as a user aren't in a position to figure out the solution, there
> are a few things you can do:
>
> * Make sure there is a good bug report
> * If you could test changes or work to collect diagnostics make that
> offer
>
> * If you're willing to pay for someone to work on the issue, that would
> be good. Debian does not have a process to track or deal with such
> offers, and so I don't have specific advice on how to make an offer to
> fund development of a particular fix that would be helpful.
>
> But if there is a patch waiting that someone knowledgable believes is
> the right fix for Debian, then things can eventually move forward.
> People have pointed out that maintainers (and developers) do not need to
> respond to any given bug.
> That's true, but maintainers and developers do not get to block work
> either.
> If there's a patch that a maintainer hasn't had time to review,
> eventually it would be appropriate to prepare an NMU for the package
> incorporating the patch.
> Anyone with the relevant skills can propose an NMU. You don't need to
> be a DM or a developer.
> You just need to understand Debian packaging, understand the software,
> and understand the fix.
> If you are not a DD or a maintainer of the package in question, you need
> to find a DD to sponsor the NMU.
> The same process can be used to request sponsorship of a NMU as for
> sponsorship of another upload.
Hello Sam and Diederik,
Although you (Sam) said that engaging with me is not a good use
of your time, I am wondering if you are inviting me to try to
find a sponsor to do an NMU to fix #983357, or perhaps you
are asking Diederik, a member of the Debian Xen Team, to
find a sponsor to do an NMU, to fix it, because there are too many
people who would be against trusting me with the task.
Diederik, what do you think of the idea of finding a sponsor
to do an NMU to fix #983357? You could propose uploading
Ben's proposed patch as part of the Debian patches relative to
the Linux upstream source and keep it in there until all the
relevant parties, which includes upstream Linux, upstream
systemd/udev, and to a lesser extent for Ben's patch, upstream
Xen, can agree on the best fix for the problem. The problem
really is not a bug in Xen, but it could be that Linux and
systemd/udev maintainers will decide they want to keep the
buffer size in the kernel at 2k, in which case the fix would
have to come from Xen upstream who would need to propose
a patch to fix the Xen keyboard driver so it does not create
data that exceeds what the kernel uevent buffer can handle.
I don't know when #983357 would be closed, with the NMU,
or not until the upstream fix comes. The sponsor could provide
advice about that.
Best regards,
Chuck
Reply to: