Local workarounds with no reported bugs

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Local workarounds with no reported bugs

Michał Górny-5
Hello, everyone.

I'd like to point out a major problem in Gentoo: there's a fair number
of developers who add various local workarounds to problems they meet
and don't bother to report a bug. Worst than that, this applies not
only for upstream problems but also to Gentoo eclass/ebuild-related
issues.


Example: udev people had problems with MULTILIB_WRAPPED_HEADERS
in the past. Instead of contacting me (which would result in helpful
explanation how to do things properly), they abused bash to disable
the check function implicitly in the ebuilds.

Nobody bothered to inform me of the issue there. Instead, I had to
notice it looking at the udev ebuilds accidentally. Furthermore, in
most of the ebuilds the workaround was no longer necessary but nobody
bothered to check that.


Example 2: Coacher had problem with git-r3 not trying fallback URIs
when earlier URI was https and https wasn't supported in git. So he
reordered URIs to have https last. With tiny explanation in some random
commit message.

So we have a problem that affects around a half of git-r3 packages
(using quick grep, results inaccurate), however minor it is. Worse, it
affects the policy of preferring https and causes some people to reject
the policy silently. And nobody gives a damn to report it!


Therefore, I'd like to request establishing an official policy against
workarounds with no associated bug reports.

Your thoughts?

--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

