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 24EBC1381F3 for ; Fri, 14 Dec 2012 14:59:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0661721C046; Fri, 14 Dec 2012 14:59:36 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 770F921C013 for ; Fri, 14 Dec 2012 14:59:02 +0000 (UTC) Received: from pomiocik.lan (unknown [213.195.166.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 866D433DC8B; Fri, 14 Dec 2012 14:59:00 +0000 (UTC) Date: Fri, 14 Dec 2012 15:59:08 +0100 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-dev@lists.gentoo.org Cc: hwoarang@gentoo.org Subject: Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86? Message-ID: <20121214155908.1fd79159@pomiocik.lan> In-Reply-To: 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> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.14; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; micalg=PGP-SHA256; boundary="Sig_/6qeGPvHbPpZNua9NR7u79YC"; protocol="application/pgp-signature" X-Archives-Salt: 35da2949-0b15-403c-b903-f528dc9e1055 X-Archives-Hash: 45b5d4ed8b804bd006aed1cfe6f72923 --Sig_/6qeGPvHbPpZNua9NR7u79YC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 14 Dec 2012 14:36:49 +0000 Markos Chandras wrote: > On 14 December 2012 14:29, Micha=C5=82 G=C3=B3rny wro= te: > > 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= require > >> >>>>> 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 p= ackages are > >> >>> then not only tested with a larger range of useflags, but with an = entirely > >> >>> different profile. Not such a great idea. > >> >>> > >> >>> The whole point of the stable masking was to keep the changes mini= mal when > >> >>> going from a "testing" to a "stable" state - by only restricting t= he use flag > >> >>> choices, and nothing else. This means most of the testing done wit= h ~arch > >> >>> packages is still valid and provides meaningful feedback to mainta= iners and > >> >>> arch teams for stabilization. > >> >> > >> >> Well, it's all a question of decisions, I believe. If we make sure = that > >> >> the new 'unstable' profiles differ from the 'stable' ones only by > >> >> additional masked/unmasked USE flags, I don't think it'd be an issu= e. > >> > > >> > 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 >=20 > 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. Yes and no. Although we have a few arches which believe nobody should touch their files (but instead wait a few weeks till they actually notice someone asked them to mask a flag), I think you shouldn't overreact on this. Let's talk on examples. A good example is pypy which is not stable on any arch. I don't really see a problem with Python team actually maintaining use.mask entry for that implementation. And even if arch teams preferred to handle this on their own, I don't think that's much work as long as it's clear what the goal is. A quick look at dev-python gives me almost 800 packages; a quick ugly grep gives around 350 packages with stable keywords. This means that in the near time there will be around 250-300 additional ebuilds to maintain just because we can't mask the pypy flag on stable arches. > 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. I'd like to point out that my proposal implies that the *current* arches become the stable arches, and new sub-arches would be the testing ones. Therefore, everyone will be allowed to touch like everyone is allowed to touch the *stable* profiles today. In other words, we mask python_targets_pypy* in the base profiles, and unmask them in the testing sub-profiles for amd64 & x86. --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/6qeGPvHbPpZNua9NR7u79YC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iJwEAQEIAAYFAlDLPrwACgkQfXuS5UK5QB2gYAP+MobobgLDYRMe8zehxWneu5ys MDTZReZcC6jsGg5Nud2zcBVYE2g3SyTli+BThqRAXhWwrJD3Wc4EhUaj3qiETt/F 2VvdpfetCrBpJgu1dJNqHe3t4bxbXI6/N+EB9k3ha3HaDPci4IEN8RD+Hiy1rDmd X8bR91pQTXjQdrwf/qI= =DdOA -----END PGP SIGNATURE----- --Sig_/6qeGPvHbPpZNua9NR7u79YC--