Re: How to motivate contributors to work on QA
Dear DPL candidates,
I would like to expand on the following example with a data point:
On 23.03.21 10:42, Christian Kastner wrote:
> Example 2#: Undermaintained packages, especially in stable
> ~~~~~~~~~~~
>
> This is something that every contributor, including me, can probably
> relate to.
>
> There are some packages that have a maintainer, but that maintainer does
> not have sufficient time to devote to the package, sometimes to the
> point where filing a bug is pointless.
>
> Some of these issues can be fixed by NMU. Many aren't. For example, I
> think the share of non-DSA security issues and important bugs that can
> be fixed in stable could be much larger, but that's quite a bit of extra
> work compared to fixing something in unstable.
According to [1], there are currently 485 RC bugs affecting stable. I
assume that the number of non-DSA security bugs affecting stable is
notable, too.
Clearly, most of those packages have active maintainers, so it's not an
issue with orphaned/RFA'd packages.
I'm going to go out on a limb here and make a bold assumption: these
bugs aren't fixed because reproducing, diagnosing and fixing a bug in
stable is generally far more resource-consuming than fixing something in
unstable, and thus hits the limits of volunteer work earlier.
Our commitment to quality is apparent in the process of a new release,
with the song and dance of transition/soft/hard freeze, and all that
they entail.
But what can the Project do to uphold this commitment even *after* a
release? Isn't that the release that most of our users will be using?
And, more specifically (again showing my bias), why shouldn't the
Project use its significant financial resources to address this problem?
Not necessarily to motivate the maintainers, but other contributors,
say, in the form of bug bounties, or whatever?
Best,
Christian
[1] https://bugs.debian.org/release-critical/other/stable.html
Reply to: