[Zope-dev] github etiquette
Hi, I wonder if there is a formal or informal write-up of how to nicely contribute code to the repositories under the zopefoundation umbrella. 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!) :-) 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? My apologies in case I missed an obvious document or reference somewhere that describes the way we should work with the zopefoundation's codebase... kind regards, jw ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] github etiquette
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 signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] github etiquette
On 9/17/13 12:04 PM, Jan-Wijbrand Kolman wrote: snip 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!) :-) 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? This is what I did just now. Kind regards, jw ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] github etiquette
On 9/17/13 1:00 PM, Marius Gedminas wrote: 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. I think we're writing it Right Now :-) regards, jw ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] github etiquette
On Tue, Sep 17, 2013 at 7:00 AM, Marius Gedminas mar...@gedmin.as wrote: ... 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. Yup. It doesn't matter much if the branch you're asking to pull is in the main repository or in a private fork. Yup. (Apparently, number of forks is a way some people keep score on github, so I'll cynically say a fork is better.) 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.) I strongly prefer that the reviewer do the merge. I'd also really like reviewers to take their responsibility seriously, making comments and suggestions where appropriate. Software review, done well, improves the software, and, more importantly, improves the developers. 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? Oh yes, please! Unfortunately, this will require moving from silva to sphinx. It will also entail separating the public sites from private documents. (The above isn't meant to dis silva, it's just not a good fit for zopefoundation.org.) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] github etiquette
On 9/17/13 1:47 PM, Jim Fulton wrote: I strongly prefer that the reviewer do the merge. I'd also really like reviewers to take their responsibility seriously, making comments and suggestions where appropriate. Software review, done well, improves the software, and, more importantly, improves the developers. I agree - I know I get better from recieving feedback :-) Is this reviewer role something someone takes upon himself? I mean, if I see a pull request for a code base that I know, I could review the request? Or do we acknowledge a group of people that generally do reviews (again formally of informally, I don't mind, I'm not looking for official procedures)? In any case, a second pair of eyes before merging is very helpful! regards, jw p.s. Another thing I noticed: some of the discussion about changes and patches and fixes now shift from the mailinglist to github. This is fine, I guess. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] github etiquette
On Tue, Sep 17, 2013 at 07:47:42AM -0400, Jim Fulton wrote: On Tue, Sep 17, 2013 at 7:00 AM, Marius Gedminas mar...@gedmin.as wrote: 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.) I strongly prefer that the reviewer do the merge. FWIW the only reason I'm in favour of self-merges is that this short-circuits the have you signed the ZF committer agreement? dance. Only people who have can merge. I also feel silly when I ask this question from people with very familiar names. (I feel that I have to do when I don't see ZF membership on their GitHub profile.) I'd also really like reviewers to take their responsibility seriously, making comments and suggestions where appropriate. Oh, absolutely. Software review, done well, improves the software, and, more importantly, improves the developers. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] github etiquette
On Tue, Sep 17, 2013 at 8:32 AM, Jan-Wijbrand Kolman janwijbr...@gmail.com wrote: On 9/17/13 1:47 PM, Jim Fulton wrote: I strongly prefer that the reviewer do the merge. I'd also really like reviewers to take their responsibility seriously, making comments and suggestions where appropriate. Software review, done well, improves the software, and, more importantly, improves the developers. I agree - I know I get better from recieving feedback :-) Is this reviewer role something someone takes upon himself? I mean, if I see a pull request for a code base that I know, I could review the request? These are good questions. I probably don't have satisfying answers. The short answer is that I think people who contribute to a project should view review as one of their duties. For better or worse, this is somewhat informal. If you don't get a review in a timely manner, try posting to the appropriate mailing list to request a review. Or do we acknowledge a group of people that generally do reviews (again formally of informally, I don't mind, I'm not looking for official procedures)? No. p.s. Another thing I noticed: some of the discussion about changes and patches and fixes now shift from the mailinglist to github. This is fine, I guess. Yes, IMO. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] github etiquette
On Tue, Sep 17, 2013 at 8:58 AM, Marius Gedminas mar...@gedmin.as wrote: On Tue, Sep 17, 2013 at 07:47:42AM -0400, Jim Fulton wrote: On Tue, Sep 17, 2013 at 7:00 AM, Marius Gedminas mar...@gedmin.as wrote: 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.) I strongly prefer that the reviewer do the merge. FWIW the only reason I'm in favour of self-merges is that this short-circuits the have you signed the ZF committer agreement? dance. Only people who have can merge. Sorry, I don't understand the point you're making. I also feel silly when I ask this question from people with very familiar names. (I feel that I have to do when I don't see ZF membership on their GitHub profile.) So are you saying you don't merge other people's code because you don't want to ask if they're contributors? I can understand this, but I'd still try to encourage a more review-centric workflow. Also, if a change is trivial, the PR doesn't have to be from a contributor. I understand that triviality isn't always clear. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] github etiquette
On 9/17/13 3:32 PM, Jim Fulton wrote: On Tue, Sep 17, 2013 at 8:32 AM, Jan-Wijbrand Kolman Is this reviewer role something someone takes upon himself? I mean, if I see a pull request for a code base that I know, I could review the request? These are good questions. I probably don't have satisfying answers. The short answer is that I think people who contribute to a project should view review as one of their duties. For better or worse, this is somewhat informal. If you don't get a review in a timely manner, try posting to the appropriate mailing list to request a review. Works for me :-) regards, jw ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Misattribution of checkin emails
Certain Subversion commits show up on the checkins@ list misattributed to Marius Gedminas cvs-ad...@zope.org. Examples: r130062 - https://mail.zope.org/pipermail/checkins/2013-March/065903.html r130296 - https://mail.zope.org/pipermail/checkins/2013-August/067498.html r130309 - https://mail.zope.org/pipermail/checkins/2013-September/067596.html All of these were actually made by Gediminas Paulauskas (svn username 'menesis'). I've tried to raise this on the checkins@ list but received no response yet. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] github etiquette
On Tue, Sep 17, 2013 at 09:35:58AM -0400, Jim Fulton wrote: On Tue, Sep 17, 2013 at 8:58 AM, Marius Gedminas mar...@gedmin.as wrote: FWIW the only reason I'm in favour of self-merges is that this short-circuits the have you signed the ZF committer agreement? dance. Only people who have can merge. Sorry, I don't understand the point you're making. I'll try to explain better. I also feel silly when I ask this question from people with very familiar names. (I feel that I have to do when I don't see ZF membership on their GitHub profile.) So are you saying you don't merge other people's code because you don't want to ask if they're contributors? No. I'm saying the reviewer-merges workflow looks like this: 1. Somebody creates a pull request 2. A reviewer reviews 3. OP fixes 4. Reviewer asks have you signed the agreement? if not please sign 5. OP says he/she signed it 6. Reviewer trusts OP's word and merges (I don't have a good short word for somebody who created the pull request, so I abused Original Poster.) Whereas I'd prefer 1. Somebody creates a pull request 2. A reviewer reviews 3. OP fixes 4. Reviewer says looks good to me, feel free to merge (if you're not a committer already, see http://foundation.zope.org/agreements) 5. OP merges It's not a very strong preference. I can feel myself changing my mind already ;-) OTOH the implicit trust in step 6 makes me a bit uneasy, and I'm not quite sure how to verify the fact of the signing. Wait for the user to show up in https://github.com/zopefoundation?tab=members ? I can understand this, but I'd still try to encourage a more review-centric workflow. +1 Also, if a change is trivial, the PR doesn't have to be from a contributor. I understand that triviality isn't always clear. It's completely unclear to me, once the PR goes beyond typo fixes. :( Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope-tests - FAILED: 6, OK: 12
This is the summary for test reports received on the zope-tests list between 2013-09-16 00:00:00 UTC and 2013-09-17 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received Successful - zopetoolkit_trunk - Build # 405 winbot / ZODB_dev py_265_win32 [1]winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 [2]winbot / zope.app.authentication_py_265_32 [3]winbot / zope.app.http_py_265_32 [4]winbot / zope.app.publication_py_265_32 [5]winbot / zope.app.wsgi_py_265_32 [6]winbot / zope.testbrowser_py_265_32 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 Non-OK results -- [1]FAILED winbot / ZODB_dev py_265_win64 https://mail.zope.org/pipermail/zope-tests/2013-September/078789.html [2]FAILED winbot / zope.app.authentication_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-September/078794.html [3]FAILED winbot / zope.app.http_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-September/078795.html [4]FAILED winbot / zope.app.publication_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-September/078793.html [5]FAILED winbot / zope.app.wsgi_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-September/078796.html [6]FAILED winbot / zope.testbrowser_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-September/078797.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
