The one concern I have with the way the last commitfest went (and I say this as strictly an observer), there was no "discussion" on anything.
Now, I know that "discussion" happened, but it happened somewhere, in some web-forum, in a community that seems to generally promote mailing lists as the preferred method of "discussion". As an observer, who generally doesn't have much input "code wise", but occasionally might have an observation as a user, *I* would love to see the "commitfest patch-queue" be something pretty "simple", along the lines of a big list of: 1) item name, submission date, author 2a) item intention (maybe a see $MSGID) 2b) item (see $MSGID) 3) status summary (in discussion, applied, needs $improvements, rejected, see $MSGID" Note I said "item" because it appears as if the consensus is that the commit-fest has to deal with more than just patches, but also proposals, and "fork-in-the-road" details. And no, I don't think it should included the 2K emails. It should can the $N "items" needing to be dealt with, and a list of pointers to messages (which generally lead to threads), with a simple status list/summary for each one (again with pointers to $MSGID where specific information might be needed). Basically, I would like to see the "patch queue" be more a summary/pointer of/to discussion, then some web forum where the discussion happens. And I would like the "mailling lists" be where the discussion of items in the patch queue happens. But all this is the opinion of an observing devellopper, not involved in any of the heavy-lifting, but as someone who would like to keep an eye on what patches are presented, and their strengths/deficiencies, so that when I present my first patch/proposal, hopefully I can avoid most of the pitfalls. But don't cater to me. Cater to Tom and Bruce, who are the ones who actually use whatever is in place. Since they are the ones doing the work, I have to accept (or ignore) whatever system they use. a. * Bruce Momjian <[EMAIL PROTECTED]> [080402 19:36]: > It is not clear to me how a wiki can be easily created for 2k emails and > then maintained in a reasonable way, or how emails can be added to it > easily. > > There are several steps: > > o getting those 2k emails to start the commit fest > o getting them into a wiki in a way that is fast/efficient > o updating the wiki for changes efficiently > > Keep in mind the patch emails are pretty dynamic. As you get closer to > the end of the commit fest, the wiki is easier because the list of open > items becomes more stable. > > I am able to give others the ability to add, move, and delete emails in > my patch queue, if desired. > > If people want to use the wiki, go ahead --- this would be one less job > for me to do. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature