[Python-Dev] Using patch mgr for peer review - sensible or chicken?

[Tim Peters]

[Jack Jansen]
> whenever I make a change to something essential, and something that
> I'm not sure I understand for the full 100%, I tend to not check the
> mods in directly but instead put a patch into the patch manager.

Good!  That's the way it's supposed to work.

> This has happened recently with a setup.py and a configure.in patch,
> for instance.  My idea was that whoever felt responsible for the file
> in question would see the patch email come by, have a look, and say
> "fine".

That part doesn't work:  you should assign it to whoever you think is best
qualified to judge the parts you're not sure about.  It won't necessarily
see action any quicker, but it feels good to have someone to blame <wink>.

> But whereas some patches get looked at quickly some can sit there for
> days (or in some cases even months).

Yup!  I imagine it's even worse for people we don't know well, who submit
odd patches nobody knows what to do with.

> This is a nuisance to me, as by the time someone looks at the patch
> my development version of the file has evolved again.

That went without saying, you know.

> Moreover, I get the impression that I'm the only person with checkin
> permissions that does this,

No, you're not.  "The rule" is that an expert in an area, with an
uncontroversial patch (and if they can't judge controversy in advance,
they're not expert in that area!), should just check something in.  Any
other case should go thru review.  For example, poor Martin hasn't had much
luck getting action from PythonLabs on some optimization patches, and I've
had to redo a UTF-16 patch from scratch (because it no longer applied) in
the 5 weeks I've been waiting for MAL to look at it (*told* you it felt good
to have someone to blame <wink>).

So everyone gets burned by this.  It's relatively rare for the
Python-Dev'ers, though, because by and large most of us stick to areas where
"I'm an expert, buzz off" applies.

> and that the rest of the developer community just checks stuff in and
> counts on it being (a) correct or (b) quickly fixed by someone else.

I *prefer* that approach when the only question is whether it will break
something on Windows.  I build Python every day anyway, so applying a patch
just to test Windows is just more work; it's easier to fix it myself than
apply a patch, explain what needs to change in the patch, then undo the
patch again.

> Am I too chicken

I forgot -- are you Dutch or German <wink>?

> and should I just check things in if I'm reasonably convinced that
> they're okay?

Depends on how sure you are.  If not "very", first assign your patch to
someone specific and give them a chance to disappoint you.