[prev in list] [next in list] [prev in thread] [next in thread]
List: gentoo-dev
Subject: Re: [gentoo-dev] Local workarounds with no reported bugs
From: Raymond Jennings <shentino () gmail ! com>
Date: 2016-10-19 15:07:59
Message-ID: CAGDaZ_rnpW1hbyMEQgtQ1VpEe-O_+qqP7gHpmyHZzTjYN=Ofug () mail ! gmail ! com
[Download RAW message or body]
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 <zlg@gentoo.org> 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
>
>
[Attachment #3 (text/html)]
<div dir="ltr">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.<div><br></div><div>Examples:</div><div>* A workaround to deal with \
a bug, especially one filed on b.g.o</div><div> - What happens if/when the bug gets \
fixed? Won't the workaround need removed?</div><div> - If the bug is serious \
enough, a workaround</div><div>* An upstream problem</div><div> - Upstream might \
want (or need to be coaxed) into taking a fix</div><div>* Anything common to more \
than one package`</div><div><br></div><div>Routine workarounds, like stuff on gentoo \
that works differently from upstream (aka build process mangling) probably \
doesn't count.</div></div><div class="gmail_extra"><br><div \
class="gmail_quote">On Tue, Oct 18, 2016 at 11:11 PM, Daniel Campbell <span \
dir="ltr"><<a href="mailto:zlg@gentoo.org" \
target="_blank">zlg@gentoo.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 10/17/2016 06:09 AM, \
Raymond Jennings wrote:<br> > My biggest ​opinion regarding workarounds and \
bugs, is that we're<br> > sweeping things under the rug that should at least \
be documented, and<br> > perhaps fixed...or even punted upstream if its serious \
enough.<br> ><br>
> Changing the status quo may require some adjustment though, but I<br>
> suppose we could start by openly documenting a bug if we find a<br>
> workaround that does not already have a bug number associated with it.<br>
> I've seen several ebuilds where workarounds are applied, but the<br>
> workaround also has a bug number in the comment.<br>
</div></div>I'd say this falls under the scope of QA, and QA should have some \
sort<br> of "quick reference" guide to help developers out and cover \
situations<br> they've come across. At the moment, the only resource I'm \
aware of<br> (aside from the obvious devmanual and PMS) that we have is either<br>
e-mailing qa@g.o or using repoman. repoman can't (and shouldn't) cover<br>
_everything_, but it's hard to take rants like this seriously when<br>
little is done to communicate to devs at large to "color in the lines".<br>
<br>
I ran into something similar when writing the wrapper script for<br>
media-sound/apulse. It took 3 attempts and being told "you're doing it<br>
wrong" 2-3 times before I figured out exactly how to do it. Had it been<br>
documented on a wiki page or something similar, it would have saved me<br>
and others a considerable amount of time.<br>
<br>
We need solid QA docs. The devmanual and repoman are great starts, and<br>
answer a bunch of questions. When/if QA comes across new situations and<br>
comes up with 'blessed' solutions, we need a way to check them out<br>
instead of waiting for it to hit Git and be smacked with a "this is<br>
wrong" e-mail.<br>
<br>
Just my 2 ¢.<br>
<br>
~zlg<br>
<span class="HOEnZb"><font color="#888888">--<br>
Daniel Campbell - Gentoo Developer<br>
OpenPGP Key: 0x1EA055D6 @ hkp://<a href="http://keys.gnupg.net" rel="noreferrer" \
target="_blank">keys.gnupg.net</a><br>
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6<br>
<br>
</font></span></blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic