Debian Bug report logs - #910541
diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

[Message part 1 (text/plain, inline)]
Package: diffoscope
Severity: important

Hi,

I just gave a small presentation about diffoscope at the mirage.io
hackretreat (which was well received) which resulted in people
wanting to file bugs against diffoscope, which turned out to be "complicated":

- the project on salsa has issues disabled (but would require a login on
  salsa anyway), still filing bugs in a webbrowser is something many
  people want to do today, so I think maybe we should enable issues?
- the link "Bugs and feature requests" on https://diffoscope.org just
  points to https://bugs.debian.org/src:diffoscope - this is helpful for
  Debian developers but hardly for anyone else.
- there is still https://github.com/ReproducibleBuilds but thats empty, 
  so noone could file issues there.

I've got no good idea how to fix this best, but I wanted to at least
document this so we can come up with something better. It's unfortunate
to say 'please file bugs' and then...

-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]
severity 910541 normal
thanks

Dear Holger,

> I just gave a small presentation about diffoscope at the mirage.io
> hackretreat (which was well received) which resulted in people
> wanting to file bugs against diffoscope, which turned out to be "complicated"

Completely, 100%, agree.

(Adjusting severity only because important severity bugs are treated
somewhat different in some interfaces, but agree this is more
severe than "just another" wishlist entry.)

> - the project on salsa has issues disabled (but would require a login on
>   salsa anyway), still filing bugs in a webbrowser is something many
>   people want to do today, so I think maybe we should enable issues?

No strong objection to the principle except that we would then have
some duplication between the two trackers.

I'm thinking specifically of those times when I'd like to pick up on a
previous issue, but then would need to "mentally merge" two lists of
bugs, filtering any potential duplicates, etc.

Do we have any ideas to limit this? One rather brutal way of doing this
would be to insist that diffoscope-on-the-BTS only had Debian-specific
issues and salsa has everything else, forcing people to refile? Or that
salsa is a superset of the BTS & just try and remember to file
everything that arrives in the BTS to.. etc.

Anyone have experience elsewhere that can help?

> - the link "Bugs and feature requests" on https://diffoscope.org just
>   points to https://bugs.debian.org/src:diffoscope

(Let's fix that when this issue is fixed; it would just need updating
and/or expanding)

> - there is still https://github.com/ReproducibleBuilds but thats empty, 
>   so noone could file issues there.

Well, this one is easily "fixed":

  https://i.imgur.com/vXbuKYU.png

Best wishes,

-- 
        O
      // \\     Chris Lamb
     O     O    reproducible-builds.org
      \\ //
        O

[Message part 1 (text/plain, inline)]
On Sun, 07 Oct 2018 22:33:49 +0100 Chris Lamb <chris@reproducible-builds.org> wrote:
> > - the project on salsa has issues disabled (but would require a login on
> >   salsa anyway), still filing bugs in a webbrowser is something many
> >   people want to do today, so I think maybe we should enable issues?
> 
> No strong objection to the principle except that we would then have
> some duplication between the two trackers.

Filling bugs in web browser is indeed something many people expect. But
having two issue trackers introduce a lot of problems. Add to your list
ambiguity of issue numbers.

What about providing appropriate "mailto" link to open new issue on BTS,
including all the magic headers, bug template etc?
Like the "reply" one existing already on BTS (I'm using it right now, I
even get quoted message I reply to!).

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
On Mon, Oct 08, 2018 at 12:15:36AM +0200, Marek Marczykowski-Górecki wrote:
> Filling bugs in web browser is indeed something many people expect.

(grumpy person here that don't understand those people…!)

> What about providing appropriate "mailto" link to open new issue on BTS,
> including all the magic headers, bug template etc?
> Like the "reply" one existing already on BTS (I'm using it right now, I
> even get quoted message I reply to!).

I just added such a link in https://diffoscope.org/ - what do you all
think? :)

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
On Mon, Oct 08, 2018 at 10:22:56AM +0200, Mattia Rizzolo wrote:
> On Mon, Oct 08, 2018 at 12:15:36AM +0200, Marek Marczykowski-Górecki wrote:
> > Filling bugs in web browser is indeed something many people expect.
> (grumpy person here that don't understand those people…!)

I think you're just officially an old person now. Soon you will be part
of the Debian grandparents team! ;)

> > What about providing appropriate "mailto" link to open new issue on BTS,
> > including all the magic headers, bug template etc?
> > Like the "reply" one existing already on BTS (I'm using it right now, I
> > even get quoted message I reply to!).
> I just added such a link in https://diffoscope.org/ - what do you all
> think? :)

awesome, thanks a lot, much much better!

-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
Dear Chris,

On Sun, Oct 07, 2018 at 10:33:49PM +0100, Chris Lamb wrote:
> (Adjusting severity only because important severity bugs are treated
> somewhat different in some interfaces, but agree this is more
> severe than "just another" wishlist entry.)

I agree, was thinking the same when filing the bug...

> > - the project on salsa has issues disabled (but would require a login on
> >   salsa anyway), still filing bugs in a webbrowser is something many
> >   people want to do today, so I think maybe we should enable issues?
> 
> No strong objection to the principle except that we would then have
> some duplication between the two trackers.

while I do agree that duplication is a problem, I think having bugs not
filed because "it's complicated" is worse.

> I'm thinking specifically of those times when I'd like to pick up on a
> previous issue, but then would need to "mentally merge" two lists of
> bugs, filtering any potential duplicates, etc.

we could make the habbit to always file a debian bug and set it
forwarded to the github issue if we'd agree to use github issues... 

but...

> > - there is still https://github.com/ReproducibleBuilds but thats empty, 
> >   so noone could file issues there.
> Well, this one is easily "fixed":
>   https://i.imgur.com/vXbuKYU.png

sigh. for two reasons:

first, I find the style of explaining an issue by the means of a
screenshot to be, dunno, passive aggressive, or maybe just annoying? its
definitly not accessable not stored in the bts, and requires everyone
reading the bts mail to go to a graphical webbrowser (& be online) to
see what you have done... so for those who have not followed that link,
Chris deleted https://github.com/ReproducibleBuilds

second, I was basically suggesting to discuss using the github tracker
and instead of allowing the discussion you killed it within minutes
after my report. surely we could recreate the github project again, but
that would mean everybody again needs to apply to become a member etc.

I actually would have been in favor of allowing people to report issues
on github, just because it has 40mio users, which includes most people
working on reproducible builds, while a.) salsa has a few thousand and
hardly anyone not involved in Debian and b.) filing bugs via mail (while
I like it a lot) is something many people dislike.

But I guess this discussion is academic now. :(

-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]
Hi all.
My way of thinking:

If the program is only for debian, bugs.d.o is a right place to report issues.

If the program aims to a broader audience (multiple distros), the
project repository is the right place to report issues. Also, issues
specific to debian can be filled alternatively in bugs.d.o and later
'sent upstream' the fixes to the project repository.

About the need for create an account in salsa.d.o to report issues, is
the same case in gitlab, github, bitbucket, etc.., the user always
needs to create an account the first time (i don't think that it is
complicated).

