List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Wed, 10 Jun 2009 23:21:49 +0200
Tobias Scherbaum <email@example.com> 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
* 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