On Tue, Sep 17, 2013 at 12:04:04PM +0200, Jan-Wijbrand Kolman wrote:
I wonder if there is a formal or informal write-up of how to "nicely" contribute code to the repositories under the zopefoundation umbrella.
I don't think so. I'd like to see one.
Back in the subversion days I would branch a project, amend code, write tests, commit this to the repository, ask for feedback on the list, and, when deemed acceptable, merge my changes back to the project's trunk, perhaps even make a release of the project.
Yesterday I wanted to add a small feature to zope.formlib and wondered whether I should:
1) clone the "canonical" zope.formlib repository, make a branch, do my work, push the changes, ask for feedback on the list and eventually merge the branch to the mainline.
or
2) fork the repository, make a branch in the fork, do my work, push the changes to my fork, and issue a pull request.
The latter is what I did, without explicitly asking for feedback. Luckily someone did give me feedback (thanks!) :-)
I think a pull request is right. It doesn't matter much if the branch you're asking to pull is in the main repository or in a private fork.
Now that I mended the pull request, should I merge the pull request myself? Or is the current etiquette that someone else should merge the pull request?
I think it's fine to merge own pull requests, provided that somebody +1'd it. (Or if nobody cared for a couple of weeks, even after asking for feedback on the list.)
My apologies in case I missed an obvious document or reference somewhere that describes the way "we" should work with the zopefoundation's codebase...
Can we please get the http://foundation.zope.org/ website source on GitHub, so it becomes maintainable by the community? Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development