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

[Ben de Groot <yngwin@gentoo.org>]

On 15 November 2013 01:32, Rich Freeman <rich0@gentoo.org> wrote:
> On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot <yngwin@gentoo.org> wrote:
>> I was particularly hit by this as maintainer of freetype, see bugs
>> 455070 and 459352 for some of the mess that could have been avoided.
>
> Looks like 455070 was the source of problems there (the other is just
> a tracker with the aftermath).  The package had no maintainer at the
> time, only a herd (per cvs).  There was a request in the bug for
> whether it was suitable to deploy to production.  Somebody associated
> with the herd gave a thumbs-up, apparently (I can only say that based
> on your comment - I have no idea how that was communicated).  Then
> something went wrong.  Since it caused problems, it was masked.  Those
> who run ~arch should be thanked for saving the stable users from
> potential breakage!
>
> I'm not sure what should have been done differently.  If the package
> maintainer (in this case a herd) says that something is good to go,
> why would anybody assume that it wasn't?  You suggested testing in an
> overlay 20 days earlier, but you weren't in any particularly
> privileged position at the time (you were presumably just another
> maintainer of the herd).

I don't really want to bring up this episode again, but it is a
telling example, which you asked for.

As can be seen from the ChangeLog, I was the primary maintainer. As a
member of the herd I didn't feel it necessary to assert any kind of
"privilege" any other way. I had already said "no, or at least wait"
but that was circumvented by asking another herd member who hadn't
touched the package in years. It would have been nice were I asked for
my okay before making any changes.

And as can be seen, the mess I feared for indeed took place. This
could have been prevented, in my opinion, had this seen more extensive
testing in an overlay.

And this is exactly why I am now more weary for the next package about
to be mangled: cairo (bug 488672).

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).

> I'm not pointing fingers here.  This was apparently a
> miscommunication, and part of the cause was a failure to document that
> there was a primary maintainer of the package (something which was
> subsequently corrected).  Michał did offer to just maintain the status
> quo on that package instead of migrating it, and apparently he thought
> he had the all-clear to migrate it anyway.
>
> 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.

> I'm sure there were other issues, but issues will happen when projects
> make changes.  That's just the way things roll around here.  If Michał
> just committed a change to a package without conferring with the
> maintainer at all or giving significant notice, I'd feel differently.
> I think we just need to learn and move forward, and from the looks of
> things we have.  Gentoo always has been a fairly "disruptive" distro,
> though it has settled down of late.  I don't think we're erring on the
> side of breaking systems too often right now, though I'm always for
> preventing that as long as it doesn't require ossification.
>
> (Just a note - this is all based on what I could piece together from
> cvs and bugzilla.  I'm sure those who were personally involved could
> contribute more detail. I'm not sure it is necessary that do so, but
> I'll gladly defer to those with firsthand knowledge.)
>
>>> In the end, stuff only
>>> gets done if people write code.  Your power in any FOSS project really
>>> comes down to your ability to write code or convince others to write
>>> code on your behalf.
>
>> No, it's more about your ability to commit and get away with it.
>
> So, I'm 100% for what Donnie said and in general I tend to lean
> towards saying "thanks, but no thanks" when a heavy contributor is
> driving everybody nuts.  However, the reality is that those who commit
> more also tend to be allowed to get away with committing more.  That's
> just human nature - we all like our free toys and we're reluctant to
> take too much objection when we're slapped around a little by the guy
> who is giving us the free toys.  There needs to be a balance, and from
> the sound of things Markos is looking to step in and adjust the
> balance if it gets out of line.  Honestly, I just wish everybody would
> do what they can to make his job easier, and I say that without
> pointing my fingers in any direction.  I think we have a really great
> thing going here...
>
> Rich
>

Markos has shown initiative and good ideas, so I'm looking forward to
positive changes.

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

As I see it now, with respect to multilib, we have three competing
solutions, but not a clear direction which way we want to go as a
distro:

1: emul-* packages
2: multilib-portage
3: multilib.eclass

I would like to vote for option 1, as it is the least intrusive and
does what we need. If it is really felt we need a more complete
solution, then my vote would be for 2, since 3 is too intrusive and
more likely to break or complicate stuff for normal users.

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.

-- 
Cheers,

Ben | yngwin
Gentoo developer