Regards,
JMPC.
On Mon, Oct 8, 2018 at 7:21 AM Holger Levsen <holger@layer-acht.org> wrote:
>
> Dear Chris,
>
> On Sun, Oct 07, 2018 at 10:33:49PM +0100, Chris Lamb wrote:
> > (Adjusting severity only because important severity bugs are treated
> > somewhat different in some interfaces, but agree this is more
> > severe than "just another" wishlist entry.)
>
> I agree, was thinking the same when filing the bug...
>
> > > - the project on salsa has issues disabled (but would require a login on
> > >   salsa anyway), still filing bugs in a webbrowser is something many
> > >   people want to do today, so I think maybe we should enable issues?
> >
> > No strong objection to the principle except that we would then have
> > some duplication between the two trackers.
>
> while I do agree that duplication is a problem, I think having bugs not
> filed because "it's complicated" is worse.
>
> > I'm thinking specifically of those times when I'd like to pick up on a
> > previous issue, but then would need to "mentally merge" two lists of
> > bugs, filtering any potential duplicates, etc.
>
> we could make the habbit to always file a debian bug and set it
> forwarded to the github issue if we'd agree to use github issues...
>
> but...
>
> > > - there is still https://github.com/ReproducibleBuilds but thats empty,
> > >   so noone could file issues there.
> > Well, this one is easily "fixed":
> >   https://i.imgur.com/vXbuKYU.png
>
> sigh. for two reasons:
>
> first, I find the style of explaining an issue by the means of a
> screenshot to be, dunno, passive aggressive, or maybe just annoying? its
> definitly not accessable not stored in the bts, and requires everyone
> reading the bts mail to go to a graphical webbrowser (& be online) to
> see what you have done... so for those who have not followed that link,
> Chris deleted https://github.com/ReproducibleBuilds
>
> second, I was basically suggesting to discuss using the github tracker
> and instead of allowing the discussion you killed it within minutes
> after my report. surely we could recreate the github project again, but
> that would mean everybody again needs to apply to become a member etc.
>
> I actually would have been in favor of allowing people to report issues
> on github, just because it has 40mio users, which includes most people
> working on reproducible builds, while a.) salsa has a few thousand and
> hardly anyone not involved in Debian and b.) filing bugs via mail (while
> I like it a lot) is something many people dislike.
>
> But I guess this discussion is academic now. :(
>
>
> --
> cheers,
>         Holger
>
> -------------------------------------------------------------------------------
>                holger@(debian|reproducible-builds|layer-acht).org
>        PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
> _______________________________________________
> Reproducible-builds mailing list
> Reproducible-builds@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds

Juan,

> If the program aims to a broader audience (multiple distros), the
> project repository is the right place to report issues.

Oh sure, we are all in agreement here but users of diffoscope in Debian
are likely to file their generic issues in the Debian bug tracker,
resulting in duplication. (And where do Debian-specific issues go?
salsa does not seem right for this...)

These is the issues we are discussing, otherwise it would be "easy" to
just move!

Best wishes,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

[Message part 1 (text/plain, inline)]
On Mon, Oct 08, 2018 at 03:21:41PM +0100, Chris Lamb wrote:
> Oh sure, we are all in agreement here but users of diffoscope in Debian
> are likely to file their generic issues in the Debian bug tracker,
> resulting in duplication.

I dont think this is a problem, or rather a problem with diffoscope, but
rather with all the other 26000 source packages too. And the solution is
simple and the same as everywhere: forward those bugs to the upstream
tracker.

(just that we dont have an upstream tracker atm...)

-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]
Dear Holger,

> […]

I'm sorry this appears to have upset you so much I'm afraid I'm
somewhat struggling to see the full extent why.

Not only was the entire GitHub organisation empty (and was at least
since the salsa migration), it was highly misleading and, naturally, we
can recreate it within 60 seconds.

(I also would have thought that any solution to /potential/ duplication
of issues between the Debian BTS and salsa would not be to introduce a
_third_ entity anyway, and alas GitHub Issues cannot really be used
without also duplicating the code there too, making the workflow for
code even worse too. Indeed, this is what I was definitely finding
before when we had a mirror.)

Naturally, if I thought this would have been a problem I would not have
pushed the button.

Best wishes,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

[Message part 1 (text/plain, inline)]
Dear Chris,

On Mon, Oct 08, 2018 at 03:36:55PM +0100, Chris Lamb wrote:
> I'm sorry this appears to have upset you so much I'm afraid I'm
> somewhat struggling to see the full extent why.

and

> Naturally, if I thought this would have been a problem I would not have
> pushed the button.

sure, I never doubted that! :)

As I tried to explain was the combination of the immediate action
itself, coming from a discussion which was just started, combined with
explaining/announcing this action with a screenshot (which itself I'm
sure was ment 'funny' or geeky or some harmless/nice thing).

> Not only was the entire GitHub organisation empty (and was at least
> since the salsa migration), it was highly misleading and, naturally, we
> can recreate it within 60 seconds.

It has been that way for months, so I dont understand the perceived
hurry. Also that organisation still had members (which surely can be
added easily), so I think my main complaint is what I wrote above: the
combination of... (see above :)

anyhow, i dont hold any grudge or anything and would prefer to move on
with the question at hand:

> (I also would have thought that any solution to /potential/ duplication
> of issues between the Debian BTS and salsa would not be to introduce a
> _third_ entity anyway, 

2nd, we dont have issues on salsa enabled.

> and alas GitHub Issues cannot really be used
> without also duplicating the code there too, making the workflow for
> code even worse too. Indeed, this is what I was definitely finding
> before when we had a mirror.)

so let's get the mirror back and track upstream issues on github?

