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