"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.
--=-=-Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iHUEARYIAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCYyS4CwAKCRAsbEw8qDeG dDCmAQD6klCTyI7ltK4og4+AKQSyXaUOPe3RtTldMwm7e7JiYQEA2CmrgidQgG0t mVROmGNi1D/tJvnSS8C/fKVIOa1rqQM=YlzL
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)