I was going to write "Or let's accept that diffoscope is a 'Debian
Reproducible Builds Project' and use the BTS or salsa for upstream bug
tracking too" but then I realized that we have the same problem with eg
the website, though there it's probably less a problem as we strive less
for drive-by contributors there.

But I think we want to move something distro agnostic, and salsa.d.o
is very much Debian centric, so I think we should look for something
else. I'd be fine to using github.com or gitlab.com or foobar.

-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]
About issues: We can't change where the users create bug reports, only
suggest the correct place to do it. The extra work for BTS/salsa
issues (if enabled) for me is inevitable.

About the move from salsa.d.o, the question is: salsa.d.o can be used
for general projects born in debian or is most suited for debian
specific projects?

If salsa.d.o is suited, the next step should be enable the issues in
the repository and handle the work of manage duplicated issues between
the repository and the BTS,  while the users understand the correct
place to create issues.

If as Holger suggests, salsa.d.o is very much Debian centric then has
sense look for a new home for diffoscope and maybe other rb
repositories (eg website).
Personally i expect not.

Regards,
JMPC

Hi Holger,

> But I think we want to move something distro agnostic, and salsa.d.o
> is very much Debian centric, so I think we should look for something
> else. I'd be fine to using github.com or gitlab.com or foobar.

Let's try and enumerate some of the potential options here so we aren't
lost or confusing each other in paragraphs (or otherwise letting this go
on for too long):

 a) Some hybrid where we have the code remain on salsa yet mirror it on
    Github. Somewhat like the situation ~12 months ago.

 b) Another frankenstein hybrid where we have the code remain on salsa
    & mirror on Github, but move issue tracking to salsa.

 c) Make salsa the canonical location, enable issues on it and use it
    for MRs. "Forward" issues upstream to salsa from the BTS.

 d) Make GitHub the canonical location and use it for PRs and issues.
    Remove diffoscope entirely from salsa & "forward" issues to GitHub
    from the BTS.

 e) Make GitLab the canonical location for both code and use it for MRs
    and issues. Remove diffoscope entirely from salsa and forward
    "issues" here from the BTS.

I'm not *really* that fussed philosophically but as someone who has
done a lot of the diffoscope coding over the past years I just want to
remove as much day-to-day infrastructure overhead with respect to
collating, collapsing, merging issues and suchforth.

It is very easy to overloop what a big mental barrier and annoyance it
is to have to do this extra work.

(... not to mention how OCD-triggering it is to have duplicates, etc.)

Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

[Message part 1 (text/plain, inline)]
Hi Chris,

On Mon, Oct 08, 2018 at 08:15:59PM +0100, Chris Lamb wrote:
> > But I think we want to move something distro agnostic, and salsa.d.o
> > is very much Debian centric, so I think we should look for something
> > else. I'd be fine to using github.com or gitlab.com or foobar.
> Let's try and enumerate some of the potential options here so we aren't
> lost or confusing each other in paragraphs (or otherwise letting this go
> on for too long):

thanks, this seems useful! :)

before answering, some questions about these scenarios:

>  a) Some hybrid where we have the code remain on salsa yet mirror it on
>     Github. Somewhat like the situation ~12 months ago.

where would we track the upstream issues in a.)?

>  b) Another frankenstein hybrid where we have the code remain on salsa
>     & mirror on Github, but move issue tracking to salsa.
> 
>  c) Make salsa the canonical location, enable issues on it and use it
>     for MRs. "Forward" issues upstream to salsa from the BTS.
> 
>  d) Make GitHub the canonical location and use it for PRs and issues.
>     Remove diffoscope entirely from salsa & "forward" issues to GitHub
>     from the BTS.
> 
>  e) Make GitLab the canonical location for both code and use it for MRs
>     and issues. Remove diffoscope entirely from salsa and forward
>     "issues" here from the BTS.

you mean a gitlab.com instance in e.)?

> I'm not *really* that fussed philosophically but as someone who has
> done a lot of the diffoscope coding over the past years I just want to
> remove as much day-to-day infrastructure overhead with respect to
> collating, collapsing, merging issues and suchforth.

nods, same here. plus I want it easy for new non-Debian contributors.
(Wish I'm sure you want too.)

> It is very easy to overloop what a big mental barrier and annoyance it
> is to have to do this extra work.

understood but what extra work exactly? of course we should automate
mirroring...

-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]
Dear Holger,

> before answering, some questions about these scenarios:

