Re: [Zope-dev] [Checkins] SVN: zc.buildout/ Moved to github
Hi Alex, Please revert this checkin. You can't just take core software pieces from Zope Foundation-hosted repositories and move them somewhere else. Thanks! jens On Aug 18, 2012, at 3:09 , J. Alexander Clark <cvs-admin@zope.org> wrote:
Log message for revision 127519: Moved to github
Changed: A zc.buildout/README_MOVED_TO_GITHUB.txt D zc.buildout/trunk/
-=- Added: zc.buildout/README_MOVED_TO_GITHUB.txt =================================================================== --- zc.buildout/README_MOVED_TO_GITHUB.txt (rev 0) +++ zc.buildout/README_MOVED_TO_GITHUB.txt 2012-08-18 01:09:06 UTC (rev 127519) @@ -0,0 +1 @@ +https://github.com/buildout/buildout/tree/1.6.x
_______________________________________________ checkins mailing list checkins@zope.org https://mail.zope.org/mailman/listinfo/checkins
Please note that development of buildout 2 happens on github since April this year. The buildout developers decided to do the move after Jim suggested it. Legally you could see this move as a fork, but it was done by Jim and others. Alex just wanted to clarify the situation and also move the development of the stable branch into the same place. Hanno On 18.08.2012, at 09:49, Jens Vagelpohl <jens@dataflake.org> wrote:
Hi Alex,
Please revert this checkin. You can't just take core software pieces from Zope Foundation-hosted repositories and move them somewhere else.
Thanks!
jens
On Aug 18, 2012, at 3:09 , J. Alexander Clark <cvs-admin@zope.org> wrote:
Log message for revision 127519: Moved to github
Changed: A zc.buildout/README_MOVED_TO_GITHUB.txt D zc.buildout/trunk/
-=- Added: zc.buildout/README_MOVED_TO_GITHUB.txt =================================================================== --- zc.buildout/README_MOVED_TO_GITHUB.txt (rev 0) +++ zc.buildout/README_MOVED_TO_GITHUB.txt 2012-08-18 01:09:06 UTC (rev 127519) @@ -0,0 +1 @@ +https://github.com/buildout/buildout/tree/1.6.x
_______________________________________________ checkins mailing list checkins@zope.org https://mail.zope.org/mailman/listinfo/checkins
_______________________________________________ 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 )
Hi Hanno, Legally this must be a fork then and I'm not sure it can be released as official Zope Foundation software anymore if you make releases from GitHub. Reason: the ZF can no longer ascertain that only official ZF contributor agreement signers have modified code in the package, which is a core requirement for software released from Zope Foundation repositories/under Zope Foundation auspices. Apart from those legal points which are still not entirely clear, since this can only be a fork I would say that last checkin must still be reverted. Don't get me wrong, I'm not trying to be facetious, but until those legal questions are cleared up you should not make any checkins on svn.zope.org that basically "shut down" development of that package from there, such as deleting the trunk. jens On Aug 18, 2012, at 10:21 , Hanno Schlichting <hanno@hannosch.eu> wrote:
Please note that development of buildout 2 happens on github since April this year. The buildout developers decided to do the move after Jim suggested it.
Legally you could see this move as a fork, but it was done by Jim and others. Alex just wanted to clarify the situation and also move the development of the stable branch into the same place.
Hanno
On 18.08.2012, at 09:49, Jens Vagelpohl <jens@dataflake.org> wrote:
Hi Alex,
Please revert this checkin. You can't just take core software pieces from Zope Foundation-hosted repositories and move them somewhere else.
Thanks!
jens
On Aug 18, 2012, at 3:09 , J. Alexander Clark <cvs-admin@zope.org> wrote:
Log message for revision 127519: Moved to github
Changed: A zc.buildout/README_MOVED_TO_GITHUB.txt D zc.buildout/trunk/
-=- Added: zc.buildout/README_MOVED_TO_GITHUB.txt =================================================================== --- zc.buildout/README_MOVED_TO_GITHUB.txt (rev 0) +++ zc.buildout/README_MOVED_TO_GITHUB.txt 2012-08-18 01:09:06 UTC (rev 127519) @@ -0,0 +1 @@ +https://github.com/buildout/buildout/tree/1.6.x
_______________________________________________ checkins mailing list checkins@zope.org https://mail.zope.org/mailman/listinfo/checkins
_______________________________________________ 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 )
On 2012-8-18 10:39, Jens Vagelpohl wrote:
Hi Hanno,
Legally this must be a fork then and I'm not sure it can be released as official Zope Foundation software anymore if you make releases from GitHub.
Doesn't the name zc.buildout imply that it is a Zope Corp project instead of a Zope Foundation one? The author has also never been listed as the foundation but Jim personally, which seems to imply zc.buildout never was Zope Foundation-owned software. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Sat, Aug 18, 2012 at 6:46 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
Doesn't the name zc.buildout imply that it is a Zope Corp project instead of a Zope Foundation one? The author has also never been listed as the foundation but Jim personally, which seems to imply zc.buildout never was Zope Foundation-owned software.
Jim *wrote* the software (and is therefore the author, regardless of who *owns* it), and gave it to the Zope Foundation under his contributor's agreement. Therefore, the Foundation and Zope Corporation both have equal ownership stakes. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> "A person who won't read has no advantage over one who can't read." --Samuel Langhorne Clemens
On Aug 18, 2012, at 12:46 , Wichert Akkerman <wichert@wiggy.net> wrote:
On 2012-8-18 10:39, Jens Vagelpohl wrote:
Hi Hanno,
Legally this must be a fork then and I'm not sure it can be released as official Zope Foundation software anymore if you make releases from GitHub.
Doesn't the name zc.buildout imply that it is a Zope Corp project instead of a Zope Foundation one? The author has also never been listed as the foundation but Jim personally, which seems to imply zc.buildout never was Zope Foundation-owned software.
Hi Wichert, Clearly, Jim is the "father" of that software and it has been developed in large part for Zope Corporation, hence the name "zc.buildout". However, that's not all there is to "ownership" of code on svn.zope.org. If you read the contributor agreements[1] all committers to svn.zope.org signed, submitting code to svn.zope.org also meant you entered into a legal agreement with the Zope Foundation regarding that code. Code submitted to svn.zope.org is from that moment on half-owned by the Zope Foundation. That means you cannot unilaterally just declare code removed from svn.zope.org, which is my point about the last checkin to the zc.buildout package. Everyone is free to fork code. But removing stuff from svn.zope.org requires approval from you as the original owner *and* the ZF as legal co-owner of anything stored on svn.zope.org. Caveat: I'm not a lawyer, that's just how I interpret the contributor agreement. jens [1] http://foundation.zope.org/agreements/ZopeFoundation_Committer_Agreement
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/18/2012 03:18 PM, Jens Vagelpohl wrote:
But removing stuff from svn.zope.org requires approval from you as the original owner *and* the ZF as legal co-owner of anything stored on svn.zope.org.
Actually, it requires the permission of the ZF. The original owner has no more say in it than any other contributor: her rights are purely to incorporate forks (of her contributions) into non-ZPL'ed software. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAwA6wACgkQ+gerLs4ltQ4l+wCgxrYPGdrpBDnlts3Vp1D4wDDp 6+UAoKf8hEYjQOTwfzGmHGMkjZS1bgNy =pWcR -----END PGP SIGNATURE-----
Hi Jens, On 18/08/2012 09:39, Jens Vagelpohl wrote:
Legally this must be a fork then and I'm not sure it can be released as official Zope Foundation software anymore if you make releases from GitHub. Reason: the ZF can no longer ascertain that only official ZF contributor agreement signers have modified code in the package,
Actually, with the cryptographically signed nature of git commits, I'm not sure this is true...
which is a core requirement for software released from Zope Foundation repositories/under Zope Foundation auspices.
Well, I guess releases would be made outside of these auspices then, whatever that means... The license looks the same, the same people are doing the development. Quite frankly, given the hard time we have getting people to help out, anything that eases that can only be a good thing. Chris McDonough and the rest of the Pyramid folk seem happy enough with the GitHub model, and I've found it's made life very much easier for the python-excel project and the other packages I maintain.
Apart from those legal points which are still not entirely clear, since this can only be a fork I would say that last checkin must still be reverted. Don't get me wrong, I'm not trying to be facetious, but until those legal questions are cleared up you should not make any checkins on svn.zope.org that basically "shut down" development of that package from there, such as deleting the trunk.
No history has been destroyed, it's just a clear marker of where active development is happening. That said, I don't have a strong opinion on this, I'd suggest Jim just makes the call... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Sat, Aug 18, 2012 at 10:39 AM, Jens Vagelpohl <jens@dataflake.org> wrote:
Legally this must be a fork then and I'm not sure it can be released as official Zope Foundation software anymore if you make releases from GitHub. Reason: the ZF can no longer ascertain that only official ZF contributor agreement signers have modified code in the package, which is a core requirement for software released from Zope Foundation repositories/under Zope Foundation auspices.
Is this because of the support for merging pull requests? Is that really legally different than a contributor making a merge from a patch? //Lennart
On Aug 18, 2012, at 15:46 , Lennart Regebro <regebro@gmail.com> wrote:
On Sat, Aug 18, 2012 at 10:39 AM, Jens Vagelpohl <jens@dataflake.org> wrote:
Legally this must be a fork then and I'm not sure it can be released as official Zope Foundation software anymore if you make releases from GitHub. Reason: the ZF can no longer ascertain that only official ZF contributor agreement signers have modified code in the package, which is a core requirement for software released from Zope Foundation repositories/under Zope Foundation auspices.
Is this because of the support for merging pull requests? Is that really legally different than a contributor making a merge from a patch?
Hi Lennart, The contributor agreement requires you as the contributor to be able to enter into the contract with the Zope Foundation transferring one half ownership to the Zope Foundation. You can only enter into this contract if you own (as in "wrote") the code yourself - you cannot assign ownership to someone else for something you don't fully own. The goal of these contractual requirements is to make sure software stored in the Zope Foundation is as "clean" as possible from an ownership standpoint. People who use code from svn.zope.org have a reasonable assurance that no third party will show up on your doorstep demanding money or license fees for code that third party claims to own. I've just recently seen what can happen for projects not following this kind of strict policy: The python-ldap package developers are unable to e.g. assign a new license to their code because since they don't hold any ownership and would need to ask every single developer who ever touched that code - an impossible task. For us that kind of issue does not arise. jens
On Sat, Aug 18, 2012 at 9:36 PM, Jens Vagelpohl <jens@dataflake.org> wrote:
On Aug 18, 2012, at 15:46 , Lennart Regebro <regebro@gmail.com> wrote:
On Sat, Aug 18, 2012 at 10:39 AM, Jens Vagelpohl <jens@dataflake.org> wrote:
Legally this must be a fork then and I'm not sure it can be released as official Zope Foundation software anymore if you make releases from GitHub. Reason: the ZF can no longer ascertain that only official ZF contributor agreement signers have modified code in the package, which is a core requirement for software released from Zope Foundation repositories/under Zope Foundation auspices.
Is this because of the support for merging pull requests? Is that really legally different than a contributor making a merge from a patch?
Hi Lennart,
The contributor agreement requires you as the contributor to be able to enter into the contract with the Zope Foundation transferring one half ownership to the Zope Foundation. You can only enter into this contract if you own (as in "wrote") the code yourself - you cannot assign ownership to someone else for something you don't fully own.
The goal of these contractual requirements is to make sure software stored in the Zope Foundation is as "clean" as possible from an ownership standpoint. People who use code from svn.zope.org have a reasonable assurance that no third party will show up on your doorstep demanding money or license fees for code that third party claims to own.
I've just recently seen what can happen for projects not following this kind of strict policy: The python-ldap package developers are unable to e.g. assign a new license to their code because since they don't hold any ownership and would need to ask every single developer who ever touched that code - an impossible task. For us that kind of issue does not arise.
Yes, but my question is why this changes with github. //Lennart
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/18/2012 03:46 PM, Lennart Regebro wrote:
On Sat, Aug 18, 2012 at 9:36 PM, Jens Vagelpohl <jens@dataflake.org> wrote:
The contributor agreement requires you as the contributor to be able to enter into the contract with the Zope Foundation transferring one half ownership to the Zope Foundation. You can only enter into this contract if you own (as in "wrote") the code yourself - you cannot assign ownership to someone else for something you don't fully own.
The goal of these contractual requirements is to make sure software stored in the Zope Foundation is as "clean" as possible from an ownership standpoint. People who use code from svn.zope.org have a reasonable assurance that no third party will show up on your doorstep demanding money or license fees for code that third party claims to own.
I've just recently seen what can happen for projects not following this kind of strict policy: The python-ldap package developers are unable to e.g. assign a new license to their code because since they don't hold any ownership and would need to ask every single developer who ever touched that code - an impossible task. For us that kind of issue does not arise.
Yes, but my question is why this changes with github.
Because the ability to check into svn.zope.org is based on a "chain of custody" managed by the ZF (web account, verified e-mail address, and SSH key). J. Random Hacker's account on Github has no such chain. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAwAwgACgkQ+gerLs4ltQ7/wwCgpdrjdb1ER6P7FS3lqO91FlwO ucQAnRpbKzABEIXDrDg5vsgJcCxz7DNX =0tGk -----END PGP SIGNATURE-----
On Sat, Aug 18, 2012 at 11:03 PM, Tres Seaver <tseaver@palladion.com> wrote:
Because the ability to check into svn.zope.org is based on a "chain of custody" managed by the ZF (web account, verified e-mail address, and SSH key). J. Random Hacker's account on Github has no such chain.
Sure, but Random J Hacker shouldn't have write permission to the repository, so I don't understand why that makes a difference. //Lennart
Hi, On 2012-08-19 01:24:31 +0000, Lennart Regebro said:
On Sat, Aug 18, 2012 at 11:03 PM, Tres Seaver <tseaver@palladion.com> wrote:
Because the ability to check into svn.zope.org is based on a "chain of custody" managed by the ZF (web account, verified e-mail address, and SSH key). J. Random Hacker's account on Github has no such chain.
Sure, but Random J Hacker shouldn't have write permission to the repository, so I don't understand why that makes a difference.
IANAL but from my perspective the legitimate issue here is that Domen Kožar has not signed the Zope Contributor's Agreement, but Jim has added him to the Buildout organization on GitHub and he has been committing fixes. If I were the ZF, I would either: - Make sure everyone in any ZF organizations on GitHub (e.g. buildout) has signed the contributor agreement, or - Declare that nothing on GitHub (or at least in the buildout organization) is a valid contribution to "the work". In either case, AFAICT zc.buildout development has stopped on svn.zope.org and started on GitHub so let us let the commit stand to reflect this real world circumstance. Alex
//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
On Aug 19, 2012, at 3:58 , Alex Clark <aclark@aclark.net> wrote:
IANAL but from my perspective the legitimate issue here is that Domen Kožar has not signed the Zope Contributor's Agreement, but Jim has added him to the Buildout organization on GitHub and he has been committing fixes. If I were the ZF, I would either:
- Make sure everyone in any ZF organizations on GitHub (e.g. buildout) has signed the contributor agreement, or - Declare that nothing on GitHub (or at least in the buildout organization) is a valid contribution to "the work".
In either case, AFAICT zc.buildout development has stopped on svn.zope.org and started on GitHub so let us let the commit stand to reflect this real world circumstance.
Right now it can only be the second option. There's no "ZF organization" on GitHub. Legally, the zc.buildout fork now existing on GitHub is independent of the ZF, and the developers maintaining it are acting independent of the ZF. Don't get me wrong, they have every right to do so. But right now they cannot claim their software as being part of the Zope Foundation set of software. The same is true for all packages forked onto GitHub that were maintained on svn.zope.org before. This may change in the future should the ZF one day embrace GitHub as the canonical repository, but that hasn't happened at this point. jens
On 19 August 2012 08:00, Jens Vagelpohl <jens@dataflake.org> wrote:
On Aug 19, 2012, at 3:58 , Alex Clark <aclark@aclark.net> wrote:
IANAL but from my perspective the legitimate issue here is that Domen Kožar has not signed the Zope Contributor's Agreement, but Jim has added him to the Buildout organization on GitHub and he has been committing fixes. If I were the ZF, I would either:
- Make sure everyone in any ZF organizations on GitHub (e.g. buildout) has signed the contributor agreement, or - Declare that nothing on GitHub (or at least in the buildout organization) is a valid contribution to "the work".
In either case, AFAICT zc.buildout development has stopped on svn.zope.org and started on GitHub so let us let the commit stand to reflect this real world circumstance.
Right now it can only be the second option. There's no "ZF organization" on GitHub. Legally, the zc.buildout fork now existing on GitHub is independent of the ZF, and the developers maintaining it are acting independent of the ZF. Don't get me wrong, they have every right to do so. But right now they cannot claim their software as being part of the Zope Foundation set of software. The same is true for all packages forked onto GitHub that were maintained on svn.zope.org before.
It may be useful for the sake of this thread to articulate why the people who did fork it and move it to GitHub might benefit from the above. Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/18/2012 09:58 PM, Alex Clark wrote:
Hi,
On 2012-08-19 01:24:31 +0000, Lennart Regebro said:
On Sat, Aug 18, 2012 at 11:03 PM, Tres Seaver <tseaver@palladion.com> wrote:
Because the ability to check into svn.zope.org is based on a "chain of custody" managed by the ZF (web account, verified e-mail address, and SSH key). J. Random Hacker's account on Github has no such chain.
Sure, but Random J Hacker shouldn't have write permission to the repository, so I don't understand why that makes a difference.
IANAL but from my perspective the legitimate issue here is that Domen Ko?ar has not signed the Zope Contributor's Agreement, but Jim has added him to the Buildout organization on GitHub and he has been committing fixes. If I were the ZF, I would either:
- Make sure everyone in any ZF organizations on GitHub (e.g. buildout) has signed the contributor agreement, or - Declare that nothing on GitHub (or at least in the buildout organization) is a valid contribution to "the work".
In either case, AFAICT zc.buildout development has stopped on svn.zope.org and started on GitHub so let us let the commit stand to reflect this real world circumstance.
Alex, please revert the commit removing the ZF's copy of the code in SVN. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAxC9QACgkQ+gerLs4ltQ7gOgCfd+h0SnF8jVLNTaJIldH4qbQV +pEAoK7Qc7WVZ2whyA1UOSCYqQc1cNp3 =6T6l -----END PGP SIGNATURE-----
Hi Tres, On 2012-08-19 15:52:52 +0000, Tres Seaver said:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/18/2012 09:58 PM, Alex Clark wrote:
Hi,
On 2012-08-19 01:24:31 +0000, Lennart Regebro said:
On Sat, Aug 18, 2012 at 11:03 PM, Tres Seaver <tseaver@palladion.com> wrote:
Because the ability to check into svn.zope.org is based on a "chain of custody" managed by the ZF (web account, verified e-mail address, and SSH key). J. Random Hacker's account on Github has no such chain.
Sure, but Random J Hacker shouldn't have write permission to the repository, so I don't understand why that makes a difference.
IANAL but from my perspective the legitimate issue here is that Domen Ko?ar has not signed the Zope Contributor's Agreement, but Jim has added him to the Buildout organization on GitHub and he has been committing fixes. If I were the ZF, I would either:
- Make sure everyone in any ZF organizations on GitHub (e.g. buildout) has signed the contributor agreement, or - Declare that nothing on GitHub (or at least in the buildout organization) is a valid contribution to "the work".
In either case, AFAICT zc.buildout development has stopped on svn.zope.org and started on GitHub so let us let the commit stand to reflect this real world circumstance.
Alex, please revert the commit removing the ZF's copy of the code in SVN.
I don't really feel comfortable doing that (for a variety of reasons). But if you or anyone else wants to do it, I won't object. Would you mind doing it for me, if you feel that strongly about it? Probably something like: $ svn cp -r127509 svn+ssh://svn.zope.org/repos/main/zc.buildout/trunk svn+ssh://svn.zope.org/repos/main/zc.buildout/trunk Thank you and sorry for the trouble, Alex
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAxC9QACgkQ+gerLs4ltQ7gOgCfd+h0SnF8jVLNTaJIldH4qbQV +pEAoK7Qc7WVZ2whyA1UOSCYqQc1cNp3 =6T6l -----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 )
-- Alex Clark · http://pythonpackages.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/18/2012 09:24 PM, Lennart Regebro wrote:
On Sat, Aug 18, 2012 at 11:03 PM, Tres Seaver <tseaver@palladion.com> wrote:
Because the ability to check into svn.zope.org is based on a "chain of custody" managed by the ZF (web account, verified e-mail address, and SSH key). J. Random Hacker's account on Github has no such chain.
Sure, but Random J Hacker shouldn't have write permission to the repository, so I don't understand why that makes a difference.
The point is that the identity of the committer on Github is not tied to the ZF's machinery for contributions, which means that it cannot be used to preserve the "chain of custody" under the contributor agreement. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAxCv4ACgkQ+gerLs4ltQ7hDgCfaQN7zti4rJ6vxCOGMPK/GLoc r8QAoJry8boBEq1l3OIrO61KrAQQwUT1 =F7Vv -----END PGP SIGNATURE-----
On Sun, Aug 19, 2012 at 5:49 PM, Tres Seaver <tseaver@palladion.com> wrote:
The point is that the identity of the committer on Github is not tied to the ZF's machinery for contributions, which means that it cannot be used to preserve the "chain of custody" under the contributor agreement.
What stops us from fixing this problem? //Lennart
On Aug 18, 2012, at 21:46 , Lennart Regebro <regebro@gmail.com> wrote:
Yes, but my question is why this changes with github.
GitHub is a third party infrastructure run by other people. I cannot ascertain how well it enforces our requirement that all checkins must be from signed contributors only. Furthermore, I cannot ascertain that private contributor data remains private (email addresses etc). And since it becomes ever easier to accept code from unknown sources (e.g. pull requests) legal code ownership becomes an issue again. jens
On Sun, Aug 19, 2012 at 8:49 AM, Jens Vagelpohl <jens@dataflake.org> wrote:
On Aug 18, 2012, at 21:46 , Lennart Regebro <regebro@gmail.com> wrote:
Yes, but my question is why this changes with github.
GitHub is a third party infrastructure run by other people. I cannot ascertain how well it enforces our requirement that all checkins must be from signed contributors only.
I have to say that I find it to be without any reasonable doubt without question that you can only wrote to a repository if you have write access. Questioning this is to me somewhat surprising, and we might as well claim that we can't ascertain how well the current SVN server enforces our requirements, as we don't know what undiscovered security holes it might have.
Furthermore, I cannot ascertain that private contributor data remains private (email addresses etc).
Is this really a requirement? Why is this a requirement? All you need to enter at github is an email (which in practice is all we can verify in ZF as well, as all communication is by email). Why does this email address have to remain private?
And since it becomes ever easier to accept code from unknown sources (e.g. pull requests) legal code ownership becomes an issue again.
And that returns me to my first question: Is it really legally different for a contributor to accept a pull request from a non-contributor compared with a contributor merging a patch from a non-contributor? //Lennart
On Aug 19, 2012, at 10:17 , Lennart Regebro <regebro@gmail.com> wrote:
And since it becomes ever easier to accept code from unknown sources (e.g. pull requests) legal code ownership becomes an issue again.
And that returns me to my first question: Is it really legally different for a contributor to accept a pull request from a non-contributor compared with a contributor merging a patch from a non-contributor?
Legally, both are disallowed unless there's some proof (written statement etc) from the code author that he assigns ownership of the patch or the contents of that pull request to the contributor who is doing the checkin. In the past we haven't done a good job of enforcing this clear ownership assignment chain. There are always code patches from non-contributors in the bug tracker that may make it into the code base with the help of a contributor. There's a grey area: Is the act of submitting a patch into the Zope bug tracker enough to signal "I am giving you ownership of this code"? I am not sure. GitHub makes this pulling in of "outside" code even easier. I'm afraid it will become even harder to really maintain this chain of custody. jens
On 19.08.2012 10:30, Jens Vagelpohl wrote:
On Aug 19, 2012, at 10:17 , Lennart Regebro <regebro@gmail.com> wrote:
And since it becomes ever easier to accept code from unknown sources (e.g. pull requests) legal code ownership becomes an issue again.
And that returns me to my first question: Is it really legally different for a contributor to accept a pull request from a non-contributor compared with a contributor merging a patch from a non-contributor?
Legally, both are disallowed unless there's some proof (written statement etc) from the code author that he assigns ownership of the patch or the contents of that pull request to the contributor who is doing the checkin.
In the past we haven't done a good job of enforcing this clear ownership assignment chain. There are always code patches from non-contributors in the bug tracker that may make it into the code base with the help of a contributor. There's a grey area: Is the act of submitting a patch into the Zope bug tracker enough to signal "I am giving you ownership of this code"? I am not sure.
GitHub makes this pulling in of "outside" code even easier. I'm afraid it will become even harder to really maintain this chain of custody.
I just wonder why this works then for other projects like plone or pyramid which basically follows similar rules as the ZF with a signed contributor agreement required in order to make core contributions. http://plone.org/foundation/contributors-agreement/agreement.pdf/view https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt btw - pyramid seem to have a very pragmatic approach for the signing process ;) Either way - SVN or GIT - it is just a question IF merging code from a non-contributor is done BY a contributor, not HOW. For me the discussion sounds a little like a general denial against github using the legal story as rationale. robert
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 )
-- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at
On Aug 19, 2012, at 10:55 , Robert Niederreiter <rnix@squarewave.at> wrote:
https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt
btw - pyramid seem to have a very pragmatic approach for the signing process ;)
An approach I doubt will hold up in a court of law. We require and have wet signatures, which makes me feel a lot more "on the safe side".
Either way - SVN or GIT - it is just a question IF merging code from a non-contributor is done BY a contributor, not HOW.
Done by a contributor with some clear gesture from the non-contributor that code ownership is going into the hands of that contributor.
For me the discussion sounds a little like a general denial against github using the legal story as rationale.
Speaking for myself as ZF representative, it is my duty to make sure that chain of custody for the code is upheld and safeguarded. Convenience, which I feel is driving the move towards GitHub, is nice to have. But I would not do my job if I didn't make extra-sure that any move for Zope Foundation code did not fulfil all legal requirements before spending much thought on convenience. jens
On 19.08.2012 12:16, Jens Vagelpohl wrote:
On Aug 19, 2012, at 10:55 , Robert Niederreiter <rnix@squarewave.at> wrote:
https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt
btw - pyramid seem to have a very pragmatic approach for the signing process ;)
An approach I doubt will hold up in a court of law. We require and have wet signatures, which makes me feel a lot more "on the safe side".
Thats fine to everyone i think. Referring to github this would require to give write access only to people who have signed the agreement.
Either way - SVN or GIT - it is just a question IF merging code from a non-contributor is done BY a contributor, not HOW.
Done by a contributor with some clear gesture from the non-contributor that code ownership is going into the hands of that contributor.
How does this 'clear gesture' from the non-contributor look like right now? A patch attached to an email or a bug report? As Lennard pointed out, how does this differ from a pull request attached to a repository?
For me the discussion sounds a little like a general denial against github using the legal story as rationale.
Speaking for myself as ZF representative, it is my duty to make sure that chain of custody for the code is upheld and safeguarded. Convenience, which I feel is driving the move towards GitHub, is nice to have. But I would not do my job if I didn't make extra-sure that any move for Zope Foundation code did not fulfil all legal requirements before spending much thought on convenience.
Also perfectly fine. Maybe it's anyway a good idea to find a process enabling contributors going to github with ZF code. robert
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 )
-- Robert Niederreiter Squarewave Computing Aflingerstraße 19 A-6176 Völs Tel: +43 699 160 20 192 Web: http://www.squarewave.at
On 2012-8-19 12:59, Robert Niederreiter wrote:
On 19.08.2012 12:16, Jens Vagelpohl wrote:
Done by a contributor with some clear gesture from the non-contributor that code ownership is going into the hands of that contributor. How does this 'clear gesture' from the non-contributor look like right now? A patch attached to an email or a bug report? As Lennard pointed out, how does this differ from a pull request attached to a repository?
A simple solution to allow pull requests but keep the submitter-has-signed-policy check is to only allow pull requests made from a ZF-owner repository. github allows pull requests from a different branch within the same repository which makes this very easy. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Sun, Aug 19, 2012 at 12:16 PM, Jens Vagelpohl <jens@dataflake.org> wrote:
Speaking for myself as ZF representative, it is my duty to make sure that chain of custody for the code is upheld and safeguarded. Convenience, which I feel is driving the move towards GitHub, is nice to have. But I would not do my job if I didn't make extra-sure that any move for Zope Foundation code did not fulfil all legal requirements before spending much thought on convenience.
Absolutely, and you are doing a good job as well, as you have no identified a problem that we have been having for a long time, before the problem actually turns legal. That's an amazing relief, because it means we can fix it. //Lennart
Hi On 2012-08-19 11:05:39 +0000, Lennart Regebro said:
On Sun, Aug 19, 2012 at 12:16 PM, Jens Vagelpohl <jens@dataflake.org> wrote:
Speaking for myself as ZF representative, it is my duty to make sure that chain of custody for the code is upheld and safeguarded. Convenience, which I feel is driving the move towards GitHub, is nice to have. But I would not do my job if I didn't make extra-sure that any move for Zope Foundation code did not fulfil all legal requirements before spending much thought on convenience.
Absolutely, and you are doing a good job as well, as you have no identified a problem that we have been having for a long time, before the problem actually turns legal. That's an amazing relief, because it means we can fix it.
FWIW I have pointed Domen Kožar at the contributor agreement instructions located here: - http://docs.zope.org/developer/becoming-a-committer.html and he is interested in signing. What I'd like to see is this issue addressed by a lawyer so we can figure out how to make GitHub work for Zope. If Jim's work on Buildout 2 on GitHub is considered a fork, then I think something is wrong with our process. Here are some scenarios to demonstrate what I think the important issues we must clarify are: Scenario 1 -------------- - Alex has signed the contributor agreement and commits code to svn.zope.org, no problem. Scenario 2 --------------- - Alex has signed the contributor agreement and commits patches from other people (who have not signed the agreement) to svn.zope.org, not allowed, IIUC. Scenario 3 --------------- - Alex has signed the contributor agreement and commits code to GitHub/buildout, no problem. Scenario 4 --------------- - Alex has signed the contributor agreement and commits patches from other people (who have not signed the agreement) to GitHub/buildout not allowed, IIUC. Scenario 5 --------------- - No commits from anyone who has not signed the contributor agreement are allowed. If we can all agree on the above, then the only thing left AFAICT is for the ZF to "bless" GitHub/buildout as a ZF repository and have a lawyer confirm that this blessing has merit from a legal perspective. Alex
//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
Robert Niederreiter <rnix@squarewave.at> writes:
On 19.08.2012 10:30, Jens Vagelpohl wrote:
On Aug 19, 2012, at 10:17 , Lennart Regebro <regebro@gmail.com> wrote:
And since it becomes ever easier to accept code from unknown sources (e.g. pull requests) legal code ownership becomes an issue again.
And that returns me to my first question: Is it really legally different for a contributor to accept a pull request from a non-contributor compared with a contributor merging a patch from a non-contributor?
Legally, both are disallowed unless there's some proof (written statement etc) from the code author that he assigns ownership of the patch or the contents of that pull request to the contributor who is doing the checkin.
In the past we haven't done a good job of enforcing this clear ownership assignment chain. There are always code patches from non-contributors in the bug tracker that may make it into the code base with the help of a contributor. There's a grey area: Is the act of submitting a patch into the Zope bug tracker enough to signal "I am giving you ownership of this code"? I am not sure.
GitHub makes this pulling in of "outside" code even easier. I'm afraid it will become even harder to really maintain this chain of custody.
I just wonder why this works then for other projects like plone or pyramid which basically follows similar rules as the ZF with a signed contributor agreement required in order to make core contributions.
http://plone.org/foundation/contributors-agreement/agreement.pdf/view
https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt
btw - pyramid seem to have a very pragmatic approach for the signing process ;)
Either way - SVN or GIT - it is just a question IF merging code from a non-contributor is done BY a contributor, not HOW.
For me the discussion sounds a little like a general denial against github using the legal story as rationale.
+10. I'm so glad others are saying the things I think need saying. I *am* a signed ZF contributor and from experience, the likelihood of such stop energy or other unpleasantness prevents me from contributing to Zope projects nearly as much as I'd like or could. This is a sterling example. To be clear, I'm not invalidating legal concerns, I'm only frustrated that those representing those concerns are taking a hard line on only one concern without seeming to accept multiple invitations to work the problem from all represented concerns. I'm grateful to the others for trying so hard to kickstart a healthy level of participation in zc.buildout development once again. Ross
On 20 August 2012 01:44, Ross Patterson <me@rpatterson.net> wrote:
For me the discussion sounds a little like a general denial against github using the legal story as rationale.
+10. I'm so glad others are saying the things I think need saying.
I *am* a signed ZF contributor and from experience, the likelihood of such stop energy or other unpleasantness prevents me from contributing to Zope projects nearly as much as I'd like or could. This is a sterling example.
To be clear, I'm not invalidating legal concerns, I'm only frustrated that those representing those concerns are taking a hard line on only one concern without seeming to accept multiple invitations to work the problem from all represented concerns. I'm grateful to the others for trying so hard to kickstart a healthy level of participation in zc.buildout development once again.
It is mildly interesting to compare the volume of discussion about Zope development vs the volume of discussion about where not to do Zope development on this list in the last few days. I think Jens is right to point out the legal concerns, which many of us don't fully understand. I think it might have been more effective had it pointed out why people should care, rather than just saying "this is the rule". Martin
On Aug 20, 2012, at 3:08 , Martin Aspeli <optilude+lists@gmail.com> wrote:
I think Jens is right to point out the legal concerns, which many of us don't fully understand. I think it might have been more effective had it pointed out why people should care, rather than just saying "this is the rule".
+1 it seems to me the ZF should consider having a lawyer check the legal implications of dealing with github instead of just stating again and again that the situation is not clear (and therefore they cannot do anything). as it looks the 1.6.1 release has already been made from github, and under the ZPL. if i understand jens correctly this shouldn't even be possible… best regards, andi -- andreas zeidler http://plone.org/author/witsch
On 2012-08-20 08:15:55 +0000, Andi Zeidler said:
On Aug 20, 2012, at 3:08 , Martin Aspeli <optilude+lists@gmail.com> wrote:
I think Jens is right to point out the legal concerns, which many of us don't fully understand. I think it might have been more effective had it pointed out why people should care, rather than just saying "this is the rule".
+1
it seems to me the ZF should consider having a lawyer check the legal implications of dealing with github instead of just stating again and again that the situation is not clear (and therefore they cannot do anything). as it looks the 1.6.1 release has already been made from github, and under the ZPL. if i understand jens correctly this shouldn't even be possible…
IIUC Jens' valid concern is that non-contributors have contributed to "the work", making legal ownership unclear. Reverting my commit won't fix this (or at least I don't understand fully how or why reverting my commit offers us any legal protection, which seems to be the concern). IMHO we need to get Domen Kožar to sign the contributor agreement, and finish the discussion on the "code ownership" list about how to move forward. Alex
best regards,
andi
-- Alex Clark · http://pythonpackages.com
Hi, I approve your position Jens. Moving to git can make sense. Moving to github as primary platform does not make sense. Github is a proprietary platform. There is really no justification in using a proprietary platform for open source projects, especially considering that many open source alternatives exist and that nothing prevents from using github as a mirror (for marketing purpose for example). It is not only depressing to see open source communities not eating their own dog food but also irresponsible. It is irresponsible because Cloud / SaaS is far from reliable. Please read this to get an idea. (http://iwgcr.org/paris-university-and-telecom-paristech-publish-availability...). Service outages are not rare. It is irresponsible because it sends a message to the market that open source is not competitive (else open source communities would use it for themselves). Many open source git hosting solutions do exist (incl. gitorious, gitlab, indefero). Why not use them ? On a more positive side, Nexedi is currently sponsoring the port of Gitlab (http://gitlabhq.com/) open source git platform to SlapOS ( http://www.slapos.org/) open source Cloud. This means that there will in a few days a python based, Zope based, buildout based and fully resilient platform to host open source projects, with the ability to manage copies of source code on servers all around the world in a true community fashion. And after reading today's message, I got so upset that I decided that Nexedi will use SlapOS to offer hosting to any open source Zope community project which believes enough in open source values to use open source tools rather than proprietary ones. This will include free support to any open source Zope project willing to manage its own SlapOS platform rather rely on ours. Let us see if Zope community will be the first or the last to eat its own dog food ;-). Regards, JPS. Nexedi CEO PS. I do not mind behind hated for using the word "irresponsible", whooever took the decision to use github. I do mean it. Le 18/08/2012 09:49, Jens Vagelpohl a écrit :
Hi Alex,
Please revert this checkin. You can't just take core software pieces from Zope Foundation-hosted repositories and move them somewhere else.
Thanks!
jens
On Aug 18, 2012, at 3:09 , J. Alexander Clark<cvs-admin@zope.org> wrote:
Log message for revision 127519: Moved to github
Changed: A zc.buildout/README_MOVED_TO_GITHUB.txt D zc.buildout/trunk/
-=- Added: zc.buildout/README_MOVED_TO_GITHUB.txt =================================================================== --- zc.buildout/README_MOVED_TO_GITHUB.txt (rev 0) +++ zc.buildout/README_MOVED_TO_GITHUB.txt 2012-08-18 01:09:06 UTC (rev 127519) @@ -0,0 +1 @@ +https://github.com/buildout/buildout/tree/1.6.x
_______________________________________________ checkins mailing list checkins@zope.org https://mail.zope.org/mailman/listinfo/checkins
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 )
I'm not going to dignify this with a fuller response other than to say that Jean-Paul Smets' entire email is nothing but bullshit written to try and promote an inferior competing product ;-) Chris On 18/08/2012 13:31, Jean-Paul Smets wrote:
Hi,
I approve your position Jens.
Moving to git can make sense. Moving to github as primary platform does not make sense.
Github is a proprietary platform. There is really no justification in using a proprietary platform for open source projects, especially considering that many open source alternatives exist and that nothing prevents from using github as a mirror (for marketing purpose for example).
It is not only depressing to see open source communities not eating their own dog food but also irresponsible.
It is irresponsible because Cloud / SaaS is far from reliable. Please read this to get an idea. (http://iwgcr.org/paris-university-and-telecom-paristech-publish-availability...). Service outages are not rare.
It is irresponsible because it sends a message to the market that open source is not competitive (else open source communities would use it for themselves). Many open source git hosting solutions do exist (incl. gitorious, gitlab, indefero). Why not use them ?
On a more positive side, Nexedi is currently sponsoring the port of Gitlab (http://gitlabhq.com/) open source git platform to SlapOS ( http://www.slapos.org/) open source Cloud. This means that there will in a few days a python based, Zope based, buildout based and fully resilient platform to host open source projects, with the ability to manage copies of source code on servers all around the world in a true community fashion.
And after reading today's message, I got so upset that I decided that Nexedi will use SlapOS to offer hosting to any open source Zope community project which believes enough in open source values to use open source tools rather than proprietary ones. This will include free support to any open source Zope project willing to manage its own SlapOS platform rather rely on ours. Let us see if Zope community will be the first or the last to eat its own dog food ;-).
Regards,
JPS. Nexedi CEO
PS. I do not mind behind hated for using the word "irresponsible", whooever took the decision to use github. I do mean it.
Le 18/08/2012 09:49, Jens Vagelpohl a écrit :
Hi Alex,
Please revert this checkin. You can't just take core software pieces from Zope Foundation-hosted repositories and move them somewhere else.
Thanks!
jens
On Aug 18, 2012, at 3:09 , J. Alexander Clark<cvs-admin@zope.org> wrote:
Log message for revision 127519: Moved to github
Changed: A zc.buildout/README_MOVED_TO_GITHUB.txt D zc.buildout/trunk/
-=- Added: zc.buildout/README_MOVED_TO_GITHUB.txt =================================================================== --- zc.buildout/README_MOVED_TO_GITHUB.txt (rev 0) +++ zc.buildout/README_MOVED_TO_GITHUB.txt 2012-08-18 01:09:06 UTC (rev 127519) @@ -0,0 +1 @@ +https://github.com/buildout/buildout/tree/1.6.x
_______________________________________________ checkins mailing list checkins@zope.org https://mail.zope.org/mailman/listinfo/checkins
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 )
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.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 )
-- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Am 18.08.2012, 15:35 Uhr, schrieb Chris Withers <chris@simplistix.co.uk>:
I'm not going to dignify this with a fuller response other than to say that Jean-Paul Smets' entire email is nothing but bullshit written to try and promote an inferior competing product.
The issues of hosting and vcs were aired a few months ago and should be considered separately. The T&C's of any of the these products should be read carefully and I, for one, do not like the indemnification clause at Github. I would, therefore, agree with Jean-Paul in this respect. I agree with Jens, that new work should be considered as a fork. It currently feels very much cloak & dagger. 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
On Aug 18, 2012, at 14:31 , Jean-Paul Smets <jp@nexedi.com> wrote:
Hi,
I approve your position Jens.
Moving to git can make sense. Moving to github as primary platform does not make sense.
Hi Jean-Paul, Technical pros and cons are valid arguments, correct, but that wasn't my point here. I'm trying to look at the contractual issues involved, that's all. I'm not saying "only platform X is acceptable", just that right now I only have proof that our self-hosted Subversion repositories on svn.zope.org appear to meet all the legal requirements laid out by the contributor agreements and the role of the Zope Foundation as the guard of these contributions as well as contributors' private data held by the Zope Foundation. jens
Hi Jens, On 2012-08-18 07:49:59 +0000, Jens Vagelpohl said:
Hi Alex,
Please revert this checkin. You can't just take core software pieces from Zope Foundation-hosted repositories and move them somewhere else.
Thanks!
I think you are confused. I would suggest you ask Jim Fulton about it, as he moved Buildout to GitHub months ago. Both 1.6.x and 2.x are under active development there. Further, I committed the *message* about the move and I removed trunk to avoid confusion, I didn't personally move anything (Jim moved 2.x and Domen Kožar moved trunk to the 1.6.x branch). Also please see the distutils-sig list for more information about recent zc.buildout 1.6.x development. Alex
jens
On Aug 18, 2012, at 3:09 , J. Alexander Clark <cvs-admin@zope.org> wrote:
Log message for revision 127519: Moved to github
Changed: A zc.buildout/README_MOVED_TO_GITHUB.txt D zc.buildout/trunk/
-=- Added: zc.buildout/README_MOVED_TO_GITHUB.txt =================================================================== --- zc.buildout/README_MOVED_TO_GITHUB.txt (rev 0) +++ zc.buildout/README_MOVED_TO_GITHUB.txt 2012-08-18 01:09:06 UTC (rev 127519) @@ -0,0 +1 @@ +https://github.com/buildout/buildout/tree/1.6.x
_______________________________________________ checkins mailing list checkins@zope.org https://mail.zope.org/mailman/listinfo/checkins
_______________________________________________ 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
Hi On 2012-08-18 22:01:51 +0000, Alex Clark said:
Hi Jens,
On 2012-08-18 07:49:59 +0000, Jens Vagelpohl said:
Hi Alex,
Please revert this checkin. You can't just take core software pieces from Zope Foundation-hosted repositories and move them somewhere else.
Thanks!
I think you are confused. I would suggest you ask Jim Fulton about it, as he moved Buildout to GitHub months ago. Both 1.6.x and 2.x are under active development there.
Further, I committed the *message* about the move and I removed trunk to avoid confusion, I didn't personally move anything (Jim moved 2.x and Domen Kožar moved trunk to the 1.6.x branch).
Also please see the distutils-sig list for more information about recent zc.buildout 1.6.x development.
And… sorry. Using a new client and I missed the ongoing thread :-) Alex
Alex
jens
On Aug 18, 2012, at 3:09 , J. Alexander Clark <cvs-admin@zope.org> wrote:
Log message for revision 127519: Moved to github
Changed: A zc.buildout/README_MOVED_TO_GITHUB.txt D zc.buildout/trunk/
-=- Added: zc.buildout/README_MOVED_TO_GITHUB.txt =================================================================== --- zc.buildout/README_MOVED_TO_GITHUB.txt (rev 0) +++ zc.buildout/README_MOVED_TO_GITHUB.txt 2012-08-18 01:09:06 UTC (rev 127519) @@ -0,0 +1 @@ +https://github.com/buildout/buildout/tree/1.6.x
_______________________________________________ checkins mailing list checkins@zope.org https://mail.zope.org/mailman/listinfo/checkins
_______________________________________________ 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
On Aug 19, 2012, at 0:01 , Alex Clark <aclark@aclark.net> wrote:
Hi Jens,
On 2012-08-18 07:49:59 +0000, Jens Vagelpohl said:
Hi Alex, Please revert this checkin. You can't just take core software pieces from Zope Foundation-hosted repositories and move them somewhere else. Thanks!
I think you are confused. I would suggest you ask Jim Fulton about it, as he moved Buildout to GitHub months ago. Both 1.6.x and 2.x are under active development there.
Again, there's a confusion about perceived and legal ownership. jens
Hi Jens, On 2012-08-19 06:51:47 +0000, Jens Vagelpohl said:
On Aug 19, 2012, at 0:01 , Alex Clark <aclark@aclark.net> wrote:
Hi Jens,
On 2012-08-18 07:49:59 +0000, Jens Vagelpohl said:
Hi Alex, Please revert this checkin. You can't just take core software pieces from Zope Foundation-hosted repositories and move them somewhere else. Thanks!
I think you are confused. I would suggest you ask Jim Fulton about it, as he moved Buildout to GitHub months ago. Both 1.6.x and 2.x are under active development there.
Again, there's a confusion about perceived and legal ownership.
You care about legal ownership because it's your job to do so. I care about helping people and shipping code because that's my job. The only thing I feel like I am confused about is why the ZF is asking me to make a change when the action-that-matters was taken months ago by someone else? Why are you making an example out of me? Shouldn't you instead address the "real" issue (which is that Jim moved Buildout)? The code is still there in the previous revision. I didn't maliciously destroy anything. Why does the ZF feel so strongly about the issue that they need to ask me to revert an innocous, nothing-but-well-intentioned change? Have we not lost our way a bit, if this is the case? What good is the legal protection of our software, if we are just sitting around fighting about it, instead of building the software? Sorry, Jens, I don't mean to accuse you or Tres in any way. I just don't understand this situation -at-all- and I don't understand why the "right" thing to do in this case is to focus all this attention on my trivial commit, which obviously alerted you to a situation that had already begun months ago, without me. 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
participants (14)
-
Alex Clark -
Andi Zeidler -
Charlie Clark -
Chris Withers -
Fred Drake -
Hanno Schlichting -
Jean-Paul Smets -
Jens Vagelpohl -
Lennart Regebro -
Martin Aspeli -
Robert Niederreiter -
Ross Patterson -
Tres Seaver -
Wichert Akkerman