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 CF6D51381F3 for ; Fri, 14 Dec 2012 14:37:31 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 29FA0E0652; Fri, 14 Dec 2012 14:37:22 +0000 (UTC) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 896B9E0642 for ; Fri, 14 Dec 2012 14:36:50 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id oi10so3369875obb.40 for ; Fri, 14 Dec 2012 06:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wHM9mL5VfPOqSm2DBeted87a7bsAgYjx0cLjRP1GFBI=; b=HTY2IADAfiKE4AyuJut+Tjyu1961dcACzz0Mes5yM6lxSjIqzPZNMA5VSIUH6uELTi n4ENZ82uIC8vQLkBSwo4ZlqvJe/mxJHUCX2xB6s6YaU2aWqFw7eb8qRwFqStPmLU2zwt EP/pPU3nh6xNU/uuYdA0dakY4qAXVeNkqXZE5DHEBfxEdwTTXzB+k70BnmHAkOG9W1vi warbf1V0ztKGV5vF3CBRKIKfoqMnqyyp/0fRtfMi4ycA47MRLeKdcIdvoQnusM0266FR D/hb7BjctZ3xvVYoChy+Do85eU72NUHLek563SqJmbieACGWLc2iEH5uNV96wkzjtFkL /Dsw== 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 Received: by 10.182.0.68 with SMTP id 4mr4754366obc.80.1355495809680; Fri, 14 Dec 2012 06:36:49 -0800 (PST) Sender: markos.chandras@gmail.com Received: by 10.76.28.169 with HTTP; Fri, 14 Dec 2012 06:36:49 -0800 (PST) In-Reply-To: <20121214152957.24e41549@pomiocik.lan> References: <20121210222717.6424ef66@pomiocik.lan> <20121212103231.546140e2@pomiocik.lan> <50C85CB9.9040603@gentoo.org> <201212132133.57417.dilfridge@gentoo.org> <20121213214344.70c37384@pomiocik.lan> <50CA4CC6.5010800@gentoo.org> <20121214152957.24e41549@pomiocik.lan> Date: Fri, 14 Dec 2012 14:36:49 +0000 X-Google-Sender-Auth: 0coXdK8Cr9fpEo3i8xg_rkE7r-k Message-ID: Subject: Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86? From: Markos Chandras To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= Cc: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 48ff9930-60e5-413a-b1e6-7fe5a98d8ab8 X-Archives-Hash: 596d4aecff98ba93c84698459e9c2488 On 14 December 2012 14:29, Micha=C5=82 G=C3=B3rny wrote= : > On Fri, 14 Dec 2012 12:38:24 +0000 > Markos Chandras wrote: > >> On 13 December 2012 21:46, Zac Medico wrote: >> > On 12/13/2012 12:43 PM, Micha=C5=82 G=C3=B3rny wrote: >> >> On Thu, 13 Dec 2012 21:33:50 +0100 >> >> "Andreas K. Huettel" wrote: >> >> >> >>> Am Mittwoch, 12. Dezember 2012, 11:30:17 schrieb Zac Medico: >> >>>>> Yes, and having 'stable' and 'unstable' profiles will work just >> >>>>> the same. Except for the fact that it will be a bit cleaner, not r= equire >> >>>>> EAPI=3D5 at all and probably make arch testing a bit easier for a = few >> >>>>> people. >> >>>> >> >>>> Sounds good to me. >> >>> >> >>> Except that it completely breaks stabilization procedures, since pac= kages are >> >>> then not only tested with a larger range of useflags, but with an en= tirely >> >>> different profile. Not such a great idea. >> >>> >> >>> The whole point of the stable masking was to keep the changes minima= l when >> >>> going from a "testing" to a "stable" state - by only restricting the= use flag >> >>> choices, and nothing else. This means most of the testing done with = ~arch >> >>> packages is still valid and provides meaningful feedback to maintain= ers and >> >>> arch teams for stabilization. >> >> >> >> Well, it's all a question of decisions, I believe. If we make sure th= at >> >> the new 'unstable' profiles differ from the 'stable' ones only by >> >> additional masked/unmasked USE flags, I don't think it'd be an issue. >> > >> > Yeah, should be fine. >> >> How are you engoing to ensure that? And how are you going to monitor >> them so they will not get out-of-sync in future? We have plenty of >> examples of stale profile entries >> all over the profiles/arch directory so I think that the stable >> *use.stable.mask will also end up >> unmaintained in the near future. > > What is your solution then? Keeping two revisions of most ebuilds so > that one could be stabilized? I don't see how that is more > maintainable, except for a few days who will easily stay out of it > and pretend that the issue doesn't exist. > > -- > Best regards, > Micha=C5=82 G=C3=B3rny By keeping multiple ebuilds around you are transfering the maintenance responsibility to the invdividual developer/herd. By adding the *use.stable.mask to each architecture, you are transferring this responsibility to the arch maintainers. We already have plenty of understaffed arches, I don't think it is wise to throw more responsibilities to them. Unless of course all developers are allowed to touch these *stable* profiles which personally I don't like because arches will lose control of their stable trees. --=20 Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2