To be clear, these aren't the full enumeration of possible scenarios
nor a request that we choose one or vote, simply a way of trying to
short-cut exchanging paragraphs of text and confusing each other.

> >  a) Some hybrid where we have the code remain on salsa yet mirror it on
> >     Github. Somewhat like the situation ~12 months ago.
> 
> where would we track the upstream issues in a.)?

(I guess the BTS to differentiate it from 'b'? *shrug*)

> >  e) Make GitLab the canonical location for both code and use it for MRs
> >     and issues. Remove diffoscope entirely from salsa and forward
> >     "issues" here from the BTS.
> 
> you mean a gitlab.com instance in e.)?

I was immediately thinking of using the existing gitlab.org instance
but feel free to split if you feel like it. (The idea of maintaining our
own Gitlab instance does not sound like a particularly good use of our
time.)

> > It is very easy to overloop what a big mental barrier and annoyance it
> > is to have to do this extra work.
> 
> understood but what extra work exactly? of course we should automate
> mirroring...

The extra work I am refering to is, from experience, the extra cognitive
and remarkably-stressful load when you have 3+ avenues for people to file
issues, bugs and PRs, etc.  (Mirroring was automated before.)

Best wishes,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

On Mon, Oct 8, 2018 at 9:18 PM Chris Lamb <lamby@debian.org> wrote:
>  c) Make salsa the canonical location, enable issues on it and use it
>     for MRs. "Forward" issues upstream to salsa from the BTS.
>
>  d) Make GitHub the canonical location and use it for PRs and issues.
>     Remove diffoscope entirely from salsa & "forward" issues to GitHub
>     from the BTS.
>
>  e) Make GitLab the canonical location for both code and use it for MRs
>     and issues. Remove diffoscope entirely from salsa and forward
>     "issues" here from the BTS.

As a not-really-Debian would-be contributor (though admittedly I do have
some Debian background), these all seem like fine options to me, not much
preference between them. While salsa is Debian-centric, it seems easy
enough to create a guest account, so that wouldn't bother me.

I can see how having duplication between the BTS and the 'upstream'
tracker could be cumbersome, though - but perhaps there are tools
to make forwarding/tracking less painful? Seems like something that
would benefit many projects.

Arnout

[Message part 1 (text/plain, inline)]
On Tue, Oct 09, 2018 at 11:22:28AM +0100, Chris Lamb wrote:
> > before answering, some questions about these scenarios:
> To be clear, these aren't the full enumeration of possible scenarios
> nor a request that we choose one or vote, simply a way of trying to
> short-cut exchanging paragraphs of text and confusing each other.

sure

> > >  a) Some hybrid where we have the code remain on salsa yet mirror it on
> > >     Github. Somewhat like the situation ~12 months ago.
> > 
> > where would we track the upstream issues in a.)?
> (I guess the BTS to differentiate it from 'b'? *shrug*)

right

> > e.)
> I was immediately thinking of using the existing gitlab.org instance
> but feel free to split if you feel like it. (The idea of maintaining our
> own Gitlab instance does not sound like a particularly good use of our
> time.)

no, no, I absolutly dont want us to run gitlab...

(gitlab.org these days btw redirects to gitlab.com... :)

> The extra work I am refering to is, from experience, the extra cognitive
> and remarkably-stressful load when you have 3+ avenues for people to file
> issues, bugs and PRs, etc.  (Mirroring was automated before.)

I'm not sure I understand. First, its 2 avenues, not 3+. And then we
will either fix upstream issues submitted to the Debian BTS immediatly
or immediatly forward those issues to our upstream tracker, which will
be the canonical location for (upstream bugs).

Speaking of stressful, I rather find it stressful to see all those
comment notifications on irc *and* via mail, kind of similar how I find
it stressful to be cc:ed when I'm subscribed anyway.  But then I also
know that some people find those useful (to receive) or easy (to send
("my mailprogramm does those cc:s automatically")) so I try to live with
them.

In a (somewhat) similar way I think we should make it very easy to
submit bugs and I believe the easiest way for most people today is
github.com.

But maybe I'm wrong and Arnout is right when he says that creating a
salsa account is easy too.

Finally, maybe this is something we should revisit in Paris, when there are
many non-Debian contributors around?

-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]
Holger wrote:

