| 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 |
Archives