From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 49FED138247 for ; Fri, 15 Nov 2013 06:53:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6D9D3E0AF5; Fri, 15 Nov 2013 06:53:02 +0000 (UTC) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 758E1E0A7D for ; Fri, 15 Nov 2013 06:53:01 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id at1so4081756iec.2 for ; Thu, 14 Nov 2013 22:53:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=VIWa7O0OwQaOD5Q7OpQzxYoej7VuS57ZaYMJZ5EDSE0=; b=u+di8waYxhUZS0jzhcz3DaJPajQ8bRMCbZLIfoaxR8mWShIc0fnxQSwRfYLbrV8Jp1 9ho8Rtjjz13lI/KwM9VHBaessHqvfvEMD5NNbRqhygDmabywiQDxHIVgqGjrHloycVZG PXWyPLPlozqnerMDS0wnnCc81IH5XDCGi0TrF5GbZhXRHhTvvkTVPWbTfX8clAwp1Haq Me25afzQk01JrX0+bYMUJjT2TCqryEjRuEsJmsqjzaCvIiGaUh57FByMWi2ZkrpjIFFj 58Ox2AOd0fGa1hT42jQs+mrrUz1sDmb1RR5nuHgK6AQIIFDB14F9bRDUrKCmOhxEieMJ I1ig== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.50.141.133 with SMTP id ro5mr3719643igb.35.1384498380632; Thu, 14 Nov 2013 22:53:00 -0800 (PST) Sender: yngwin@gmail.com Received: by 10.64.227.240 with HTTP; Thu, 14 Nov 2013 22:53:00 -0800 (PST) In-Reply-To: References: <20131113151012.04145837@gentoo.org> <5283948F.1000409@gentoo.org> <52841023.9010208@gentoo.org> <20131114061328.09136f6f@gentoo.org> Date: Fri, 15 Nov 2013 14:53:00 +0800 X-Google-Sender-Auth: RmqPmo2UpJjDY0SvMJyJTbvTiZ4 Message-ID: Subject: Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask From: Ben de Groot To: gentoo-dev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 2bdf8c61-3d34-4ab2-b014-deebcd4ba224 X-Archives-Hash: ed2c30f6c4233abae924b9e787078e1b On 15 November 2013 01:32, Rich Freeman wrote: > On Thu, Nov 14, 2013 at 11:38 AM, Ben de Groot 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=C5=82 did offer to just maintain the stat= us > quo on that package instead of migrating it, and apparently he thought > he had the all-clear to migrate it anyway. > > Micha=C5=82 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=C5= =82 > 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. --=20 Cheers, Ben | yngwin Gentoo developer