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

[Alec Warner]

On Thu, Sep 3, 2015 at 4:28 AM, Kent Fredric  wrote:

> On 3 September 2015 at 07:17, Paweł Hajdan, Jr. 
> 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.
>

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

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

[Paweł Hajdan , Jr .]

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ł



signature.asc
Description: OpenPGP digital signature

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.

> 

We have nearly the same tirade. :|

Andrew

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



-- 
Kent

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

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

[Paweł Hajdan , Jr .]

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




signature.asc
Description: OpenPGP digital 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.dun...@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

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