Re: [gentoo-dev] Gentoo Council Reminder for June 11

[Ciaran McCreesh]

On Wed, 10 Jun 2009 23:21:49 +0200
Tobias Scherbaum <dertobi123@g.o> 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.

-- 
Ciaran McCreesh