From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1MEVyI-0000mB-2I for garchives@archives.gentoo.org; Wed, 10 Jun 2009 22:08:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 59B811C001; Wed, 10 Jun 2009 22:08:36 +0000 (UTC) Received: from mail-ew0-f213.google.com (mail-ew0-f213.google.com [209.85.219.213]) by pigeon.gentoo.org (Postfix) with ESMTP id 022101C001 for ; Wed, 10 Jun 2009 22:08:35 +0000 (UTC) Received: by ewy9 with SMTP id 9so1127577ewy.34 for ; Wed, 10 Jun 2009 15:08:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=EN8nGzCk4TqiFFIosb8MOdmjfichAhw8SIzC9SE3KuM=; b=C0RKVroenKbyYe5hJbrsR5p5W/SCRbZVIaNcLwoz+5zVoRTSJQMIkwFJNkP3MjNHM3 AWupfXuMOwuJFAtvI4gN2CaWJ+C4llQ+qhQk8weFjR42/YShimpyfrXGTu2sMPz9CNu7 6LjFJpwvZdOYi6xggqLSKap9l2gFb4u+AGZJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=Mtq+P2ugM5jpqez3ZlDDHkFpdGvMwtgIhjaj2T5KsaPtKJ0B1dx2gb5zxeukLy6y3X i2xaLAhTK04eMhxZyaxjnnoKcNeD9x6x0u3GAONrRFNKZf7bmDtbyoB0e4w98JRVsgrN /FI6swgmGRW+KrzHu+khasCfhMk3C5HxQCu+k= Received: by 10.210.60.8 with SMTP id i8mr1448287eba.28.1244671715343; Wed, 10 Jun 2009 15:08:35 -0700 (PDT) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id 10sm147634eyd.42.2009.06.10.15.08.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Jun 2009 15:08:35 -0700 (PDT) Date: Wed, 10 Jun 2009 23:08:22 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Gentoo Council Reminder for June 11 Message-ID: <20090610230822.0a9a08fc@snowcone> In-Reply-To: <1244668909.6190.23.camel@homer.ob.libexec.de> References: <1244154362.11496.172.camel@localhost> <1244668909.6190.23.camel@homer.ob.libexec.de> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; 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-SHA1; boundary="Sig_/yfDfBKF0+yT7EIvAfxlL9c8"; protocol="application/pgp-signature" X-Archives-Salt: ad376813-2a71-444e-84b2-321f51f0ae1d X-Archives-Hash: d3a4758c455fded00608e891f525d3cc --Sig_/yfDfBKF0+yT7EIvAfxlL9c8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 10 Jun 2009 23:21:49 +0200 Tobias Scherbaum wrote: > And for EAPI development: I did dislike the google spreadsheet which > has been used for EAPI-3 and don't think this has proved to be > useful. If we do opt for any public collaboration development process > (instead of say some file in $SCM) we should use a simple Wiki and be > done. Tracking changes made to that document is a requirement from my > pov. Using bugs for each feature and an EAPI tracker bug would be > another possible way to organize this. Oh please no wiki. The problem for EAPI 3 was that feature requests were on a google spreadsheet, and on bugzilla, and on a pms draft branch, and on a text file in various people's devspaces. The workflow that'd be easiest is: * Requests go onto bugzilla, where they could be nicely organised into "can do this now", "probably not doable in the timeframe we're looking for" and "not detailed enough to be usable". * We get rough diffs for PMS for everything in the "can do this now" category, and give them all an arbitrary codename that in no way describes the feature (so that certain people can't vote and discuss things based upon what they think the feature is without bothering to find out if it's anything to do with what they assume). * Based upon developer feedback, the Council rates each of those codenames as "yes", "no", "whatever" or "needs more discussion". For those that need discussion, the people who voted for discussion explain what they think needs discussing, and we sort that out. * The PMS people come up with exact wording for things that are mostly "yes". * The Council votes for final approval, pending Portage implementation. * Portage implements it in ~arch. People start using it in ~arch. * Portage goes stable. People are allowed to start using it in stable for things that aren't deps of anything super-critical. What we don't need is lots of people running around doing their own thing in different places. What we do need is for a single waterflow-like workflow with a good way of coordinating it that doesn't rely upon the PMS team chasing everyone up and trying to keep track of everything. --=20 Ciaran McCreesh --Sig_/yfDfBKF0+yT7EIvAfxlL9c8 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkowLtsACgkQ96zL6DUtXhHeaQCfVL7WLsRRTNJlopM7QMj0V67F DygAoKa1Z4/KGYXpfP4xgoXRURbFiPOl =IQuu -----END PGP SIGNATURE----- --Sig_/yfDfBKF0+yT7EIvAfxlL9c8--