On 6 Apr 2004, at 17:13, Kip Hampton wrote:
[1] http://totalcinema.com/axkit/axkitguidelines.xml
I think this document hits the mark, and I'm +1 on moving forward with becoming a TLP and adopting this new development approach. I've gone over this document twice now and have nothing to add to it at this point.
Of course we'll need a pumpking. I'm not saying I won't do it, but given my recent activity (rather - lack of) on AxKit I doubt many people would ask me to take up the role. But if it turns out to be a hot potato I'd be happy to pick it up as it's easier to arrange meetings and shout at people than it is to pick up the codebase again.
Some important things to note about the Pumpking is that he/she is selected 1) only for a given minor version (1.7 through 1.7.n) and 2) based on the approval of their proposed release plan.
Here's how I see that working (ideally):
Wishlist/feature items get added to the STATUS file, voting happens as-needed.
Chris Commiter really want to see FeatureX happen, so s/he picks it, and a few other items from the STATUS and makes a Release Plan.
Chris' RP is selected or rejected by a vote. If selected, Chris becomes Pumpking for the next set of subversion releases. Those releases contain *only* the items from the RP + fixes for any bugs that pop up during his/her tenure.
Chris reports progress to the AxKit PMC at the (newly instituted) bi-weekly dev meetings.
When the items on Chris' RP are knocked down and released, the process starts over.
The benefits I'd hope to see from this are:
* Democratic fairness. Since RPs are accepted by vote (based on STATUS file items that will also have been voted in) everybody gets their itch scratched sooner or later.
* Faster release cycles. If a developer's pet features aren't in the current RP, they still have a reason to help implement the current items, so that the next RP goings that *does* have their pet features will come up sooner.
* Better communication. Everyone on the dev team knows where we are at, and users get to know what to expect from the next release (and roughly when to expect it).
* No single committer get saddled with the Pumpking duties. Committers are more likely to step up and take on a leadership role if they know that there is a there is a clear end in sight and they don't have to worry about biting off more than they can chew in terms of time/energy comitment.
A Couple of questions still stick out in my mind (none of which are probably showstoppers, but we should talk about them):
1) What happens if the current Pumpking can't or won't fulfil their duties?
2) Is charging a Pumpking with ownership of a full set of subversion releases *still* too much? Should we do new RPs for each microversion instead? Maybe a "keep releasing until all items on the RP are completed, regardless of version numbers" approach would work better?
In any case, it looks like we have a general consensus w.r.t. to that project guidelines doc and we should probably push forward with the TLP proposal (if you have thoughts to the contrary, speak up now).
Cheers, -kip
