Neal Norwitz schrieb:
Is there an easy to fix this sort of problem so it doesn't happen in
the future (other than revoke my checkin privileges :-) ?
Sure: Don't make changes after a release candidate. That files are
missing can only be detected by actually producing the installer and
testing whether it works; the closer the release, the less testing
recent changes get.
It might be possible to improve msi.py to better guess what files
are test files, but I'd rather package too little than too much.
One thing it *should* do is to report files that it skipped - but
that really just helps me, since you have to run msi.py to see
these messages.
There are already so many things to remember for changes. If we can
automate finding these sorts of problems (installation, fixing
something for one platform, but not another, etc), the submitter can
fix these things with a little prodding from the buildbots. Or is
this too minor to worry about?
This specific instance is not to worry about. I noticed before making
the release, and fixed it; me changing the branch while it is frozen
is not even a policy violation. It's unfortunate that you can't
recreate the installer from the tag that had been made, but it's just
a release candidate, so that's a really minor issue.
It would also be great if we could automate complaint emails about
missing NEWS entries, doc, and tests so I wouldn't have to do it. :-)
Unless anyone has better ideas how to improve Python.
I don't think this can be automated in a reasonable way. People
apparently have different views on what is good policy and what
is overkill; in a free software project, you can only have so
much policy enforcement. If there is a wide consensus on some
issue, committers will pick up the consensus; if they don't,
it typically means they disagree.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
