[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: An email address for drive-by bug reports?

>>>>> On 2023-03-01 16:30:01 +0100, Sam Hartman wrote:

 > Honestly, if there is not currently a submitter behind a bug---someone
 > who cares about it and is willing to look into requests for more
 > information or to help confirm a fix---I'm not particularly interested
 > in working on such a bug.

	We’re all volunteers here.  If someone doesn’t want to work
	on a particular issue, they’re IMO at full liberty to not do
	any such work.  (There are exceptions, but ultimately, it boils
	down to whether the person does or doesn’t want to put effort
	into a particular issue / package / etc., possibly to the
	detriment of their other commitments.)

 > To me, that's often a sign the bug should be closed until someone
 > comes along who cares about the issue enough to interact with it.

 > There are exceptions.

 > So I'd be fine with a nosubmitter command or similar, but also with
 > the understanding that it's entirely reasonable for maintainers
 > to close nosubmitter bugs as wontfix-until-some-specific-person-cares.

 > Socially and culturally I do want to emphasize the idea that if you
 > aren't willing (any more) to put energy behind your problem report,
 > it's entirely fine if no one is going to put energy behind fixing it.

 > Having a bunch of problem reports that no one is interested in
 > cluttering up package pages has a cost.  Just for the same reasons
 > you don't want these reports cluttering up your bugs from page,
 > I perhaps don't want them cluttering up my bugs on my package
 > pages if you no longer care.

	My long-time opinion is that so long as the bug is reproducible,
	and does affect Debian users, it’s ought to be in the BTS, open.

	The maintainer(s) can of course indicate their lack of desire
	to invest effort into solving the issue via the wontfix tag;
	no opposition to that.

	For an example, I’ve once spent hours trying to determine the
	cause of a particular problem I was having.  Turns out
	tinysshd(8) from Bullseye has an interoperability issue with
	openssh-client from the same.  It would’ve likely helped me
	if #1006801 were listed on http://bugs.debian.org/src:tinysshd .

	(I’m not entirely sure as to /why/ it got archived, TBH:
	it’s found in 20190101-1, which is still in the archive, and
	fixed in 20220305-1; as such, I’d expect it to remain open
	until Bullseye itself is archived.)

	The problem with the logic quoted above is that a bug that the
	original submitter isn’t interested in can still be affecting
	those who use Debian now; and, unless fixed, can still affect
	those who will use Debian at some later point.  The absence of
	a /record/ of a person interested in the issue is not the same
	as the absence of such a /person/ themselves.

	Personally, I find Debian BTS to be a valuable source of what
	issues there /are./  On occasion, I’d choose between two
	packages based on what bugs are filed for each.  Othertimes,
	I’ll find workarounds there.  Or I might find why a particular
	issue is infeasible to fix in a given package, and start
	searching for another option for the task at hand.

	It’d be sad to see Debian BTS devolve into a bunch of
	maintainers’ personal TODO lists.

FSF associate member #7257  http://am-1.org/~ivan/

Reply to: