[gentoo-dev] Better way to direct upstream bugs upstream?

[gentoo-dev] Better way to direct upstream bugs upstream?

[Matt Turner]

In April I closed out ~100 bugs assigned to x11@ that the X11 team
never had any realistic ability to fix ourselves (see most bugs about
x11-drivers/ati-drivers). Most of these were fleeting driver bugs
affecting a particular piece of hardware and a (often now old)
particular version of the driver -- now long obsolete but still
cluttering our bugzilla and making triaging actually solvable bugs
more difficult.

We often direct reporters to file bugs upstream (being a middle-man
for a driver bug is extremely inefficient), but even when that happens
the Gentoo bug remains open, often long after the upstream bug is
fixed and closed.

Worse, users sometimes file bugs in our bugzilla that we don't have
time to respond to for a while during which time they're waiting on
people without the ability to help them.

Is there a better way of directing reporters to file bugs upstream? Of
course it's not always clear whether a bug is an ebuild bug or
something easily patched in Gentoo vs a driver bug that requires an
upstream developer...

Maybe some text on https://bugs.gentoo.org/enter_bug.cgi asking users
to direct bug reports upstream under some to-be-decided-upon
circumstances?

Re: [gentoo-dev] Better way to direct upstream bugs upstream?

[Kent Fredric]

On 30 August 2015 at 07:53, Matt Turner <mattst88@gentoo.org> wrote:
>
> Is there a better way of directing reporters to file bugs upstream? Of
> course it's not always clear whether a bug is an ebuild bug or
> something easily patched in Gentoo vs a driver bug that requires an
> upstream developer...


I've always seen it as a case where Gentoo devs stand as a layer of
sanitization between downstream and upstream.

Wherein reporting things upstream is good, but having a downstream
tracker for it is also good, so that when the bug is resolved
upstream,
that the consequences of it are known to be propagated downstream.

And if upstream refuses to fix a bug, Gentoo devs have to choose how
to handle that problem for downstream, sometimes patching around it,
or if that is not simple, or not possible,
to provide blockers where necessary, or produce end-user-visible
warnings about problematic behaviour, etc.

So, even in the case users are prompted to file bugs upstream first,
they should also at minimum report to gentoo when the bug is resolved
upstream
so that the fix can be replicated.

Its also not always abundantly clear to end users where upstream is,
and there are potholes in that process. For instance, in Perl space,
the "Current upstream reporting que" is often RT, but it can be
github, and knowing exactly where the reporting queue *currently* is
something that can't be reliably replicated in metadata.xml, because
it can change on a whim, and sometimes the metadata visible on the
CPAN sources is also wrong, and requires an experienced developer to
chase its tail to work out where it currently is.

And there are some upstreams on CPAN where there is no documented or
stated bug reporting mechanism, and in such cases, the metadata will
encourage you to use the defacto standard, RT, and doing so for some
upstreams will get you automated mails that will possibly make the
reporter recoil in a corner for a bit.

I know and have had moderate success in dealing with upstreams like
that, because I've worked out from listening to people talk how/where
to actaully talk about problems and try to work out how to say things
in a way that will work.

( That is, I'm a much better reporter at reporting faults found in
gentoo to some upstreams than any user could hope to be )

There are also cases where users reporting direct to upstream just
irritates upstream, because its a breakage/potential breakage due to
something gentoo does, and you have the whole hostile "not our
problem, you're on gentoo, you get to keep the pieces" response.

For these reasons, I think its best that those with the most knowledge
of how upstream works, ( us, the developers ) handle reports from end
users and ferry them upstream.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Better way to direct upstream bugs upstream?

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/30/2015 12:03 AM, Kent Fredric wrote:
> On 30 August 2015 at 07:53, Matt Turner <mattst88@gentoo.org>
> wrote:
>> 
>> Is there a better way of directing reporters to file bugs
>> upstream? Of course it's not always clear whether a bug is an
>> ebuild bug or something easily patched in Gentoo vs a driver bug
>> that requires an upstream developer...
> 
> 
> I've always seen it as a case where Gentoo devs stand as a layer
> of sanitization between downstream and upstream.
> 
> Wherein reporting things upstream is good, but having a downstream 
> tracker for it is also good, so that when the bug is resolved 
> upstream, that the consequences of it are known to be propagated
> downstream.
> 
> And if upstream refuses to fix a bug, Gentoo devs have to choose
> how to handle that problem for downstream, sometimes patching
> around it, or if that is not simple, or not possible, to provide
> blockers where necessary, or produce end-user-visible warnings
> about problematic behaviour, etc.
> 
> So, even in the case users are prompted to file bugs upstream
> first, they should also at minimum report to gentoo when the bug is
> resolved upstream so that the fix can be replicated.
> 
> Its also not always abundantly clear to end users where upstream
> is, and there are potholes in that process. For instance, in Perl
> space, the "Current upstream reporting que" is often RT, but it can
> be github, and knowing exactly where the reporting queue
> *currently* is something that can't be reliably replicated in
> metadata.xml, because it can change on a whim, and sometimes the
> metadata visible on the CPAN sources is also wrong, and requires an
> experienced developer to chase its tail to work out where it
> currently is.
> 
> And there are some upstreams on CPAN where there is no documented
> or stated bug reporting mechanism, and in such cases, the metadata
> will encourage you to use the defacto standard, RT, and doing so
> for some upstreams will get you automated mails that will possibly
> make the reporter recoil in a corner for a bit.
> 
> I know and have had moderate success in dealing with upstreams
> like that, because I've worked out from listening to people talk
> how/where to actaully talk about problems and try to work out how
> to say things in a way that will work.
> 
> ( That is, I'm a much better reporter at reporting faults found in 
> gentoo to some upstreams than any user could hope to be )
> 
> There are also cases where users reporting direct to upstream just 
> irritates upstream, because its a breakage/potential breakage due
> to something gentoo does, and you have the whole hostile "not our 
> problem, you're on gentoo, you get to keep the pieces" response.
> 
> For these reasons, I think its best that those with the most
> knowledge of how upstream works, ( us, the developers ) handle
> reports from end users and ferry them upstream.
> 

Quick question: what is RT?

Regarding that, I've noticed that multiple upstreams (apparently urxvt
being one) have an issue with Gentoo and how 'problematic' we are as a
distribution because we offer so much choice to users. I'm not sure I
understand that attitude since makes upstreams look like they don't
care about the configurability of their own software.

If Perl packages and CPAN have similar issues, how do you guys handle
it in perl-space? I think if I was dealing with a difficult upstream,
I'd try to figure out what I could do to help their build scripts
improve. If they were unresponsive to criticism or offers for
improvement, I would reroute bugs their way.

Historically, what is our approach to stubborn upstreams that think
Gentoo is the problem instead of their build scripts or packaging
preferences? Do we have a policy regarding difficult upstreams?

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV4q6kAAoJEAEkDpRQOeFwin4QAMKIC2WwOlfdsZ1U9WKnmgP1
Aussqt36Fcw4HR50lJ4rqxmkax2QIbF7msDjR/keoW9ZQ/IjcCObXy5XATthw2lJ
g2nNS3TLKRtpQxA4baZsZqlLUpPOTNOKm7KArA9e1PCfELdViVD9aSlYWGfmz0Ns
efcXJUjN22uHgx2Awqpj9+jg1o/wgonnryYwMAHxvzfFeIdVd9zV4Af8IyXz7Qh9
tp1/UfMLYE/40sne7NVd/2sZpJHFD0WW8ViPEYkJFtYySwR3KRwNfu/S/7iLhiKB
pG5Mqneq0taN4EWXYX7wSG6w5dr5EWMiN5ftPI/mXDSfElTZY7H6U4KjXMi5eNU2
Wm8HjfrGtTm8pOJhd1EZ9otBSCWVGySTEeTGFEUEQokMor62Ff9/jVCB20hw6Hrf
oP79U+VyZlLcejW9kCEP+dUdnjLgO81uxLbcp3r35A05lwgUPnLltT+9/nFwY6ut
VgEWxUNHrIsr6eUTZQ53OeB/VDxf3yyJcIg1ysdN9jGVHM/W5/DuDCe+/sttOMD1
7C/wGLVfltZEVets2EAr+ks76sTG8/Miurr79J/f07Z8TU1qKhjyCri2+7cuIuOZ
B51HQ1NdI9TNEa68/c7MKtKwYLfwQTcEndQgRnRL8ZDLGPMZIJuKDKUb5OHsWilC
Xc53D+mRG+YGy+rcL73E
=QWFf
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Better way to direct upstream bugs upstream?

[Kent Fredric]

On 30 August 2015 at 19:20, Daniel Campbell <zlg@gentoo.org> wrote:
> Quick question: what is RT?
>

RT is rt.cpan.org, for which every cpan distribution that gets
published gets a free bug tracker there
where permissions assigned to that bug tracker reflect permissions
granted under the CPAN authority scheme.

- Every new distribution gets an RT queue whether you want it or not
- If you don't stipulate "bug tracker" metadata in your distribution,
then all the CPAN user interfaces will guide users to said RT queues
- RT queues are sometimes also assumed to be "The place" to send bugs,
even in spite of published metadata
- RT queues can't be turned off or disabled
- RT queues also don't require a sign up to use, and you can file bugs
simply by sending an email to the right email address
- And all new bugs/new feedback to RT queues sends email to the
associated CPAN authors email address.

> Regarding that, I've noticed that multiple upstreams (apparently urxvt
> being one) have an issue with Gentoo and how 'problematic' we are as a
> distribution because we offer so much choice to users. I'm not sure I
> understand that attitude since makes upstreams look like they don't
> care about the configurability of their own software.

Sometimes its a social problem, not a technical one. Sometimes its
both. Sometimes its a problem of effort. Other times its a problem
where upstream literally can't fix our problems because they can't
replicate them, and they can't replicate them because its something
we're doing that causes it, and so they define that invisible
intangible thing as a deviation from standard, and that it must be
broken.

Obviously if somebody encounters many problems of that nature,
learning that a distribution seems "broken by default" and they don't
want to operate with it unless the problem can be clear and
demonstrated and well defined in an isolated context.

> If Perl packages and CPAN have similar issues, how do you guys handle
> it in perl-space? I think if I was dealing with a difficult upstream,
> I'd try to figure out what I could do to help their build scripts
> improve. If they were unresponsive to criticism or offers for
> improvement, I would reroute bugs their way.

Its very hard because CPAN is very anarchic, every distribution is its
own source of irrefutable authority like  a little government, where
change in authority is something that can only happen either
willingly, or by evidence that the author of a distribution has been
long absent entirely. Simple stubbornness and refusal to co-operate
are not enough, and if an author is present but negligent, we
literally have to wash our hands of the problem and route around the
damage.

So "how we deal with a continued problem" is essentially:

- Fork the problem
- Fix the fork
- Encourage people to use the fork.

Which is essentially a direct-representation-democratization of
changing the defaults.

>
> Historically, what is our approach to stubborn upstreams that think
> Gentoo is the problem instead of their build scripts or packaging
> preferences? Do we have a policy regarding difficult upstreams?

Maybe here we can take the example of udev/systemd. Upstream headed in
a direction that was at odds with the gentoo way, and their
stubbornness dictated that "this is how its going to be", and we were
expected to just follow suit.

There's no way we can simply go "I can't use my computer any more
because I don't want systemd" and respond with simply "tell upstream,
not our problem".

We've had to accept that upstream were being unreasonable, and fork
the problem and manage it ourselves.

And now we have eudev.

This is a very good example of "Gentoo standing in between upstream
and our users to protect our users from upstream".

That's our job. To keep upstream accountable, and shield users from
their mistakes.

That's why we have all these security systems(GLSAs and related
downstream security patching) and QA checks on upstream packages.

This is also why we have install/build happen in sandbox, because we
assume the default of "Upstream can't be trusted to be sane".

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Better way to direct upstream bugs upstream?

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/30/2015 12:54 AM, Kent Fredric wrote:
> On 30 August 2015 at 19:20, Daniel Campbell <zlg@gentoo.org>
> wrote:
>> Quick question: what is RT?
>> 
> 
> RT is rt.cpan.org, for which every cpan distribution that gets 
> published gets a free bug tracker there where permissions assigned
> to that bug tracker reflect permissions granted under the CPAN
> authority scheme.
> 
> - Every new distribution gets an RT queue whether you want it or
> not - If you don't stipulate "bug tracker" metadata in your
> distribution, then all the CPAN user interfaces will guide users to
> said RT queues - RT queues are sometimes also assumed to be "The
> place" to send bugs, even in spite of published metadata - RT
> queues can't be turned off or disabled - RT queues also don't
> require a sign up to use, and you can file bugs simply by sending
> an email to the right email address - And all new bugs/new feedback
> to RT queues sends email to the associated CPAN authors email
> address.
> 
>> Regarding that, I've noticed that multiple upstreams (apparently
>> urxvt being one) have an issue with Gentoo and how 'problematic'
>> we are as a distribution because we offer so much choice to
>> users. I'm not sure I understand that attitude since makes
>> upstreams look like they don't care about the configurability of
>> their own software.
> 
> Sometimes its a social problem, not a technical one. Sometimes its 
> both. Sometimes its a problem of effort. Other times its a problem 
> where upstream literally can't fix our problems because they can't 
> replicate them, and they can't replicate them because its
> something we're doing that causes it, and so they define that
> invisible intangible thing as a deviation from standard, and that
> it must be broken.
> 
> Obviously if somebody encounters many problems of that nature, 
> learning that a distribution seems "broken by default" and they
> don't want to operate with it unless the problem can be clear and 
> demonstrated and well defined in an isolated context.
> 
>> If Perl packages and CPAN have similar issues, how do you guys
>> handle it in perl-space? I think if I was dealing with a
>> difficult upstream, I'd try to figure out what I could do to help
>> their build scripts improve. If they were unresponsive to
>> criticism or offers for improvement, I would reroute bugs their
>> way.
> 
> Its very hard because CPAN is very anarchic, every distribution is
> its own source of irrefutable authority like  a little government,
> where change in authority is something that can only happen either 
> willingly, or by evidence that the author of a distribution has
> been long absent entirely. Simple stubbornness and refusal to
> co-operate are not enough, and if an author is present but
> negligent, we literally have to wash our hands of the problem and
> route around the damage.
> 
> So "how we deal with a continued problem" is essentially:
> 
> - Fork the problem - Fix the fork - Encourage people to use the
> fork.
> 
> Which is essentially a direct-representation-democratization of 
> changing the defaults.
> 
>> 
>> Historically, what is our approach to stubborn upstreams that
>> think Gentoo is the problem instead of their build scripts or
>> packaging preferences? Do we have a policy regarding difficult
>> upstreams?
> 
> Maybe here we can take the example of udev/systemd. Upstream headed
> in a direction that was at odds with the gentoo way, and their 
> stubbornness dictated that "this is how its going to be", and we
> were expected to just follow suit.
> 
> There's no way we can simply go "I can't use my computer any more 
> because I don't want systemd" and respond with simply "tell
> upstream, not our problem".
> 
> We've had to accept that upstream were being unreasonable, and
> fork the problem and manage it ourselves.
> 
> And now we have eudev.
> 
> This is a very good example of "Gentoo standing in between
> upstream and our users to protect our users from upstream".
> 
> That's our job. To keep upstream accountable, and shield users
> from their mistakes.
> 
> That's why we have all these security systems(GLSAs and related 
> downstream security patching) and QA checks on upstream packages.
> 
> This is also why we have install/build happen in sandbox, because
> we assume the default of "Upstream can't be trusted to be sane".
> 
Thanks for that write-up. Simple to understand and (imo anyway) really
represents one of the reasons I became a developer. I like the idea of
protecting our users' choices and creating a system that's sane,
despite (or in spite :P) of our upstreams.

- -- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV4rfVAAoJEAEkDpRQOeFw4TsQANecNmZCKnSi19nifRxzTGak
o74AjlPUvaKFJu3nO8bABPo1FrkSwa0lta+hSY5CB223XRjT3PXu8kAi3lgUOVQz
jK89Fs1yIXULDV5pA2/26UDcGLtfzENfpdd5P8qNgLNb9ky+RB30IbJzzG5DxLbD
qG/nQ7CkozRp2Nbkr1U7u1gbbf/jW0L4CXE0dI2tZIDB0VIXLspNjYrj0nXA9hAj
9OGa6nnxIZCE9nrirnAk4rFxT0NwJWbeCEiqbeRR6A+YyekTvVlzQGZSvxHs6hBu
jXhoZOwGqIu2jV/ezjEZ8OlEnAbGzMscQjr7PxSMchJG4O8uo8R/E0+HRveSjFwd
BR/mgAgmD+YRw8FetWN5fTiecuXbLSZvvQRAyLjrR4ZQJTtrtWJcBTZfWhHQAItX
N+Rq0EHpD4RXGE3h5GqP6sZ0TLOgA5/2CBGTkng2F6pc+8mC0gWXse9asJjdm72V
XF9LYpLxaixzEhioDSwMok43Nj6F/3GA4LuuqKsQSqS9pSe5KuLA135NtfKAu4Cy
8OWcYLsB7OHycDhZZLJwkQA3JaV+LjHD219BZcsssJBkGXZKx9OuftFst6/9JB93
wdBIt4PqIOA8mrGRbvZTC3qkQ3d3JdRHYq3ceSig+hwKga04g1ny6qBuWrFdspZp
UVeuwYM1F7bkxBUSkuAD
=PF3g
-----END PGP SIGNATURE-----

[gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Duncan]

Kent Fredric posted on Sun, 30 Aug 2015 19:03:37 +1200 as excerpted:

> I've always seen it as a case where Gentoo devs stand as a layer of
> sanitization between downstream and upstream.
> 
> Wherein reporting things upstream is good, but having a downstream
> tracker for it is also good, so that when the bug is resolved upstream,
> that the consequences of it are known to be propagated downstream.
> 
> And if upstream refuses to fix a bug, Gentoo devs have to choose how to
> handle that problem for downstream, sometimes patching around it, or if
> that is not simple, or not possible,
> to provide blockers where necessary, or produce end-user-visible
> warnings about problematic behaviour, etc.
> 
> So, even in the case users are prompted to file bugs upstream first,
> they should also at minimum report to gentoo when the bug is resolved
> upstream so that the fix can be replicated.

In addition to the other services a distro provides, a big one is having 
one single place to file bugs, instead of a couple hundred different bug 
tracker accounts on a half-dozen tracker software bases, and that's not 
even counting the ones (like the perl trackers that Kent mentions) that 
are virtually impossible for a user to find at all.

This is a big deal that I think some gentoo package maintainers forget 
about sometimes.  The maintainer should be familiar with package upstream 
and know where to file bugs, as well as probably already having a bug 
reporter account.  Users are unlikely to, because as I said, it'd end up 
being a couple hundred accounts scattered all over the place.  But users 
probably already do have a gentoo bug account, and if they don't, setting 
it up once to use for all those hundreds of packages instead of a couple 
hundred times... makes a difference.  As a result, a user told to file a 
bug upstream may well simply blow it off and wait out the bug, which 
someone else will likely eventually report, but look at all the time that 
is needlessly going by on a bug that could actually be in the process of 
being fixed, in the mean time.


Both for that reason and because I often /don't/ know whether it's a 
gentoo bug or not, I default to filing with gentoo.  However, where the 
details are specific enough that I know it's an upstream bug, 
particularly if it's urgent, I'll often go to the trouble of filing 
upstream as well, then referencing each bug in the other filing.  When I 
do so, whichever one gives me a patch to test or whatever, first, I try 
to update the other one, both with the mention of the patch and the 
results of my test with it.  Among other reasons, I never know when other 
gentooers are going to be running into the problem, and if/when I know of 
a patch available, I want it on the bug, so they too can drop it in /etc/
portage/patches/ and get a fix, often before the maintainer gets around 
to patching the gentoo package.  I know I've found enough fixes already 
available on bugs filed by others, and am simply paying it forward. =:^)

FWIW the two most recent bugs I've handled this way were systemd bugs, 
one a networkd bug on IPv4-only setups, the other a tmpfiles.d bug that 
only affected users on btrfs, both related to changes originally found in 
218, IIRC, with the fixes making 220.  Awhile before that was a rather 
nasty gmime related bug, in 2.6.16, IIRC, "nasty" because people with the 
affected version were posting messages that broke the RFCs, thus 
affecting many others attempting to read those messages.  The details on 
all three bugs were specific enough that once upstream took a look, the 
bug was easily reproduceable and thus reasonably quickly fixed.

Of course other bugs I report upstream because I'm already involved with 
upstream, or want to be by the time I find and file a bug.  I've never 
used gentoo kernel packages, for instance, having learned to build my own 
back on mandrake, and simply adjusted as necessary when I switched to 
gentoo.  All my kernel bug reports have thus been upstream, during the rc 
cycle before upstream release, with all but one fixed before release and 
that one fixed in another kernel cycle. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Kent Fredric]

On 30 August 2015 at 21:37, Duncan <1i5t5.duncan@cox.net> wrote:
> In addition to the other services a distro provides, a big one is having
> one single place to file bugs, instead of a couple hundred different bug
> tracker accounts on a half-dozen tracker software bases, and that's not
> even counting the ones (like the perl trackers that Kent mentions) that
> are virtually impossible for a user to find at all.

And there are cases where there *is* no contactable upstream. This is
disturbingly frequent in proprietary software, like games, where your
only report channels are other people who don't know waxing lyrical on
what they think the problem is on support forums, which is no better a
bug tracker in practice than "Have you tried googling?"

Or upstream might be a monolithic giant like Google where their
upstream bug tracking is some pointless forum where you get ignored by
the people actually working on things.

I really love it, and take pride in the fact that OpenSource Linux
vendors provide better technical support to their users, and at no
cost, than proprietary products can deliver at a fee.



-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Better way to direct upstream bugs upstream?

[Peter Stuge]

<upstream hat on>

Kent Fredric wrote:
> I've always seen it as a case where Gentoo devs stand as a layer of
> sanitization between downstream and upstream.

This is the last thing I want. Did you play the whisper game as a kid?

