[Python-Dev] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
glyph at divmod.com
glyph at divmod.com
Wed Jun 3 19:41:51 CEST 2009
On 02:39 am, guido at python.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
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
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 :).
More information about the Python-Dev