Re: [gentoo-dev] Local workarounds with no reported bugs

2016-10-19 Thread 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  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 qa@g.o 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
>
>

Re: [gentoo-dev] Local workarounds with no reported bugs

2016-10-19 Thread Daniel Campbell 
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 qa@g.o 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
Description: OpenPGP digital signature

Re: [gentoo-dev] Local workarounds with no reported bugs

2016-10-17 Thread William L. Thomson Jr. 
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
Description: This is a digitally signed message part.

Re: [gentoo-dev] Local workarounds with no reported bugs

2016-10-17 Thread Ian Stakenvicius 
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
Description: OpenPGP digital signature

Re: [gentoo-dev] Local workarounds with no reported bugs

2016-10-17 Thread Raymond Jennings 
My personal opinion:

If you have to work around it, its already a bug.

Re: [gentoo-dev] Local workarounds with no reported bugs

2016-10-17 Thread Ilya Tumaykin 
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
Description: This is a digitally signed message part.

Re: [gentoo-dev] Local workarounds with no reported bugs

2016-10-17 Thread Rich Freeman 
On Mon, Oct 17, 2016 at 9:09 AM, Raymond Jennings  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

Re: [gentoo-dev] Local workarounds with no reported bugs

2016-10-17 Thread 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.

Re: [gentoo-dev] Local workarounds with no reported bugs

2016-10-17 Thread 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
Description: OpenPGP digital signature

Re: [gentoo-dev] Local workarounds with no reported bugs

2016-10-17 Thread Patrice Clement 
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
> 

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
Description: PGP signature

Re: [gentoo-dev] Local workarounds with no reported bugs

2016-10-17 Thread Raymond Jennings 
On Mon, Oct 17, 2016 at 12: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?
>
> --
> Best regards,
> Michał Górny
> 
>

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

Re: [gentoo-dev] Local workarounds with no reported bugs

2016-10-17 Thread Kent Fredric 
On Mon, 17 Oct 2016 09:23:09 +0200
Michał Górny  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.



pgpS51GnH9zAz.pgp
Description: OpenPGP digital signature

[gentoo-dev] Local workarounds with no reported bugs

2016-10-17 Thread Michał Górny 
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



pgpJLw7ED9eKm.pgp
Description: OpenPGP digital signature