On Fri, May 30, 2025 at 02:39:19PM +0100, Simon McVittie wrote:
>
> This seems like a good opportunity to point out that for non-trivial
> changes, it's often a good idea to have a bug report (or issue, or
> whatever this particular project uses) *anyway*, as a place to put a
> solution-neutral problem statement. The change that's being proposed
> is often one of several ways to address a particular problem, and if
> the maintainer is being asked to reverse-engineer the problem from
> the proposed solution, that makes it harder (and more
> time-consuming, and less likely to be done) to review the proposed
> change and assess whether it's a good solution to the problem.
>
> If maintainer bandwidth is the limiting factor in a particular
> project (which it often is), then it's all the more important to
> provide a good bug report (steps to reproduce / expected result /
> actual result) or a user story for a new feature (who wants the
> proposed feature and why) so that it's as easy and quick as possible
> for the maintainer to understand that the proposed solution is a
> good one....
The other thing to note is that sometimes sending the bug report and
patches to upstream can often be a much better way of dealing with
maintainer bandwidth. For example pull requests sent to e2fsprogs at
github are considered second class citizens, which only I look at when
I have time. Patches sent to linux-e...@vger.kernel.org are much more
likely to get attention from other ext4 developers (some of whom
package for SuSE or RedHat, instead of Debian, so there is a lot more
review bandwidth).
Also, plus one on sending reliable reproducers, not just patches. For
bonus points, if there is a regression test suite (such as I have for
e2fsprogs), creating a minimum reproducer using a small file system
and adding a test case will earn you a *lot* more attention.
- Ted
