1 |
On Wed, 10 Jun 2009 23:21:49 +0200 |
2 |
Tobias Scherbaum <dertobi123@g.o> wrote: |
3 |
> And for EAPI development: I did dislike the google spreadsheet which |
4 |
> has been used for EAPI-3 and don't think this has proved to be |
5 |
> useful. If we do opt for any public collaboration development process |
6 |
> (instead of say some file in $SCM) we should use a simple Wiki and be |
7 |
> done. Tracking changes made to that document is a requirement from my |
8 |
> pov. Using bugs for each feature and an EAPI tracker bug would be |
9 |
> another possible way to organize this. |
10 |
|
11 |
Oh please no wiki. The problem for EAPI 3 was that feature requests |
12 |
were on a google spreadsheet, and on bugzilla, and on a pms draft |
13 |
branch, and on a text file in various people's devspaces. |
14 |
|
15 |
The workflow that'd be easiest is: |
16 |
|
17 |
* Requests go onto bugzilla, where they could be nicely organised into |
18 |
"can do this now", "probably not doable in the timeframe we're |
19 |
looking for" and "not detailed enough to be usable". |
20 |
|
21 |
* We get rough diffs for PMS for everything in the "can do this now" |
22 |
category, and give them all an arbitrary codename that in no way |
23 |
describes the feature (so that certain people can't vote and discuss |
24 |
things based upon what they think the feature is without bothering to |
25 |
find out if it's anything to do with what they assume). |
26 |
|
27 |
* Based upon developer feedback, the Council rates each of those |
28 |
codenames as "yes", "no", "whatever" or "needs more discussion". For |
29 |
those that need discussion, the people who voted for discussion |
30 |
explain what they think needs discussing, and we sort that out. |
31 |
|
32 |
* The PMS people come up with exact wording for things that are mostly |
33 |
"yes". |
34 |
|
35 |
* The Council votes for final approval, pending Portage implementation. |
36 |
|
37 |
* Portage implements it in ~arch. People start using it in ~arch. |
38 |
|
39 |
* Portage goes stable. People are allowed to start using it in stable |
40 |
for things that aren't deps of anything super-critical. |
41 |
|
42 |
What we don't need is lots of people running around doing their own |
43 |
thing in different places. What we do need is for a single |
44 |
waterflow-like workflow with a good way of coordinating it that doesn't |
45 |
rely upon the PMS team chasing everyone up and trying to keep track of |
46 |
everything. |
47 |
|
48 |
-- |
49 |
Ciaran McCreesh |