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.