attachment0 (949 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Local workarounds with no reported bugs

Kent Fredric-2
On Mon, 17 Oct 2016 09:23:09 +0200
Michał Górny <[hidden email]> wrote:

> Therefore, I'd like to request establishing an official policy against
> workarounds with no associated bug reports.
>
> Your thoughts?

Obviously I assume this is still a "to taste" thing, because when
you're packaging something, and you find something upstream have done
which makes sense for them, but not for gentoo, you're inclined to go
"oh, right", and just side-step that, without such thought as to file a
bug in the process.

So obviously not *all* workarounds can have useful bugs filed for them.

Unless I'm supposed to see the bug before I ship the code, and file a
bug in gentoo, ship the ebuild with the workaround, and then close the
bug, even though the bug never existed from any users perspective.

So its just a matter of more clearly defining the scopes of workarounds
were talking about here.


attachment0 (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Local workarounds with no reported bugs

Raymond Jennings
In reply to this post by Michał Górny-5
On Mon, Oct 17, 2016 at 12:23 AM, Michał Górny <[hidden email]> wrote:
Hello, everyone.

I'd like to point out a major problem in Gentoo: there's a fair number
of developers who add various local workarounds to problems they meet
and don't bother to report a bug. Worst than that, this applies not
only for upstream problems but also to Gentoo eclass/ebuild-related
issues.


Example: udev people had problems with MULTILIB_WRAPPED_HEADERS
in the past. Instead of contacting me (which would result in helpful
explanation how to do things properly), they abused bash to disable
the check function implicitly in the ebuilds.

Nobody bothered to inform me of the issue there. Instead, I had to
notice it looking at the udev ebuilds accidentally. Furthermore, in
most of the ebuilds the workaround was no longer necessary but nobody
bothered to check that.


Example 2: Coacher had problem with git-r3 not trying fallback URIs
when earlier URI was https and https wasn't supported in git. So he
reordered URIs to have https last. With tiny explanation in some random
commit message.

So we have a problem that affects around a half of git-r3 packages
(using quick grep, results inaccurate), however minor it is. Worse, it
affects the policy of preferring https and causes some people to reject
the policy silently. And nobody gives a damn to report it!


Therefore, I'd like to request establishing an official policy against
workarounds with no associated bug reports.

Your thoughts?

--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

+1.

Anything serious enough to require a workaround or an upstream deviation should be documented in a bug report.

And may also be something we should poke upstream about anyway. If junk hits us in gentoo, it may have come from upstream and may affect users outside of gentoo.
Reply | Threaded
Open this post in threaded view
|

Re: Local workarounds with no reported bugs

Patrice Clement
In reply to this post by Michał Górny-5
Monday 17 Oct 2016 09:23:09, Michał Górny wrote :

> Hello, everyone.
>
> I'd like to point out a major problem in Gentoo: there's a fair number
> of developers who add various local workarounds to problems they meet
> and don't bother to report a bug. Worst than that, this applies not
> only for upstream problems but also to Gentoo eclass/ebuild-related
> issues.
>
> --8<--snip--8<--snip--8<--snip--8<--snip--8<--
>
> Therefore, I'd like to request establishing an official policy against
> workarounds with no associated bug reports.
>
> Your thoughts?
>
> --
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>
Michal

You're being emotional in my opinion and as a result, are painting *all* Gentoo
developers with a broad brush. Relax. We don't need yet another policy to "fix"
two problems you've encountered, this sounds silly. To be honest, I don't
understand your 2nd example: a change was made in an eclass and as all eclass
changes, these need to be discussed either here on the mailing list or via IRC.
You seem to be maintainer of git-r3; who made the commit? did you sign off
on it? if not, why was it merged? etc. Give us a bit more context please. Your
message looks more like a rant rather than a rational proposal.

Cheers,

--
Patrice Clement
Gentoo Linux developer
http://www.gentoo.org

signature.asc (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Local workarounds with no reported bugs

Paweł Hajdan, Jr.
On 17/10/2016 12:42, Patrice Clement wrote:
> We don't need yet another policy to "fix" two problems you've
> encountered

+1 ; policies don't always fix things

It's a worthwhile guideline though - as Gentoo devs, and maybe even
wider community, we should work together to fix problems.

That's one of the advantages I see in open source and communities - that
we don't need to work around each other's bugs, but can just squash them
at the source.

Paweł


signature.asc (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Local workarounds with no reported bugs

Raymond Jennings
My biggest ​opinion regarding workarounds and bugs, is that we're sweeping things under the rug that should at least be documented, and perhaps fixed...or even punted upstream if its serious enough.

Changing the status quo may require some adjustment though, but I suppose we could start by openly documenting a bug if we find a workaround that does not already have a bug number associated with it.  I've seen several ebuilds where workarounds are applied, but the workaround also has a bug number in the comment.
Reply | Threaded
Open this post in threaded view
|

Re: Local workarounds with no reported bugs

Rich Freeman
On Mon, Oct 17, 2016 at 9:09 AM, Raymond Jennings <[hidden email]> wrote:
>
> Changing the status quo may require some adjustment though, but I suppose we
> could start by openly documenting a bug if we find a workaround that does
> not already have a bug number associated with it.  I've seen several ebuilds
> where workarounds are applied, but the workaround also has a bug number in
> the comment.

The other side of this is being approachable so that people don't feel
like they're about to demonstrate their incompetence by filing a bug.
FOSS tends to be a meritocracy, and I think people sometimes work in
their own little corner because they're afraid of being shamed for not
"getting it."  In reality having mistakes exposed shouldn't be
unpleasant, and we should be able to use it to grow.

I can see how a new developer might be reluctant to suggest that some
very experienced developer has made a mistake in an eclass.  Of
course, that doesn't make this OK.  We should be speaking up when we
see mistakes, and we should be gracious both when our mistakes are
pointed out or somebody doing so has made a mistake themselves.

--
Rich

Reply | Threaded
Open this post in threaded view
|

Re: Local workarounds with no reported bugs

Ilya Tumaykin
In reply to this post by Michał Górny-5
On Monday 17 October 2016 09:23:09 Michał Górny wrote:
> Hello, everyone.

Hello.

Coacher's here.


> Example 2: Coacher had problem with git-r3 not trying fallback URIs
> when earlier URI was https and https wasn't supported in git. So he
> reordered URIs to have https last. With tiny explanation in some random
> commit message.

Original user's request [1], my PR [2], commit in question [3], bug: [4].
I've addressed a user's issue and reported a bug to Gentoo bugzilla the following day.
I don't see a problem with my workflow.


> So we have a problem that affects around a half of git-r3 packages
> (using quick grep, results inaccurate), however minor it is. Worse, it
> affects the policy of preferring https and causes some people to reject
> the policy silently.

Please share a link to this policy as I was unable to find it neither here [5], nor here [6].


> And nobody gives a damn to report it!

You expect me to create bugs the very second I encounter smth resembling a problem
without doing at least some minimum research on the matter? I don't do this.
I made the commit around 1 AM localtime, went to sleep,
and at 9 AM localtime you already jumping to conclusions in g-dev ML.


> Therefore, I'd like to request establishing an official policy against
> workarounds with no associated bug reports.
>
> Your thoughts?

You are quite emotional because of a change that didn't make it to the tree yet
expecting other people to provide 24/7 level of support for some reason.
At least this is how I see things from here.

No official policy is required.


[1]: https://github.com/gentoo/gentoo/pull/2570
[2]: https://github.com/gentoo/gentoo/pull/2572
[3]: https://github.com/gentoo/gentoo/pull/2572/commits/37a4eb12691b27631f4f23fe60dc26aff5f4fe47
[4]: https://bugs.gentoo.org/show_bug.cgi?id=597356
[5]: https://wiki.gentoo.org/wiki/Project:GLEP#Implemented_GLEPs_.28Final_or_Active.29
[6]: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Policies

--
Best regards.
Ilya Tumaykin.

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Local workarounds with no reported bugs

Raymond Jennings
My personal opinion:

If you have to work around it, its already a bug.
Reply | Threaded
Open this post in threaded view
|

Re: Local workarounds with no reported bugs

Ian Stakenvicius-2
In reply to this post by Michał Górny-5
On 17/10/16 03:23 AM, Michał Górny wrote:

> Hello, everyone.
>
> I'd like to point out a major problem in Gentoo: there's a fair number
> of developers who add various local workarounds to problems they meet
> and don't bother to report a bug. Worst than that, this applies not
> only for upstream problems but also to Gentoo eclass/ebuild-related
> issues.
>
>
> Example: udev people had problems with MULTILIB_WRAPPED_HEADERS
> in the past. Instead of contacting me (which would result in helpful
> explanation how to do things properly), they abused bash to disable
> the check function implicitly in the ebuilds.
>
> Nobody bothered to inform me of the issue there. Instead, I had to
> notice it looking at the udev ebuilds accidentally. Furthermore, in
> most of the ebuilds the workaround was no longer necessary but nobody
> bothered to check that.
>
>
> Example 2: Coacher had problem with git-r3 not trying fallback URIs
> when earlier URI was https and https wasn't supported in git. So he
> reordered URIs to have https last. With tiny explanation in some random
> commit message.
>
> So we have a problem that affects around a half of git-r3 packages
> (using quick grep, results inaccurate), however minor it is. Worse, it
> affects the policy of preferring https and causes some people to reject
> the policy silently. And nobody gives a damn to report it!
>
>
> Therefore, I'd like to request establishing an official policy against
> workarounds with no associated bug reports.
>
> Your thoughts?
>
To be clear, are you referring here to workarounds only regarding
gentoo related stuffs (use of eclasses, package manager (ie portage)
functionality, etc) or are you also referring to the various
workarounds we as maintainers need to do to say, the use of build
tools (cmake, etc) or upstream's codebase/build system itself, to
successfully package it as well?




signature.asc (220 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Local workarounds with no reported bugs

William L. Thomson Jr.
In reply to this post by Michał Górny-5
On Monday, October 17, 2016 9:23:09 AM EDT Michał Górny wrote:
>
> Example: udev people had problems with MULTILIB_WRAPPED_HEADERS
> in the past. Instead of contacting me (which would result in helpful
> explanation how to do things properly), they abused bash to disable
> the check function implicitly in the ebuilds.

Should we call "bash protective services" to report the abuse? They and I have
no tolerance for bash abusers, they should be dealt with swiftly...

Now to go abuse ksh...

> Nobody bothered to inform me of the issue there. Instead, I had to
> notice it looking at the udev ebuilds accidentally. Furthermore, in
> most of the ebuilds the workaround was no longer necessary but nobody
> bothered to check that.

How would they know to contact you? Is it documented as the work flow
somewhere?

> So we have a problem that affects around a half of git-r3 packages
> (using quick grep, results inaccurate), however minor it is. Worse, it
> affects the policy of preferring https and causes some people to reject
> the policy silently. And nobody gives a damn to report it!

If you see a problem fix it. If you have something to contribute to further a
package then make the change. That in my opinion is working as a team,
collaboration.
 
Also report the issues/changes in the log, tends to make a better argument in
the long run and a better learning process and environment.

--
William L. Thomson Jr.

signature.asc (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Local workarounds with no reported bugs

Patrick Lauer
In reply to this post by Michał Górny-5
On 10/17/16 09:23, Michał Górny wrote:

> Hello, everyone.
>
> I'd like to point out a major problem in Gentoo: there's a fair number
> of developers who add various local workarounds to problems they meet
> and don't bother to report a bug. Worst than that, this applies not
> only for upstream problems but also to Gentoo eclass/ebuild-related
> issues.
>
>
> Example: udev people had problems with MULTILIB_WRAPPED_HEADERS
> in the past. Instead of contacting me
... bus factor of 1, that's not a good strategy in general.

> (which would result in helpful
> explanation how to do things properly), they abused bash to disable
> the check function implicitly in the ebuilds.


> Nobody bothered to inform me of the issue there.
Well, you didn't ask ;)

 Instead, I had to

> notice it looking at the udev ebuilds accidentally. Furthermore, in
> most of the ebuilds the workaround was no longer necessary but nobody
> bothered to check that.
>
>
> Example 2: Coacher had problem with git-r3 not trying fallback URIs
> when earlier URI was https and https wasn't supported in git. So he
> reordered URIs to have https last. With tiny explanation in some random
> commit message.
>
> So we have a problem that affects around a half of git-r3 packages
> (using quick grep, results inaccurate), however minor it is. Worse, it
> affects the policy of preferring https and causes some people to reject
> the policy silently. And nobody gives a damn to report it!
>
>
> Therefore, I'd like to request establishing an official policy against
> workarounds with no associated bug reports.
That's too fuzzy to make a policy. Feels good, everyone agrees with the
idea, but where's the limit? When is it a required fix, when it is just
a workaround? What needs to be upstreamed, and what can't be upstreamed?

>
> Your thoughts?
>
I like the general idea of ... like ... improving ... things, but you
should be more precise and try to avoid creating situations with a bus
factor of one.

Reply | Threaded
Open this post in threaded view
|

Re: Local workarounds with no reported bugs

Michał Górny-5
On Tue, 18 Oct 2016 21:09:44 +0200
Patrick Lauer <[hidden email]> wrote:

> On 10/17/16 09:23, Michał Górny wrote:
> > Hello, everyone.
> >
> > I'd like to point out a major problem in Gentoo: there's a fair number
> > of developers who add various local workarounds to problems they meet
> > and don't bother to report a bug. Worst than that, this applies not
> > only for upstream problems but also to Gentoo eclass/ebuild-related
> > issues.
> >
> >
> > Example: udev people had problems with MULTILIB_WRAPPED_HEADERS
> > in the past. Instead of contacting me  
> ... bus factor of 1, that's not a good strategy in general.
s/me/anyone on multilib team/. Does that make you happy? But yes, I
should add a big fat warning to the docs.

--
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

attachment0 (949 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Local workarounds with no reported bugs

Daniel Campbell (zlg)
In reply to this post by Raymond Jennings
On 10/17/2016 06:09 AM, Raymond Jennings wrote:
> My biggest ​opinion regarding workarounds and bugs, is that we're
> sweeping things under the rug that should at least be documented, and
> perhaps fixed...or even punted upstream if its serious enough.
>
> Changing the status quo may require some adjustment though, but I
> suppose we could start by openly documenting a bug if we find a
> workaround that does not already have a bug number associated with it.
> I've seen several ebuilds where workarounds are applied, but the
> workaround also has a bug number in the comment.
I'd say this falls under the scope of QA, and QA should have some sort
of "quick reference" guide to help developers out and cover situations
they've come across. At the moment, the only resource I'm aware of
(aside from the obvious devmanual and PMS) that we have is either
e-mailing [hidden email] or using repoman. repoman can't (and shouldn't) cover
_everything_, but it's hard to take rants like this seriously when
little is done to communicate to devs at large to "color in the lines".

I ran into something similar when writing the wrapper script for
media-sound/apulse. It took 3 attempts and being told "you're doing it
wrong" 2-3 times before I figured out exactly how to do it. Had it been
documented on a wiki page or something similar, it would have saved me
and others a considerable amount of time.

We need solid QA docs. The devmanual and repoman are great starts, and
answer a bunch of questions. When/if QA comes across new situations and
comes up with 'blessed' solutions, we need a way to check them out
instead of waiting for it to hit Git and be smacked with a "this is
wrong" e-mail.

Just my 2¢.

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


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Local workarounds with no reported bugs

Raymond Jennings
My main concern in this thread, is that I don't want anything swept under the rug in such a way that a wider issue is masked that actually needs dealt with anyway.

Examples:
* A workaround to deal with a bug, especially one filed on b.g.o
  - What happens if/when the bug gets fixed?  Won't the workaround need removed?
  - If the bug is serious enough, a workaround
* An upstream problem
  - Upstream might want (or need to be coaxed) into taking a fix
* Anything common to more than one package`

Routine workarounds, like stuff on gentoo that works differently from upstream (aka build process mangling) probably doesn't count.

On Tue, Oct 18, 2016 at 11:11 PM, Daniel Campbell <[hidden email]> wrote:
On 10/17/2016 06:09 AM, Raymond Jennings wrote:
> My biggest ​opinion regarding workarounds and bugs, is that we're
> sweeping things under the rug that should at least be documented, and
> perhaps fixed...or even punted upstream if its serious enough.
>
> Changing the status quo may require some adjustment though, but I
> suppose we could start by openly documenting a bug if we find a
> workaround that does not already have a bug number associated with it.
> I've seen several ebuilds where workarounds are applied, but the
> workaround also has a bug number in the comment.
I'd say this falls under the scope of QA, and QA should have some sort
of "quick reference" guide to help developers out and cover situations
they've come across. At the moment, the only resource I'm aware of
(aside from the obvious devmanual and PMS) that we have is either
e-mailing [hidden email] or using repoman. repoman can't (and shouldn't) cover
_everything_, but it's hard to take rants like this seriously when
little is done to communicate to devs at large to "color in the lines".

I ran into something similar when writing the wrapper script for
media-sound/apulse. It took 3 attempts and being told "you're doing it
wrong" 2-3 times before I figured out exactly how to do it. Had it been
documented on a wiki page or something similar, it would have saved me
and others a considerable amount of time.

We need solid QA docs. The devmanual and repoman are great starts, and
answer a bunch of questions. When/if QA comes across new situations and
comes up with 'blessed' solutions, we need a way to check them out
instead of waiting for it to hit Git and be smacked with a "this is
wrong" e-mail.

Just my 2¢.

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