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

2023-04-09 Thread Sam Hartman
> "Ivan" == Ivan Shmakov  writes:


>> 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.

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

I appreciate that is your position.
But as I point out in the paragraph above, that position has a cost for
maintainers and for the project as a whole.

What's needed to move forward from such a position is for people to
think about the balance between  the various costs.
I didn't get that you were trying to do that from your message, and I
appreciate that I might not be trying to look at things expansively
either.

You proposed the wontfix tag as related.
I don't think it is.
I might well be willing as a maintainer to fix some of these isues *if
someone cares and is willing to take on the submitter role, working with
me, and confirming fixes*.
That interaction makes it more worth my time as an issue.
Wontfix incorrectly implies that if someone comes along and cares about
the issue I'd be unwilling to work with them.



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

2023-04-02 Thread Ivan Shmakov
> On 2023-03-23 05:30:01 +0100, Don Armstrong wrote:
> On Fri, 17 Mar 2023, Ivan Shmakov wrote:

 >> 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.)

 > Bugs that are fixed in testing, unstable (and experimental) but
 > not RC severity (serious and above) are archived if they have
 > been closed for more than 28 days.

ACK, thanks.  Somewhere along the way I’ve picked a mistaken
understanding of the process.

The end result is that I should pay more attention to archived
bugs, I suppose.

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



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

2023-03-22 Thread Don Armstrong
On Fri, 17 Mar 2023, Ivan Shmakov wrote:
> 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.)

Bugs that are fixed in testing, unstable (and experimental) but not RC
severity (serious and above) are archived if they have been closed for
more than 28 days.


-- 
Don Armstrong  https://www.donarmstrong.com

Rule 30: "A little trust goes a long way. The less you use, the
further you'll go."
  -- Howard Tayler _Schlock Mercenary_ March 8th, 2003
 http://www.schlockmercenary.com/d/20030308.html



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

2023-03-17 Thread Ivan Shmakov
> 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/



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

2023-03-07 Thread Paul Wise
On Mon, 2023-03-06 at 16:56 -0800, Don Armstrong wrote:

> This is my viewpoint too, and why I don't plan on implementing or
> accepting a patch to do nosubmitter unless someone can convince me
> otherwise.

The use-case presented in the thread seems reasonable to me; when you
are submitting a bug that you noticed and definitely exists (and is
easy to reproduce) but that you don't really care about.

For example some folks mass-file FTBFS or other QA bugs but don't care
about or use the individual packages. Or I might notice a typo while
looking at newly available packages or downloaded things, but if the
package isn't one I will install, I don't really care about the bug.

These bugs don't have someone we *know* definitely cares about them,
but the are still likely to affect *unknown* persons, either Debian
users or users of the upstream package on other platforms and thus
it is still reasonable that they be filed as bug reports somewhere.

Personally, I've replied to moreinfo requests on bugs for packages I
no longer use so I wouldn't use this feature, but I can see its value.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part


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

2023-03-06 Thread Don Armstrong
On Wed, 01 Mar 2023, Sam Hartman wrote:
> Honestly, if there is not currently a submitter behind a bug […]
> that's often a sign the bug should be closed until someone comes along
> who cares about the issue enough to interact with it.

This is my viewpoint too, and why I don't plan on implementing or
accepting a patch to do nosubmitter unless someone can convince me
otherwise.

[Submitter is a currently non-optional field; if a bug does not have a
submitter, the BTS will not accept the bug. Making it optional would be
more work than adding the control command.]

-- 
Don Armstrong  https://www.donarmstrong.com

"The trouble with you, Ibid" he said, "is that you think you're the
biggest bloody authority on everything"
 -- Terry Pratchet _Pyramids_ p146



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

2023-03-01 Thread Gioele Barabucci

On 01/03/23 16:22, Sam Hartman wrote:

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.


That seems to me like a perfectly fine social agreement.

And not much different to what happens with orphaned packages (you don't 
maintain the package anymore, don't expect others to put in the effort 
to do it).


Regards,

--
Gioele Barabucci



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

2023-03-01 Thread Sam Hartman
> "Gioele" == Gioele Barabucci  writes:

Gioele> For example I have opened bugs years ago against packages
Gioele> that I do not use anymore. These reports are still valid and
Gioele> sometime others comment on them, but I would no longer be
Gioele> able to, for example, respond to `moreinfo` requests. At the
Gioele> same time these bugs clutter the bugs.d.o page associated to
Gioele> my email address.

Gioele> It would be nice to have a separate email address to which
Gioele> these bugs could be reassigned (maybe after a minimum amount
Gioele> of time?).

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.
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.

Again, that's not always true, and it will be dependent on the
individual maintainer and the bug.


signature.asc
Description: PGP signature


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

2023-02-28 Thread Paul Wise
On Tue, 2023-02-28 at 18:36 +0100, Gioele Barabucci wrote:

> Should there be a standard email address for "I'm reporting this because 
> I noticed it, but I'm not interested in it"-bug reports?

Similar to the BTS noowner command, perhaps add a nosubmitter command?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part


An email address for drive-by bug reports?

2023-02-28 Thread Gioele Barabucci
Should there be a standard email address for "I'm reporting this because 
I noticed it, but I'm not interested in it"-bug reports?


Orphaned packages get their maintainer address set to 
. Shouldn't something similar be available for bugs?


For example I have opened bugs years ago against packages that I do not 
use anymore. These reports are still valid and sometime others comment 
on them, but I would no longer be able to, for example, respond to 
`moreinfo` requests. At the same time these bugs clutter the bugs.d.o 
page associated to my email address.


It would be nice to have a separate email address to which these bugs 
could be reassigned (maybe after a minimum amount of time?).


It could be as simple as a the address of a dedicated mailing list.

Regards,

--
Gioele Barabucci