[Python-Dev] patch metadata - to use or not to use?
Nick Coghlan
ncoghlan at gmail.com
Sat Nov 19 11:52:14 CET 2011
On Sat, Nov 19, 2011 at 6:42 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Hi,
>
> I recently got some patches accepted for inclusion in 3.3, and each time,
> the patch metadata (such as my name and my commit comment) were stripped by
> applying the patch manually, instead of hg importing it. This makes it clear
> in the history who eventually reviewed and applied the patch, but less
> visible who wrote it (except for the entry in Misc/NEWS).
>
> I didn't see this mentioned in the dev-guide. Is it being considered the
> Right Way To Do It?
Generally speaking, it's more useful for the checkin metadata to
reflect who actually did the checkin, since that's the most useful
information for the tracker and buildbot integration. The question of
did the original patch does matter in terms of giving appropriate
credit (which is covered by NEWS and the commit message), but who did
the checkin matters for immediate workflow reasons (i.e. who is
responsible for dealing with any buildbot breakage, objections on
python-dev, objections on the tracker, etc).
One of the key aspects of having push rights is that we're the ones
that take responsibility for the state of the central repo - if we
stuff it up and break the build (either because we missed something on
review, or due to cross-platform issues), that's *our* problem, not
usually something the original patch contributor needs to worry about.
We do have a guideline that says to always use the "--no-commit" flag
with "hg import" and then run the tests before committing, so that may
answer your question about whether or not it's an official policy.
(That said, I don't know if the devguide actually says that explicitly
anywhere - it's just reflected in the various workflow examples, as
well as in the mailing list discussions that helped craft those
examples)
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev
mailing list