Re: [Zope-dev] Zope 4 release management
On Feb 1, 2012, at 00:05 , Alex Clark wrote: Bottom line: Zope stands to benefit greatly if the current active developers keep an open mind about how/where/when development of Zope software should occur. There are plenty of people that still think Zope software is cool, and plenty of skilled developers on github that could potentially help move it forward. This discussion seems to unnecessarily combine at least two distinct issues: - what RCS software to use - where to host it It may be easier if we disentangled them. Speaking purely as a developer, I'm leaning to Git when it comes to the RCS software decision between Subversion and Git. But I can use both equally well. Where it is hosted, well, purely as a developer it doesn't matter to me, unless I need to give up too much personal data to get access. From the perspective as a Zope Foundation member the RCS software decision is a technical detail that doesn't matter much. I'm more concerned with the where question, though. The Zope Foundation is tasked with safeguarding the software released under the Zope Foundation umbrella, and it is tasked with enforcing the contributor agreements everyone signed. Commits can only be made by signed contributors, and contributors are specifically disallowed to take outside code they don't own and commit it to the repository. We already have the technical infrastructure in place for most of this, such as ZF-controlled logins on svn.zope.org, access only via SSH key, etc. Our current where can be fully trusted, so to speak, and the people tasked with maintaining this infrastructure are known, accountable, and part of the foundation. My third role is secretary of the Zope Foundation Board of Directors and in that role I collect and maintain contributor applications and the (private) data associated with it. I can vouch that our current means of storing this data is reasonably secure. I can't make that assertion if the data is stored somewhere out of Zope Foundation control. My last role is admin for the ZF infrastructure and servers. In that role I would be involved in executing any changes in repository hosting. If only the RCS software changes that's a chunk of work, but doable. Git service can be added to the ZF infrastructure and packages can be migrated into Git repositories, probably on a as-needed basis. Most of the current authentication and safety infrastructure could stay in place. On balance and taking all my roles into account, sticking with SVN and the current hosting is the most attractive option. Moving to Git in the current hosting environment is doable, it means work, but I feel I've done my job keeping the software, access to it, and contributor data as secure as possible. Any option that involves moving to a different host altogether not only makes me feel I haven't done my job, it may also throw up legal questions. jens signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Zope 4 release management
On 2/1/12 6:08 AM, Jens Vagelpohl wrote: On Feb 1, 2012, at 00:05 , Alex Clark wrote: Bottom line: Zope stands to benefit greatly if the current active developers keep an open mind about how/where/when development of Zope software should occur. There are plenty of people that still think Zope software is cool, and plenty of skilled developers on github that could potentially help move it forward. This discussion seems to unnecessarily combine at least two distinct issues: - what RCS software to use - where to host it It may be easier if we disentangled them. Traditionally it was easier, but now-a-days with github and bitbucket they are harder to disentangle. Speaking purely as a developer, I'm leaning to Git when it comes to the RCS software decision between Subversion and Git. But I can use both equally well. Where it is hosted, well, purely as a developer it doesn't matter to me, unless I need to give up too much personal data to get access. From the perspective as a Zope Foundation member the RCS software decision is a technical detail that doesn't matter much. I'm more concerned with the where question, though. The Zope Foundation is tasked with safeguarding the software released under the Zope Foundation umbrella, and it is tasked with enforcing the contributor agreements everyone signed. Commits can only be made by signed contributors, and contributors are specifically disallowed to take outside code they don't own and commit it to the repository. We already have the technical infrastructure in place for most of this, such as ZF-controlled logins on svn.zope.org, access only via SSH key, etc. Our current where can be fully trusted, so to speak, and the people tasked with maintaining this infrastructure are known, accountable, and part of the foundation. My third role is secretary of the Zope Foundation Board of Directors and in that role I collect and maintain contributor applications and the (private) data associated with it. I can vouch that our current means of storing this data is reasonably secure. I can't make that assertion if the data is stored somewhere out of Zope Foundation control. My last role is admin for the ZF infrastructure and servers. In that role I would be involved in executing any changes in repository hosting. If only the RCS software changes that's a chunk of work, but doable. Git service can be added to the ZF infrastructure and packages can be migrated into Git repositories, probably on a as-needed basis. Most of the current authentication and safety infrastructure could stay in place. On balance and taking all my roles into account, sticking with SVN and the current hosting is the most attractive option. Moving to Git in the current hosting environment is doable, it means work, but I feel I've done my job keeping the software, access to it, and contributor data as secure as possible. Any option that involves moving to a different host altogether not only makes me feel I haven't done my job, it may also throw up legal questions. Fair enough, all of this sounds reasonable. My only point was that it should be someone's role in the ZF to take a look around at the available options in today's software development ecosystem. If github.com is attractive to you, great. If it's not and you are happy with the status quo, also fine. But like anything else, there are pros and cons associated with either approach. E.g. Plone's move to github has been a challenge for a lot of people, and we continue to struggle with it everyday; but I know it was the right move for the software and the project so I feel good about what we are doing. Alex jens ___ 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 ) -- Alex Clark · http://pythonpackages.com ___ 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] Zope 4 release management
On Wed, Feb 1, 2012 at 13:03, Alex Clark acl...@aclark.net wrote: - what RCS software to use - where to host it It may be easier if we disentangled them. Traditionally it was easier, but now-a-days with github and bitbucket they are harder to disentangle. It is entangled, but it is important to notice that they are separate concerns. I do think the big issue is where to host it. Yes, fine, people have opinions on git vs svn vs hg, etc. But that boils down to 25% technical arguments, 25% what you are used to 25% what everyone else uses and then 30% religion to make sure the bucket overflows. But where to host it is a tricky issue. Ownership and control is one big argument for having our own servers. Githubs forking/merging process a big argument for going to github. Should you then decide that github is the place to host it, well, then git is the software to use. To be honest I see little point in just setting up our own git repository. Yeah, maybe git is better from some technical standpoints, but it's also harder to use, and the question then becomes just religion. What we would like to do, of course, is to have a self-hosted github. :-) (And that exists. Buuut... it costs $250 per commiter and year, so that's not an option, obviously.) //Lennart ___ 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] Zope 4 release management
On 2/1/12 8:21 AM, Lennart Regebro wrote: On Wed, Feb 1, 2012 at 13:03, Alex Clarkacl...@aclark.net wrote: - what RCS software to use - where to host it It may be easier if we disentangled them. Traditionally it was easier, but now-a-days with github and bitbucket they are harder to disentangle. It is entangled, but it is important to notice that they are separate concerns. I do think the big issue is where to host it. Yes, fine, people have opinions on git vs svn vs hg, etc. But that boils down to 25% technical arguments, 25% what you are used to 25% what everyone else uses and then 30% religion to make sure the bucket overflows. But where to host it is a tricky issue. Ownership and control is one big argument for having our own servers. Githubs forking/merging process a big argument for going to github. Should you then decide that github is the place to host it, well, then git is the software to use. Actually, they introduced improved Subversion client support late last year: - https://github.com/blog/966-improved-subversion-client-support (they've supported import-from-svn and limited svn client support for longer) To be honest I see little point in just setting up our own git repository. Yeah, maybe git is better from some technical standpoints, but it's also harder to use, and the question then becomes just religion. What we would like to do, of course, is to have a self-hosted github. :-) (And that exists. Buuut... it costs $250 per commiter and year, so that's not an option, obviously.) //Lennart ___ 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 ) -- Alex Clark · http://pythonpackages.com ___ 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] Zope 4 release management
On 02/01/2012 02:29 PM, Alex Clark wrote: Actually, they introduced improved Subversion client support late last year: - https://github.com/blog/966-improved-subversion-client-support Unfortunately it is too unstable to be usable. Wichert. ___ 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] Zope 4 release management
On Wed, Feb 01, 2012 at 02:21:32PM +0100, Lennart Regebro wrote: What we would like to do, of course, is to have a self-hosted github. :-) (And that exists. Buuut... it costs $250 per commiter and year, so that's not an option, obviously.) Just to be sure I keep the fire on: what about self-hosted Gitorious? It's not as neat as Github, but you still have the same (similar) forking/merging abilities than Github. Jonathan ___ 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] Zope 4 release management
Le 01/02/2012 14:21, Lennart Regebro a écrit : I do think the big issue is where to host it. Yes, fine, people have opinions on git vs svn vs hg, etc. But that boils down to 25% technical arguments, 25% what you are used to 25% what everyone else uses and then 30% religion to make sure the bucket overflows. Disclaimer : Though I use zope libs every day, I'm not a comitter nor member of foundation. I'm a bit amazed by this argumentation. I think one important thing is that subversion is centralized while dvcs are not. With dvcs everyone got full history of zope libs. I personally find it a big pro for a free software. More over with dvcs someone may fork a product on his side (a branch of his own, not on a zope server) and make it evolve, still having ability to merge updates (and auto merge in dvcs are superior to the one found in subversion). All I see here is usability not religion ;-) Now about github, I may say that gitorious.org exists and is free-software and gitosis + gitweb are on most linux distribs and offers same features as today's zope svn. I think the same can be said for hg. But really github/bitbucket is just hosting, it's not like subversion, you got all your data and history at home also, so you can leave github as soon as you want (if you do not use other features). Finally, moving a subversion repo to git is really easy (and I think it's the same with hg) Hope this helps. Alex -- Alexandre Garel 06 78 33 15 37 ___ 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] Zope 4 release management
Am 01.02.2012, 15:40 Uhr, schrieb Alexandre Garel alex.ga...@tarentis.com: All I see here is usability not religion Which is pretty much what Jens said originally. To me, much of the argument seems to be trying to solve a different problem: getting more people involved in contributing to Zope or at least maintaining important packages. While this is a laudable goal I think it is has little to do with the tools involved, something that is becomingly increasingly irrelevant as more and more third-party packages are used in Zope projects; something which Zope did a great deal to encourage. Currently the hurdle to getting involved is signing and sending the committer agreement. A hurdle which I think is worth keeping. On hosting: personally, it does matter to me a great deal where the little code I write is hosted. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] zope-tests - FAILED: 27, OK: 40
Am 01.02.2012 um 02:00 schrieb Zope tests summarizer: [...] [1]FAILED ZTK 1.0 / Python2.4.6 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/057143.html [2]FAILED ZTK 1.0 / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/057145.html [3]FAILED ZTK 1.0dev / Python2.4.6 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/057153.html [4]FAILED ZTK 1.0dev / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/057155.html [5]FAILED ZTK 1.1 / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/057141.html [6]FAILED ZTK 1.1dev / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/057152.html [7]FAILED Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/057171.html [8]FAILED Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/057165.html [9]FAILED Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/057173.html [10] FAILED Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/057169.html [11] FAILED Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/057175.html [12] FAILED Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/057172.html [13] FAILED Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/057178.html [14] FAILED Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/057174.html [15] FAILED Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/057181.html [16] FAILED Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/057176.html [17] FAILED Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/057185.html [18] FAILED Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/057177.html [19] FAILED Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/057188.html [20] FAILED Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/057180.html [22] FAILED winbot / ztk_10 py_254_win32 https://mail.zope.org/pipermail/zope-tests/2012-January/057195.html [23] FAILED winbot / ztk_11 py_254_win32 https://mail.zope.org/pipermail/zope-tests/2012-January/057198.html I fixed the test failure in zope.error, cut a new release and updated all ZTK versions. So these test failures should be gone by tomorrow. [21] FAILED winbot / zope.testing_py_265_32 https://mail.zope.org/pipermail/zope-tests/2012-January/057146.html [24] FAILED winbot / ztk_dev py_265_win32 https://mail.zope.org/pipermail/zope-tests/2012-January/057191.html [25] FAILED winbot / ztk_dev py_265_win64 https://mail.zope.org/pipermail/zope-tests/2012-January/057192.html [26] FAILED winbot / ztk_dev py_270_win32 https://mail.zope.org/pipermail/zope-tests/2012-January/057193.html [27] FAILED winbot / ztk_dev py_270_win64 https://mail.zope.org/pipermail/zope-tests/2012-January/057194.html There seems to be a problem in zope.testing 4.1.0 on Windows. I cannot repoduce this error on Mac OS X: File c:\buildslave\ztk_dev_py_270_win32\build\src\zope.testing\src\zope\testing\wait.txt, line 152, in wait.txt Failed example: @wait(timeout=0) def _(state=[]): if len(state) 1: return True state.append(0) Expected: Traceback (most recent call last): ... ValueError: _ Got: mynow mysleep 0.0001 mynow mysleep 0.0001 Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · Forsterstraße 29 · 06112 Halle (Saale) · Germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting, operations ___ 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] Zope 4 release management
On 1 February 2012 14:35, Jonathan Ballet j...@multani.info wrote: On Wed, Feb 01, 2012 at 02:21:32PM +0100, Lennart Regebro wrote: What we would like to do, of course, is to have a self-hosted github. :-) (And that exists. Buuut... it costs $250 per commiter and year, so that's not an option, obviously.) Just to be sure I keep the fire on: what about self-hosted Gitorious? It's not as neat as Github, but you still have the same (similar) forking/merging abilities than Github. From me, the key advantage of Github is the functionality to easily discuss code in pull requests and the one-click merging where appropriate. It takes me much less effort to respond to a Github pull request where I have all the relevant information to hand than an email with a patch or a request to take a look at a branch in subversion. For projects I work on in my own time that often makes the difference when it comes to responding in a timely manner. Github certainly has it's problems too, but it has an api for scripting which makes it possible to send better commit emails or integrate with Launchpad for bug tracking if someone wants to put the effort in. I don't really have an opinion on whether Github or a repository hosted on a zope.org server is nominated as the ZF's canonical repository (presumably with a pre-receive hook that checks all commit authors are known to have signed the contributor agreement.) With DVCS it shouldn't really matter. It's access to improved tools that's important for me. Laurence ___ 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] Zope 4 release management
On Feb 1, 2012, at 15:53 , Charlie Clark wrote: Currently the hurdle to getting involved is signing and sending the committer agreement. A hurdle which I think is worth keeping. For any code released under the Zope Foundation umbrella that hurdle cannot be removed, anyway. To be frank, I don't even think that's a hurdle. And it helps to remind the signer that there are legal requirements and responsibilities involved. jens signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Zope 4 ZMI sprint report
On 26 January 2012 04:29, Christopher Lozinski lozin...@freerecruiting.com wrote: Thank you for the sprint report. I think it is great that you are working on upgrading the ZMI. I am also turning my attention to this problem. Clearly ZMI needs an upgrade. I need an upgraded ZMI. Today I fired up my old version of ZAM. I can give you a password and url if you want to see what it looks like. My understanding is that it is a well thought out upgrade for the ZMI. Properly done with page templates, not dtml, and pluggable. It certainly looks nice. Of course it has copy, cut, delete, rename, but no create. I also did a reinstall of the ZAM demo, but it broke. Am I doing the wrong thing working on ZAM? Is that consistent with the direction others are taking on upgrading the ZMI, or should I be putting my energy elsewhere? If I am doing the right thing working on ZAM, perhaps the first thing I should do is get the install working again correctly. For that I have to get svn access from the Zope foundation. I presume Larry Rowe is the release manager for Zope 4, so he is the person who signs off on the upgrades to ZAM? Do I understand the process correctly? Is ZAM part of Zope 4? Is it the basis of the new ZMI, or is something else the new ZMI? I think building a better ZMI will be important in the long run though I'm not sure it should land in Zope 4 itself as I think it could be too big a step for that release. I wasn't able to get zam.demo (svn trunk) to run, so I don't have an opinion on ZAM itself at the moment. Note that Zope 4 is based on Zope 2 rather than BlueBream so I don't know how much of the existing work would still be applicable. I can volunteer some time towards guiding the Zope 4 release process, though it may be appropriate to find someone more comfortable with the existing svn/email/launchpad toolchain to be release manager if the consensus is to stay with that. Laurence ___ 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] Announcement: 2012 Zope Foundation Board Elections and General Meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (Apologies in advance for the cross-post: we need this to reach the whole Zope community). The Zope Foundation board is pleased to announce the regular 2012 general meeting of the foundation will be held on Friday, 16 March 2012, at 15:00 UTC. The meeting will be conducted via IRC at the following channel: irc://irc.freenode.net/#zope-foundation Prior to that meeting, the current board will conduct an elections in which foundation members will select seven (7) board members in accordance with the foundation bylaws[1]. Summary - --- - - Nominations open via the foundat...@zope.org mailing list until Friday, 2012-02-10. - - Voting via e-mail to a closed mailing list, from Wednesday, 2012-02-15 through Friday, 2012-03-02. - - Votes tallied by representatives of the current board, using Meek and Warrent STV method using OpenSTV software. - - General meeting and seating of the new board, Friday, 2012-03-16. Procedure for Elections - --- The procedure for the elections is as follows: - - Foundation members may nominate any member by responding to the board's announcment on the foundat...@zope.org maling list. Nominations will remain open until Friday, 2012-02-10, 23:00 UTC. - - At the close of the nominations period, the board will create a new mailman list, 'zf-elections-2012', and approve all ZF members to post to the list. In order to preserve anonymity of votes, foundation members will not be subscribers to the list; access to the list archives will be restricted to the tellers appointed by the board. - - On Wednesday, 2012-02-15, the Secretary will send an e-mail announcing the opening of the voting period. This email will contain the ballot, with careful instructions about how to rank preferences in the reply. The Reply-to header of this e-mail will be set to the 'zf-elections-2012' list. - - ZF members will vote by replying to that e-mail. Voting will remain open until Friday, 2012-03-02, 23:00 UTC. - - At the close of voting, the board will appoint two of its members as tellers. The tellers will use the list archive to tabulate the members' votes, using the OpenSTV application[2] configured to use the Meek and Warren STV method[3]. The tellers will report the election results, along with the raw tallies, at a special board meeting to be held on Tuesday, 2012-03-13, 15:00 UTC. - - After canvassing the results from the tellers, the board will notify all nominees of the success / failure of their candidacy, thanking them for their willingness to serve. - - At the general meeting, the last item on the agenda will the announcement of the election results, including a vote to seat the board. An online version of this announcement is available at: http://foundation.zope.org/news/2012_election_and_general_meeting References - -- [1] http://foundation.zope.org/bylaws/zope_foundation_bylaws.pdf [2] http://stv.sourceforge.net/aboutopenstv [3] http://stv.sourceforge.net/votingmethods/meek Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8psnAACgkQ+gerLs4ltQ6l+ACglK1iWt6eq0z52Zojiq9n0id2 weoAnRs57WAoLtDLqyaBM/YdzkEMQ5Bv =1oDS -END PGP 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] zope-tests - FAILED: 27, OK: 40
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/01/2012 09:57 AM, Michael Howitz wrote: Am 01.02.2012 um 02:00 schrieb Zope tests summarizer: [...] [1]FAILED ZTK 1.0 / Python2.4.6 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/057143.html [2]FAILED ZTK 1.0 / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/057145.html [3]FAILED ZTK 1.0dev / Python2.4.6 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/057153.html [4]FAILED ZTK 1.0dev / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/057155.html [5]FAILED ZTK 1.1 / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/057141.html [6]FAILED ZTK 1.1dev / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-January/057152.html [7]FAILED Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/057171.html [8]FAILED Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/057165.html [9]FAILED Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/057173.html [10] FAILED Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/057169.html [11] FAILED Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/057175.html [12] FAILED Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/057172.html [13] FAILED Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/057178.html [14] FAILED Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/057174.html [15] FAILED Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/057181.html [16] FAILED Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/057176.html [17] FAILED Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/057185.html [18] FAILED Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/057177.html [19] FAILED Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-January/057188.html [20] FAILED Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-January/057180.html [22] FAILED winbot / ztk_10 py_254_win32 https://mail.zope.org/pipermail/zope-tests/2012-January/057195.html [23] FAILED winbot / ztk_11 py_254_win32 https://mail.zope.org/pipermail/zope-tests/2012-January/057198.html I fixed the test failure in zope.error, cut a new release and updated all ZTK versions. So these test failures should be gone by tomorrow. Thank you for that effort! [21] FAILED winbot / zope.testing_py_265_32 https://mail.zope.org/pipermail/zope-tests/2012-January/057146.html [24] FAILED winbot / ztk_dev py_265_win32 https://mail.zope.org/pipermail/zope-tests/2012-January/057191.html [25] FAILED winbot / ztk_dev py_265_win64 https://mail.zope.org/pipermail/zope-tests/2012-January/057192.html [26] FAILED winbot / ztk_dev py_270_win32 https://mail.zope.org/pipermail/zope-tests/2012-January/057193.html [27] FAILED winbot / ztk_dev py_270_win64 https://mail.zope.org/pipermail/zope-tests/2012-January/057194.html There seems to be a problem in zope.testing 4.1.0 on Windows. I cannot repoduce this error on Mac OS X: File c:\buildslave\ztk_dev_py_270_win32\build\src\zope.testing\src\zope\testing\wait.txt, line 152, in wait.txt Failed example: @wait(timeout=0) def _(state=[]): if len(state) 1: return True state.append(0) Expected: Traceback (most recent call last): ... ValueError: _ Got: mynow mysleep 0.0001 mynow mysleep 0.00 Hmmm, Jim has recently made some changes in there -- maybe he has an idea about the test failure? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8pwS4ACgkQ+gerLs4ltQ4iggCgl8s5RJIsND7xcuc9wahnI0X2 tfcAn2gTv1f0hHYeg5aIJ1hkjqAmeDOO =z34D -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or
[Zope-dev] zope-tests - FAILED: 26, OK: 41
This is the summary for test reports received on the zope-tests list between 2012-01-31 00:00:00 UTC and 2012-02-01 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 [1]ZTK 1.0 / Python2.4.6 Linux 64bit [2]ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.7 Linux 64bit [3]ZTK 1.0dev / Python2.4.6 Linux 64bit [4]ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit [5]ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit [6]ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit [7]ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.6 slave-ubuntu32 Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.7 slave-ubuntu32 Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 Zope Buildbot / zope2.14-py2.6 slave-ubuntu32 Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 Zope Buildbot / zope2.14-py2.7 slave-ubuntu32 Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 [8]Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu32 [9]Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 [10] Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu32 [11] Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 [12] Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 [13] Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 [14] Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu32 [15] Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 [16] Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu32 [17] Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 [18] Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu32 [19] Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 [20] Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu32 [21] Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 [22] winbot / zope.testing_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 [23] winbot / ztk_dev py_265_win32 [24] winbot / ztk_dev py_265_win64 [25] winbot / ztk_dev py_270_win32 [26] winbot / ztk_dev py_270_win64 Non-OK results -- [1]FAILED ZTK 1.0 / Python2.4.6 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-February/057210.html [2]FAILED ZTK 1.0 / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-February/057212.html [3]FAILED ZTK 1.0dev / Python2.4.6 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-February/057220.html [4]FAILED ZTK 1.0dev / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-February/057222.html [5]FAILED ZTK 1.1 / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-February/057208.html [6]FAILED ZTK 1.1dev / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-February/057217.html [7]FAILED ZTK 1.1dev / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2012-February/057218.html [8]FAILED Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-February/057239.html [9]FAILED Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 https://mail.zope.org/pipermail/zope-tests/2012-February/057230.html [10] FAILED Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu32 https://mail.zope.org/pipermail/zope-tests/2012-February/057241.html [11] FAILED Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64
Re: [Zope-dev] Zope 4 release management
On Wed, 2012-02-01 at 16:29 +0100, Jens Vagelpohl wrote: On Feb 1, 2012, at 15:53 , Charlie Clark wrote: Currently the hurdle to getting involved is signing and sending the committer agreement. A hurdle which I think is worth keeping. For any code released under the Zope Foundation umbrella that hurdle cannot be removed, anyway. To be frank, I don't even think that's a hurdle. And it helps to remind the signer that there are legal requirements and responsibilities involved. For what it's worth, in the Pylons Project, we decided to continue requiring the signing of a contributor's agreement (more or less the same contributor agreement as Zope requires). But instead of signing via paper, we ask that folks sign the contributor agreement by adding their name and date to a CONTRIBUTORS.txt file in a git fork of each repository they wish to commit to (e.g. https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt). The CONTRIBUTORS.txt *is* the agreement, and the pull request serves as proof that they agree to the contribution terms it outlines. I'm not 100% confident that this will serve as watertight proof of agreement in a well-funded court challenge. But it's a lot easier on the contributor and on the organization. The contributor doesn't need to use a fax or lick a stamp and wait, and at least if they're checked in they're fairly durable and have lots of backups (it would be very impressive if the ZF would be able to produce all the paper contributor agreements that have been signed over the course of Zope's existence on demand). - C ___ 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] Zope 4 release management
Hi Chris, For what it's worth, in the Pylons Project, we decided to continue requiring the signing of a contributor's agreement (more or less the same contributor agreement as Zope requires). But instead of signing via paper, we ask that folks sign the contributor agreement by adding their name and date to a CONTRIBUTORS.txt file in a git fork of each repository they wish to commit to (e.g. https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt). The CONTRIBUTORS.txt *is* the agreement, and the pull request serves as proof that they agree to the contribution terms it outlines. I'm not 100% confident that this will serve as watertight proof of agreement in a well-funded court challenge. But it's a lot easier on the contributor and on the organization. The contributor doesn't need to use a fax or lick a stamp and wait, and at least if they're checked in they're fairly durable and have lots of backups (it would be very impressive if the ZF would be able to produce all the paper contributor agreements that have been signed over the course of Zope's existence on demand). Yes, I remember signing the Repoze repository agreement in a similar way a few years ago. I liked it because it was convenient, sure. But as you say, I doubt it would hold up in a court. Speaking of those paper contributor agreement availability, you'd be surprised. I have them all in 3 large binders, for every signer the latest agreement they signed. jens signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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 )