I want direct contact with the user who can reproduce the problem in
the upstream bug tracker, anything else is absolutely suboptimal and
will easily cause the bug to never get fixed at all.


> Wherein reporting things upstream is good, but having a downstream
> tracker for it is also good, so that when the bug is resolved
> upstream,
> that the consequences of it are known to be propagated downstream.

I think a clever downstream would make sure to integrate with the
upstream, by e.g. subscribing to all ticket resolution changes.


> So, even in the case users are prompted to file bugs upstream first,
> they should also at minimum report to gentoo when the bug is resolved
> upstream so that the fix can be replicated.

I think this duplication is utterly dysfunctional, as long as
upstream does not refuse to fix the bug.


> Its also not always abundantly clear to end users where upstream is,
> and there are potholes in that process.

Sure. This is an area where maintainers probably already know
everything, and where they can help users by documenting it.
(I use HOMEPAGE a lot. Would BUGTRACKER make sense?)


> knowing exactly where the reporting queue *currently* is something
> that can't be reliably replicated in metadata.xml, because it can
> change on a whim

In theory it can, but my experience is that in practice it doesn't
change very often.


> sometimes the metadata visible on the CPAN sources is also wrong,
> and requires an experienced developer to chase its tail to work out
> where it currently is.

Sounds like a task that the ebuild maintainer can solve?


> ( That is, I'm a much better reporter at reporting faults found in
> gentoo to some upstreams than any user could hope to be )

Cool! And thank you for doing that! But it's not always neccessary,
and it shouldn't be required when it isn't.


> There are also cases where users reporting direct to upstream just
> irritates upstream, because its a breakage/potential breakage due to
> something gentoo does, and you have the whole hostile "not our
> problem, you're on gentoo, you get to keep the pieces" response.
> 
> For these reasons, I think its best that those with the most knowledge
> of how upstream works, ( us, the developers ) handle reports from end
> users and ferry them upstream.

Do not use this as a blanket policy. It is unhelpful for upstreams
who understand Gentoo and appreciate that users are building from
source.

Maybe they are the exception, but don't punish the minority of good
guys just because most are bad.


Thanks

//Peter

Re: [gentoo-dev] Better way to direct upstream bugs upstream?

[Kent Fredric]

On 31 August 2015 at 00:15, Peter Stuge <peter@stuge.se> wrote:
> In theory it can, but my experience is that in practice it doesn't
> change very often.
>
>
>> sometimes the metadata visible on the CPAN sources is also wrong,
>> and requires an experienced developer to chase its tail to work out
>> where it currently is.
>
> Sounds like a task that the ebuild maintainer can solve?


It can be done, just there are annoying edge cases where it doesn't
work and any metadata will be wrong.

- There are upstreams where there is no real contact address
- There are upstreams where using automatically discernable defaults
will get you a default that will get anyone who uses that contact
address "Yelled at".
- There are upstreams where the documented bug tracker in the
discoverable metadata is wrong, and will require a new release to fix.
- There are upstreams whos bug tracker I would *never* refer a user
to, for instance, bug trackers on sourceforge are enough to make me go
"Is there somewhere else I can throw my reports?" ( My ad blockers now
block that whole domain due to its track record of being a safe haven
to malware and deceptive advertising )

And the problem with the "Not a reliable data" is that you can't
discover it until its a problem.

Which means it won't be known its a problem until a user attempts to use it.

Which means we're telling users to resolve a bug in resolving bug
trackers before they can resolve a bug.

My favourite class of these at present are the ones who were foolish
enough to use Google Code for bug tracking, as the metadata for many
projects *still* says its viable, and you follow the link and get a
403, and some of these don't *actually* have a decided upon
alternative yet. I've just been tracking down the authors and doing it
manually, or digging into the data to find their source control is
mirrored on github and there's a defacto collection of people who have
started filing bugs there instead, but its not authoritative yet.

Yes, cases like these are exceptions, but they're exceptions that
cause serious user confusion every time they happen.

For a namespace like dev-perl/ and perl-core/, we could automate
provisioning "an upstream" bug tracker for 90% of cases. But the
remaining 10% that was provisioned from metadata would be wrong, and a
sentience of some kind would be required to work out which 5% was
wrong, and *not* to rely on the automated provisioning.

And there are some authors on CPAN who I would institute a custom
black hole stipulating that they should *only* contact gentoo about
bugs and *never* upstream, because upstream have a marked track record
of setting people who report their bugs on fire *due* to them being
gentoo users.

