On 02:39 am, firstname.lastname@example.org wrote:
I'm disappointed in the process -- it's as if nobody really reviewed the API until it was released with rc1, and this despite there being a significant discussion about its inclusion and alternatives months ago. (Don't look at me -- I wouldn't recognize a netmask if it bit me in the behind, and I can honestly say that I don't know whether /8 means to look only at the first 8 bits or whether it means to mask off the last 8 bits.)
I hope we can learn from this.
As he pointed out to Martin, Jean-Paul voiced objections several months ago which are similar to the ones which are now being discussed. To be fair, he didn't unambiguously say "... and therefore don't include this library"; he simply suggested that netaddr was superior in some ways and that perhaps some documentation could illuminate why ipaddr was better.
I've been frustrated with similar aspects of Python's development process in the past. The biggest problem I can see is that it's too hard to follow the discussion, and catch oneself up on the discussion thus far.
It's also difficult to refer back to posts much earlier in the history of an email discussion, and that frequently needs to be done when someone jumps into the middle of a discussion.
The way Twisted dealt with this particular issue was to move *all* discussions relevant to a particular feature into the ticket for that feature. If discussion starts up on the mailing list, within a few messages of it starting, someone on the dev team will pipe up and say "Hey, here's the ticket for this, could you add a link to this discussion and a summary".
Once on a ticket, the phraseology and typesetting used by our core team has reached a very precise consensus. Like the feature? "Merge this patch" or "Land this branch". Don't like it? "Thanks for your patch, but:", followed by a list of enumerated feedback. The required reactions to such feedback are equally well understood. Even if a comment isn't a full, formal code review, it still follows a similar style.
This system is possibly too simplistic for the more wide-ranging development of Python; although Twisted has its share of enthusiastic discussions, there is rarely the level of controversy I see here on python-dev, so I can't recommend it as such. I can say that keeping ticket discussions on tickets is generally a good idea, though, especially in a system like roundup or trac where it's easy to say "see message 7" rather than repeating yourself.
It seems that there is a habit of occasionally using ASF-style +1/+0/-0/-1 markers, but it's inconsistently applied. More importantly, nobody ever actually adds them up, so it's not entirely clear when they should be used.
To go back to JP's original comments though: what was the right thing for him to do, back in January, when he had these concerns? Should he have said "I am therefore -1 on this inclusion"? Should he have been discussing this on the mailing list rather than the tracker? Should he have kept coming back to the ticket and answering every single message reinforcing his original conclusions? I honestly don't think it's very clear what one is "officially" supposed to do. Without a clear expectation that one should say "No" to features that are problematic, it seems gratuitously mean to do so; so, it's nicer to just say "here's what I found" with the hopes that someone will evaluate that feedback.
Unfortunately it seems like the winning strategy here is just to keep flogging a dead horse until it's a dead horse hamburger; reply and reply and reply until everybody gets sick of talking about it. Repeat your original points in every post so that nobody will miss them. I think everyone is ill-served by this discussion format. Certainly when I voice my own objections or support for something, I'd like to just stop by, add a note for the committers to take into account when considering the issue, and then go away.
So, here are my recommendations:
1. Use the tracker for discussing tickets, so that it's easy to refer back to a previous point in the discussion, and so that people working on those tickets can easily find your commentary. 2. Use the mailing list for drawing attention to these discussions if they are of general interest, especially if the discussion is time- critical. In this case, an announcement "You have six weeks to review ipaddr now until its inclusion is permanent, anyone interested please look at issue 3959." 3. If you have an opinion, put your +1/+0/-0/-1 on a line by itself at the top of your message, so that it's easy for newcomers to the discussion to get a general feel.
Of course, this won't prevent all meandering discussions, or discussions that are too late to the party, but I do think it will help.
However, I think before everyone just starts doing this, even *more* important is my meta-suggestion: let's agree on how and when feedback is useful, and when it will be considered, so that it's not just a contest to overflow Guido's inbox. The opinion of the committers who will be considering feedback is much more important than mine :).