1 |
Ciaran McCreesh wrote: |
2 |
> Oh please no wiki. |
3 |
|
4 |
Whatever. My requirements are quite simple: public accessible, no |
5 |
accounts needed on 3rd party systems (like Google) to add feature |
6 |
requests or comments and changes must be traceable. Using bugzilla fits |
7 |
those criteria as well. |
8 |
|
9 |
> The problem for EAPI 3 was that feature requests |
10 |
> were on a google spreadsheet, and on bugzilla, and on a pms draft |
11 |
> branch, and on a text file in various people's devspaces. |
12 |
|
13 |
Agreed. |
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 |
* "can do this now" requests are added to a tracker bug for the upcoming |
22 |
EAPI. |
23 |
|
24 |
> * We get rough diffs for PMS for everything in the "can do this now" |
25 |
> category, and give them all an arbitrary codename that in no way |
26 |
> describes the feature (so that certain people can't vote and discuss |
27 |
> things based upon what they think the feature is without bothering to |
28 |
> find out if it's anything to do with what they assume). |
29 |
> |
30 |
> * Based upon developer feedback, the Council rates each of those |
31 |
> codenames as "yes", "no", "whatever" or "needs more discussion". For |
32 |
> those that need discussion, the people who voted for discussion |
33 |
> explain what they think needs discussing, and we sort that out. |
34 |
> |
35 |
> * The PMS people come up with exact wording for things that are mostly |
36 |
> "yes". |
37 |
> |
38 |
> * The Council votes for final approval, pending Portage implementation. |
39 |
|
40 |
Looks good so far. |
41 |
|
42 |
> * Portage implements it in ~arch. People start using it in ~arch. |
43 |
|
44 |
I'd propose: Portage implements it in ~arch. People can start using it |
45 |
in overlays. |
46 |
|
47 |
> * Portage goes stable. People are allowed to start using it in stable |
48 |
> for things that aren't deps of anything super-critical. |
49 |
|
50 |
I'd propose: Portage goes stable. 4 Weeks thereafter people are allowed |
51 |
to start using it for things that aren't deps of anything |
52 |
super-critical. |
53 |
|
54 |
> What we don't need is lots of people running around doing their own |
55 |
> thing in different places. What we do need is for a single |
56 |
> waterflow-like workflow with a good way of coordinating it that doesn't |
57 |
> rely upon the PMS team chasing everyone up and trying to keep track of |
58 |
> everything. |
59 |
|
60 |
ack. |
61 |
|
62 |
Tobias |