Its cool that there are lots of upstream who are capable and willing
to deal with gentoo users directly. But the odds of a gentoo user
assuming any upstream able /willing to be responsive and them getting
unhelpful responses and the Gentoo user not realising they needed
flame retardant clothing, makes me want to suggest a system wherein
direct upstream contact by Gentoo users should be something decided
upon based on the gentoo users technical competence.

If for example, a Gentoo user is able to function at the level
expected of a Gentoo developer, and are able to dig into the problem
sufficient to isolate and comprehend the problem in a systems agnostic
way, or at least express how and why Gentoo changes the behaviour of a
system, then by all means, going straight to upstream should be fine,
and they can ask for a revision bump once the problem is fixed, and if
they're feeling generous, put a copy of their issue on bgo with
possible solutions, because that is where gentoo users look first.

But we shouldn't expect this level of performance from all users, and
we should be capable and willing to try helping the less capable with
reporting their issues to upstream.

Some of this is just basic due dilligence, making sure the user has
even reported the right information.

If a user isn't able to provide information to gentoo sufficient that
gentoo can even identify that a bug is in fact happening, they're just
going to be irritating upstream, because upstream won't be able to
easily plumb the gentoo specifics to make sure they haven't just done
something dumb that gentoo has already put guards against that the
user has unwittingly disabled.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

[gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Chí-Thanh Christopher Nguyễn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matt Turner schrieb:
> Worse, users sometimes file bugs in our bugzilla that we don't have time
> to respond to for a while during which time they're waiting on people
> without the ability to help them.
> 
> Is there a better way of directing reporters to file bugs upstream? Of 
> course it's not always clear whether a bug is an ebuild bug or something
> easily patched in Gentoo vs a driver bug that requires an upstream
> developer...

I think such bug reports are still useful. They can point to patches once
the issue has been resolved upstream, for consideration in a new ebuild
revision.

Whether they are kept open or resolved UPSTREAM while an upstream fix is
unavailable I have no strong opinion about.


Best regards,
Chí-Thanh Christopher Nguyễn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlXjRHgACgkQ+gvH2voEPRCiLwCeNOZAIpEsXwCIsSV2ZzMwXxO4
gUkAnR+5nwYhL8ty5YR2QoISDe4y+B8Y
=U/e0
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Paweł Hajdan, Jr.]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

On 8/30/15 12:02 PM, Kent Fredric wrote:
> Or upstream might be a monolithic giant like Google where their
> upstream bug tracking is some pointless forum where you get ignored by
> the people actually working on things.

Ouch.

Do you have specific examples?

I'm not denying they exist. I just had mostly positive experience with
<https://code.google.com/p/chromium/issues> . Because I'm also Chromium
developer, I know that's what people "actually working on things" use.

I admit with 85000+ open issues not all of them are getting enough
attention. But if you know an upstream developer, it's easier to get the
right people to look at the bug.

Of course above is not the only Google project, and I don't have much
experience with the other ones.

Paweł



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Jason Zaman]

On Wed, Sep 02, 2015 at 09:17:16PM +0200, Paweł Hajdan, Jr. wrote:
> On 8/30/15 12:02 PM, Kent Fredric wrote:
> > Or upstream might be a monolithic giant like Google where their
> > upstream bug tracking is some pointless forum where you get ignored by
> > the people actually working on things.
> 
> Ouch.
> 
> Do you have specific examples?
> 
> I'm not denying they exist. I just had mostly positive experience with
> <https://code.google.com/p/chromium/issues> . Because I'm also Chromium
> developer, I know that's what people "actually working on things" use.
> 
> I admit with 85000+ open issues not all of them are getting enough
> attention. But if you know an upstream developer, it's easier to get the
> right people to look at the bug.
> 
> Of course above is not the only Google project, and I don't have much
> experience with the other ones.
> 
> Paweł

I dont know what ones he's talking about, but I have this one:

https://code.google.com/p/android/issues/detail?id=175284
https://bugs.gentoo.org/show_bug.cgi?id=533178

Android Studio is released as a compiled binary for windows/mac/linux
but there is no source code for it. And to make matters even worse they
don't have proper tags in the git repos for it so I can't even just make
the tarballs myself because I dont know which commits correspond to the
releases. They just closed the bug as declined with no reason given :(.

-- Jason

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Kent Fredric]

On 3 September 2015 at 07:17, Paweł Hajdan, Jr. <phajdan.jr@gentoo.org> wrote:
> Do you have specific examples?


None that I can currently recall, I've just long resigned myself from
trying to care with Google products. The instances I can recall were
more defects in their web services, some where there was literally no
place to go, and I just kept getting the feeling nobody cared.