> > The extra work I am refering to is, from experience, the extra cognitive
> > and remarkably-stressful load when you have 3+ avenues for people to file
> > issues, bugs and PRs, etc.  (Mirroring was automated before.)
> 
> I'm not sure I understand. First, its 2 avenues, not 3+.

Didn't some of the previously-enumerated combinations had 3+ routes to
filing such things? Even if not, more than one is sub-optimal at the
very least.

It is a shame you don't see the overhead as being meaningful enough to
remark upon. Perhaps it's "another lamby thing" but — not to put too
much stress on this angle — not appreciating and considering the
prefered workflows of the folks doing the maintenance itself seems a
little… short-sighted at best.

Very happy to discuss in Paris.

> Speaking of stressful, I rather find it stressful to see all those
> comment notifications on irc *and* via mail, kind of similar how I [..]

(These seem like separate issues; very happy to discuss, alas away from
#910541.)

Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

[Message part 1 (text/plain, inline)]
Tryin to consider myself an active contributor to diffoscope, I'd hate
to have two different places to check for bugs.  That probably goes for
all the other project that are non debian specific though (I remember
reading about people advocating for upstream developers to check their
downstream bug trackers).

That said, I think this bug report lacks a lot from input by non-Debian
contributors.  I'm here explicitly CCing the only two that wrote in the
bug, probably not even knowing tha they are not automatically subscribed
to the bug report…

I'd like to hear what potential bug reporters would like to see, rather
than us trying to guess what they might think; therefore, I believe this
bug should (well, could) be deferred to in-person discussion in Paris.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
On Wed, Oct 10, 2018 at 03:51:49PM +0200, Mattia Rizzolo wrote:
> Tryin to consider myself an active contributor to diffoscope, I'd hate
> to have two different places to check for bugs.  That probably goes for
> all the other project that are non debian specific though (I remember
> reading about people advocating for upstream developers to check their
> downstream bug trackers).

Personally I find BTS usage "a little" cumbersome for newcomers. I think
I created under 10 bugs there and almost every time I had some troubles.
Like "why doesn't it like Package: put where I put it", or "how to set
upstream bug url". This are all trivial things if you're used to, but
lack clear guidance for others. Web based bug trackers are nice, because
they show some kind of template automatically. Either as a set of
combo boxes ("choose package", "choose version", ...), or pre-filled
template for a bug report. In this regard, the link Mattia added helps a
lot.

> That said, I think this bug report lacks a lot from input by non-Debian
> contributors.  I'm here explicitly CCing the only two that wrote in the
> bug, probably not even knowing tha they are not automatically subscribed
> to the bug report…

Oh, that's indeed the case. I was assuming I'm automatically subscribed,
because that's what every other bug tracker does (github, bugzilla,
gitlab, jira, ...). And since there is no "subscribe me" checkbox, I didn't
noticed and still don't know how to subscribe myself...

> I'd like to hear what potential bug reporters would like to see, rather
> than us trying to guess what they might think; therefore, I believe this
> bug should (well, could) be deferred to in-person discussion in Paris.

+1

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
On Wed, Oct 10, 2018 at 04:34:39PM +0200, Marek Marczykowski-Górecki wrote:
> > That said, I think this bug report lacks a lot from input by non-Debian
> > contributors.  I'm here explicitly CCing the only two that wrote in the
> > bug, probably not even knowing tha they are not automatically subscribed
> > to the bug report…
> 
> Oh, that's indeed the case. I was assuming I'm automatically subscribed,
> because that's what every other bug tracker does (github, bugzilla,
> gitlab, jira, ...). And since there is no "subscribe me" checkbox, I didn't
> noticed and still don't know how to subscribe myself...

Right, uh? ;)
There have been countless discussions on changing this behaviour, but
nothing happened.  From *our* use case this behaviour works great, since
there are several of us who mass-file bugs on the order of the
hundreds/thousands, and they really care about following the possible
ensuing discussion.

At any rate, to subscribe to a bug here you need to send an email (heh)
to nnnnn-subscribe@bugs.debian.org, so 910541-subscribe@bugs.debian.org
for this bug.  the content is ignored.  it will then send back an email
asking for confirmation, to which you need to just reply without
changing the conent/subject.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
On Wed, Oct 10, 2018 at 04:34:39PM +0200, Marek Marczykowski-Górecki wrote:
> > I'd like to hear what potential bug reporters would like to see, rather
> > than us trying to guess what they might think; therefore, I believe this
> > bug should (well, could) be deferred to in-person discussion in Paris.
> +1

