Ciaran McCreesh wrote: > Oh please no wiki. Whatever. My requirements are quite simple: public accessible, no accounts needed on 3rd party systems (like Google) to add feature requests or comments and changes must be traceable. Using bugzilla fits those criteria as well.
> 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. Agreed. > 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". * "can do this now" requests are added to a tracker bug for the upcoming EAPI. > * 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. Looks good so far. > * Portage implements it in ~arch. People start using it in ~arch. I'd propose: Portage implements it in ~arch. People can start using it in overlays. > * Portage goes stable. People are allowed to start using it in stable > for things that aren't deps of anything super-critical. I'd propose: Portage goes stable. 4 Weeks thereafter people are allowed to start using it 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. ack. Tobias
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