eg: I found a coding defect in the Google Ads code that injected the
version string from whatever flash implementation you were using
verbatim inside an HTML Tags attributes without caring to escape it,
which meant if you had a competing implementation(eg: Gnash ) that
used a double-quote mark in its version string, Ad injection could
cause entire page layout to be broken.

Or for instance, when GMail overhauled their email service, despite
the pleas of developers to have a "Don't top-post by default" toggle
in the settings, the whole developer community was deemed unimportant
and that such a feature could never happen.

So now every time I reply to something, I have to fight with GMail to
make sure I highlight the whole message manually first, making sure
not to have my selector accidentally slip outside the email text, and
*then* hit reply, which makes it quote it instead.

The latter choice has been the one that stuck with me the most,
because I'm constantly feeling like I'm being slapped in the face by
it.

Granted these instances are not instances of "Software I run on my
machine", but they are still software to me.

</tirade>

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Andrew Udvare]

On 03/09/15 04:28, Kent Fredric wrote:
> Or for instance, when GMail overhauled their email service, despite
> the pleas of developers to have a "Don't top-post by default" toggle
> in the settings, the whole developer community was deemed unimportant
> and that such a feature could never happen.

Chromium team is no different in this regard. No options, for anything.
It is extremely annoying when they implement 'privacy-violating'
features like the previously visited sites in the New tab (before you've
entered a URL), with no option to disable despite pleas to give that option.

Developers and other habits (perhaps not seen at Google internally) are
apparently not important. Even privacy can be compromised at times. Most
certainly Google mostly cares for those outside the organisation who
'evangelise' with the Google way of doing things.

> So now every time I reply to something, I have to fight with GMail to
> make sure I highlight the whole message manually first, making sure
> not to have my selector accidentally slip outside the email text, and
> *then* hit reply, which makes it quote it instead.

This is why I moved back to a client. Right now Thunderbird.

> </tirade>

We have nearly the same tirade. :|

Andrew

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Paweł Hajdan, Jr.]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

On 9/3/15 10:16 PM, Andrew Udvare wrote:
> Chromium team is no different in this regard. No options, for anything.
> It is extremely annoying when they implement 'privacy-violating'
> features like the previously visited sites in the New tab (before you've
> entered a URL), with no option to disable despite pleas to give that option.

Do you have references to these pleas? I'd expect e.g. some public bug
reports.

Would overriding the new tab page using an extension
(https://developer.chrome.com/extensions/override) work for you?

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 2424 bytes --]

On Thu, Sep 3, 2015 at 4:28 AM, Kent Fredric <kentfredric@gmail.com> wrote:

> On 3 September 2015 at 07:17, Paweł Hajdan, Jr. <phajdan.jr@gentoo.org>
> wrote:
> > Do you have specific examples?
>
>
> None that I can currently recall, I've just long resigned myself from
> trying to care with Google products. The instances I can recall were
> more defects in their web services, some where there was literally no
> place to go, and I just kept getting the feeling nobody cared.
>

Often that can be the case. On the team I am on, we care but we have about
a billion other things to do than fix low priority bugs or implement
one-off customer features in our clients or APIs. Often I recommend (as
Pawel did later in the thread) writing and using extensions to add these
features. Obviously in the ads one, its not really possible to fix for
everyone (here install this third party extension!) but for gmail it seems
feasible to write a browser extension to highlight the text for you.


>
> eg: I found a coding defect in the Google Ads code that injected the
> version string from whatever flash implementation you were using
> verbatim inside an HTML Tags attributes without caring to escape it,
> which meant if you had a competing implementation(eg: Gnash ) that
> used a double-quote mark in its version string, Ad injection could
> cause entire page layout to be broken.
>

> Or for instance, when GMail overhauled their email service, despite
> the pleas of developers to have a "Don't top-post by default" toggle
> in the settings, the whole developer community was deemed unimportant
> and that such a feature could never happen.
>

So write an extension that doesn't do it?


>
> So now every time I reply to something, I have to fight with GMail to
> make sure I highlight the whole message manually first, making sure
> not to have my selector accidentally slip outside the email text, and
> *then* hit reply, which makes it quote it instead.
>

I'm unsure if extensions work on mobile though :(


>
> The latter choice has been the one that stuck with me the most,
> because I'm constantly feeling like I'm being slapped in the face by
> it.


> Granted these instances are not instances of "Software I run on my
> machine", but they are still software to me.
>

> </tirade>
>
> --
> Kent
>
> KENTNL - https://metacpan.org/author/KENTNL
>
>

[-- Attachment #2: Type: text/html, Size: 3818 bytes --]