I've added this to my list of things to do/discuss in Paris.

Thank you all for this discussion so far!

-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
hi,

we've discussed this at https://reproducible-builds.org/events/paris2018/
and noone present (*) had a problem using salsa for filing upstream issues
or providing merge requests, thus closing this bug report.

*) out of the 50 people present maybe 10 were regular Debian contributors...

-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
This is all fine, but issues on salsa diffoscope project are still
disabled.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[signature.asc (application/pgp-signature, inline)]
[Message part 1 (text/plain, inline)]
On Fri, Dec 14, 2018 at 05:11:30PM +0100, Marek Marczykowski-Górecki wrote:
> This is all fine, but issues on salsa diffoscope project are still
> disabled.

any objections to me enabling them? :)

-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]
Holger Levsen wrote:

> > This is all fine, but issues on salsa diffoscope project are still
> > disabled.
> 
> any objections to me enabling them? :)

Yes and no. :)

As in; I have nothing against moving to salsa (!) if we go that route,
we should just first firmly decide whether the BTS or salsa is the
canonical source of truth. This, I believe, is where we got blocked
last time on this matter.

(eg. one must surely be a strict subset of the other, rather than
having two distinct/overlapping sets of issues, where things get
lost in the cracks etc.)

As I hinted at last time as someone who is taking on the majority of
the heavy-lifting of diffoscope development these days, I humbly feel
like I should at least have some input on the processes and procedures
that I use day-to-day. :)

Best wishes,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

[Message part 1 (text/plain, inline)]
On Fri, Dec 14, 2018 at 07:05:49PM +0100, Chris Lamb wrote:
> > any objections to me enabling them? :)
> Yes and no. :)

:)

> As in; I have nothing against moving to salsa (!) if we go that route,
> we should just first firmly decide whether the BTS or salsa is the
> canonical source of truth.

I dont think there is a canonical source of truth ;)

Rather (if we go this route), salsa will be the upstream bug tracker and
the BTS will be for Debian issues. And like with all other packages in
Debian, sometimes users will report upstream issues in the BTS and we as
maintainers should (or could/can) forward them to the upstream tracker,
which will be on salsa.

(And of course we should then encourage everyone to file upstream issues
on salsa.)

> (eg. one must surely be a strict subset of the other, rather than
> having two distinct/overlapping sets of issues, where things get
> lost in the cracks etc.)

sure.

> As I hinted at last time as someone who is taking on the majority of
> the heavy-lifting of diffoscope development these days, I humbly feel
> like I should at least have some input on the processes and procedures
> that I use day-to-day. :)

I hope the above addresses your concerns. Does it?

-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]
Holger Levsen wrote:

> Rather (if we go this route), salsa will be the upstream bug tracker and
> the BTS will be for Debian issues. And like with all other packages in
> Debian, sometimes users will report upstream issues in the BTS and we as
> maintainers should (or could/can) forward them to the upstream tracker,
> which will be on salsa.

My reading of this is that (ignoring Debian-specific issues as they
are an "easy" case IMHO) salsa becomes the single source of truth; ie.
we both encourage and at least aim to forward/refile all "upstream"
bugs to Salsa.

I'm totally cool with that, I only insist on it not being undefined or
ambiguous.

Best wishes,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

[Message part 1 (text/plain, inline)]
On Fri, Dec 14, 2018 at 07:19:46PM +0100, Chris Lamb wrote:
> My reading of this is that (ignoring Debian-specific issues as they
> are an "easy" case IMHO) salsa becomes the single source of truth; ie.
> we both encourage and at least aim to forward/refile all "upstream"
> bugs to Salsa.

absolutly.

> I'm totally cool with that, I only insist on it not being undefined or
> ambiguous.

great!

I just wanted to enable issues on diffoscope.git on salsa, but couldnt
find the setting... so: could someone else please do that? :)

Once this has been done, we also need to update CONTRIBUTING.rst to
reflect this new reality. (I'm happy to do so, but don't want to do it
before the feature is enabled...)

-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]

Debian Bug report logs - #910541 diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors

Debian Bug report logs - #910541
diffoscope: filing bugs on diffoscope is cumbersome for non-Debian contributors