On 01/13/2010 09:24 AM, Mike Frysinger wrote:
On Tuesday 12 January 2010 15:51:28 Tomáš Chvátal wrote:
And since WE want to enable as-needed as default at some time we need to
work on the bugs
which isnt going to happen
This isn't really intended to point fingers at anybody in particular - I
haven't personally investigated the complexity of fixing the as-needed
issue for this particular package.
I think that logging as-needed bugs is certainly a value-add.
I think that tracking a blocker for as-needed is a value-add.
However, if we want to turn as-needed into a QA issue and try to enforce
it, I think that this should really be run past the council and
documented. It wouldn't hurt to also document tips for solving the
problem and the proper way to mask as-needed if it just isn't going to
work (even if we make as-needed the default that doesn't mean that we
can't mask it if we have to).
I think that devs should make good-faith efforts to fix as-needed
issues, but if the problem is with the overall upstream design and major
work is involved, that is an UPSTREAM problem. Sure, it is nice if
somebody wants to be an upstream contributor and fix their problems for
them, but I'm not sure that it is worth the Gentoo resources in every
single case. Maybe for system packages or common dependencies we might
push a little harder.
In any case, when this kind of controversy exists the best solution is
to make a proposal and ask the council to render a decision. It isn't
productive to have battles on the mailing list about whether something
should or shouldn't be policy.
I don't mean to suggest that QA or treecleaners or whatever absolutely
must run everything they do past the council. However, when we run into
genuine disagreements between projects/herds/devs that is the ultimate
escalation path.
Package mask is not a very good way to try to hit devs with a cluestick
anyway - the main victims of this sort of approach tend to be the users.
