Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask

[Rich Freeman <rich0@gentoo.org>]

On Fri, Nov 15, 2013 at 1:53 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>
> I don't really want to bring up this episode again, but it is a
> telling example, which you asked for.

I appreciate that.  I did ask for an example.  I'll also limit my
comments just to things that I think are more helpful moving forward.

>
> As can be seen from the ChangeLog, I was the primary maintainer.

Depends on your definition of maintainer.  If you define maintainer as
somebody who has actually been doing work on a package, then you were.
 If you define it as the person listed in metadata.xml, then you
weren't.

Ideally those should match, so that when projects have to go running
around the tree making changes they don't have to read between the
lines to figure out who is the right contact for any particular
package.

They match now, which is good.

>
> I am even tempted to undo the multilib changes to freetype, since it
> is still causing trouble (just search for freetype bugs and see how
> often multilib pops up).

Well, make sure you talk to the OTHER maintainer for that package,
which is the multilib team, before doing that.  You don't own the
package - you just help to maintain it.  I don't want to rehash the
thread from last summer - I do appreciate your feelings and I'm trying
to find a balance.  I want to appreciate the fact that maintainers
have the largest investment in their packages, but at the same time
those working on projects are investing in Gentoo as well.

>>
>> Michał did add the multilib project as a co-maintainer, taking
>> responsibility for dealing with the multilib-related issues long-term.
>>  In my mind this is the sort of things projects should do.
>
> Indeed, but more communication with the current actual maintainers of
> the package in question should also be part of that.

You're both "actual" maintainers now.  Certainly I agree that you
should be talking to each other.  :)  I'd hope that things are going
better now, but if they aren't I'd hope that Comrel would provide some
assistance here.

>
> I am also cautiously optimistic about a renewed QA team, which could
> be involved more in this kind of issues.

I tend to agree here, but their role isn't to pick winners so much as
to defend the general integrity of the tree.  I think the challenge is
figuring out how good, "good enough," is before these packages end up
in ~arch (which IS intended for TESTING packages, but packages that
are fairly likely to work with some maintainer testing already).

> If you say council should take more of a leadership role, then maybe
> this issue can be decided by council and a clear direction be taken by
> the distro as a whole? Then those who oppose the choice made can
> either put up or shut up, and we can all work at implementing the
> chosen solution.

Should we pick an init system while we're at it?  :)

Honestly, I don't think we can really choose anything at this point as
none of the solutions are really fully-baked.  If the Council simply
pronounced support for one of them the only result would be that
people might stop working on the other two, with no further progress
on the chosen one.  Then if that one dies on the vine we're stuck.

I do have thoughts around things that could be improved, but I don't
think either of the new options are at the point where they make
sense.  Both options really have to progress further on their own
before we can think about standardizing/etc.

Rich