DISCUSS: Community checkins for CVS
At last, the announcement I've been dying to make. After much deliberation -- meaning, I've procrastinated for too long :^) -- I'm pleased to announce our approach for opening the CVS repository to community checkins. The first round of materials are open for public discussion at: http://dev.zope.org/CVS/ In the first bullet of the second list, you'll find links to the important documents: http://dev.zope.org/CVS/ContributorIntroduction http://dev.zope.org/CVS/ContributorFAQ http://dev.zope.org/CVS/Contributor.pdf For those desperately wanting to read as little as possible, here's an overview: o A group of people makes decisions on who to invite, just like in the Python community. We at Zope Corporation will start the process by choosing an initial, small group of invitees to bootstrap the process. o With a real signature on a real document, an invitee will legally start the process of becoming a committer. This "real document" is the Zope Contributor Agreement. o When an invitee's contributor agreement arrives, and the invitee conducts their first checkin using their CVS credentials, they are consenting to the joint ownership terms of the contributor agreement. I'd like to have a period of discussion regarding the material, particularly the Zope Contributor Agreement, through early next week. Once it is clear that the agreement is done, I can change it to version 1.0 and start accepting completed forms from people in the bootstrap group. So, let's begin what I'm sure will be a lively and illuminating discussion. :^) --Paul
On Thu, 20 Sep 2001, Paul Everitt wrote:
So, let's begin what I'm sure will be a lively and illuminating discussion. :^)
First man out? :-) Will a ZPL-ish license [1] be accepted (declared, ref. paragraph 4 of the Zope Contributor Agreement) by the Zope Corporation? [1] http://www.thingamy.org/tpl -Morten
This is a good point, and one that we need to settle on pretty quickly. The language is an artifact from the Mozilla contributor form, which served as the starting point for this. We intended to follow it, but with the advent of the joint ownership idea (which came late in the process), we might want to revisit it. Either way, I'll get an answer for you, thanks! --Paul Morten W. Petersen wrote:
On Thu, 20 Sep 2001, Paul Everitt wrote:
So, let's begin what I'm sure will be a lively and illuminating discussion. :^)
First man out? :-)
Will a ZPL-ish license [1] be accepted (declared, ref. paragraph 4 of the Zope Contributor Agreement) by the Zope Corporation?
[1] http://www.thingamy.org/tpl
-Morten
Here's the answer, added to the FAQ (but I haven't updated the page yet): 7) Can I provide my contributions under a different license, as stated in the License section of the Zope Contributor Agreement? In summary, yes but no. You don't pick the license that you use when you give it to us. Rather, we pick the license to give it to others (for our 1/2), and that license is the ZPL. You, however, can pick any license in the world to give the code to anyone other than us. This language about a different acceptible license is there in case we decide at some point to change from the ZPL to a different open source license. Make sense? --Paul Morten W. Petersen wrote:
On Thu, 20 Sep 2001, Paul Everitt wrote:
So, let's begin what I'm sure will be a lively and illuminating discussion. :^)
First man out? :-)
Will a ZPL-ish license [1] be accepted (declared, ref. paragraph 4 of the Zope Contributor Agreement) by the Zope Corporation?
[1] http://www.thingamy.org/tpl
-Morten
On Thu, 20 Sep 2001, Paul Everitt wrote:
So, let's begin what I'm sure will be a lively and illuminating discussion. :^)
First, would it be possible to put up a copy of the Contributor Agreement in html format? If you feel the only legal version for signing is the PDF one fine, but it would be a lot easier for people to check it out if there is an html version to read. Second, I suppose you should be aware of my biases before reading anything more. I don't believe in intellectual property, either copyright or patent. On the other hand, they are currently the law of the land; and, within what seems to me to be fair use kinds of standards, I try to respect copyrights while encouraging people to use vehicles that make use of as few of the restrictions imposed by copyrights and patents as possible. (You will guess that I am *not* a fan of the GPL, though I consider it far superior to a traditional copyright <grin>.) Also, I am not a lawyer and don't pretend to be very up on the subtleties of copyright law, so my concern may turn out to be naive. I very much like the intent stated in the Introduction, that of getting maximal rights into the hands of both the contributors and Zope Corporation to do things in the future with the code without having to get an endless set of sign-offs. However, I have a concern about the Agreement that isn't covered in the Introduction or the FAQ. I'm worried that the Agreement may exclude us from some of the benefits of the bazaar model of open source development. My key concern is summed up in this statement from the Introduction: "Essentially, a committer signs an agreement stating that all code that the committer submits has been created by her." The actual agreement does *not* say this, but "essentially" it does require it, since the things the committer has to swear to in submitting the code are very difficult to swear to unless he or she is the author of the code. Now, I have only contributed small amounts of code to Open Source projects so far. But I'm sure there are a lot more people out there who have "only contributed small amounts" than those who have contributed whole modules, and that there are even fewer people who do so much work that jumping through these kinds of legal hoops, and agreeing to a certain amount of liability, is worth while. In the cases where I have contributed, it's just been, "oh, cool, thanks for the patch", with no legal discussion and maybe an acknowledgment in the contributors file. My concern here is that under a regime such as this one, if I write ten lines of code that adds a feature I and a few other people really need in Zope, it is *not* going to get committed. I'm certainly not going to sign that agreement and become a committer just for ten lines of code, and I much doubt that Zope Corporation is going to want to go to the overhead of vetting my application just for ten lines of code. But if I wrote those ten lines, it hardly seems that any other contributor can commit them, since they don't own any rights to them that they can assign to Zope Corporation. I suppose that I could assign them those rights, but personally I find that idea repugnant since I don't believe in intellectual property <grin>. (Hmm. If I put my stuff in the public domain, how would that play in?) But aside from that, jumping through legal hoops (there would presumably have to be some sort of written assignment of rights) for ten lines of code is at the very least going to have a dampening effect on small contributions. Of course, you could get around this problem by having the committer rewrite the small submissions, but this seems a bit disingenuous, and it seems to me it might be legally questionable. In other words, under this Agreement, exactly what is the legal status of a one or two line patch? So, the many small contributions that make a bazaar software project tend rapidly toward high quality, which is one of the things I got the impression you are trying to achieve by opening up the CVS repository, may not materialize under this Agreement. We'll have just about the same situation we have now, except that there will be more committers and therefore, one hopes, an increase in the pace of (controlled) change. An improvement, yes, but can we do even better? Of course, I could be completely wrong in my guesses about the dynamics, but I figured somebody should play the devil's advocate here <grin>. --RDM
R. David Murray writes:
... So, the many small contributions that make a bazaar software project tend rapidly toward high quality, which is one of the things I got the impression you are trying to achieve by opening up the CVS repository, may not materialize under this Agreement. We'll have just about the same situation we have now, except that there will be more committers and therefore, one hopes, an increase in the pace of (controlled) change. An improvement, yes, but can we do even better? I think (and indeed I really hope) that your anxiety is not founded.
The Zope Contribution Initiative took Python as model. There, you have beside contributors a bug tracking system where problems can be reported and patches posted to. I do not know the details of Python development process, especially the legal agreements behind it. But somehow, it seems to work... Dieter
I'll reply in more depth later (on the way out for my b-day dinner), but in short: I think the issue of overhead on patches is something for us to consider. We won't do something that breaks the integrity of the code base, but there might be ample discussion directions. Thanks! --Paul Dieter Maurer wrote:
R. David Murray writes:
... So, the many small contributions that make a bazaar software project tend rapidly toward high quality, which is one of the things I got the impression you are trying to achieve by opening up the CVS repository, may not materialize under this Agreement. We'll have just about the same situation we have now, except that there will be more committers and therefore, one hopes, an increase in the pace of (controlled) change. An improvement, yes, but can we do even better? I think (and indeed I really hope) that your anxiety is not founded.
The Zope Contribution Initiative took Python as model. There, you have beside contributors a bug tracking system where problems can be reported and patches posted to.
I do not know the details of Python development process, especially the legal agreements behind it. But somehow, it seems to work...
Dieter
OK, a response. Sorry for the delay. First, I'll change the part of the introduction that says: "Essentially, a committer signs an agreement stating that all code that the committer submits has been created by her." ...to say: "Essentially, a committer signs an agreement stating that all code that the committer submits has been created by her, or that she has verified that the contributed code violates no rights." Which means that we're going to take you up on your suggestion for encouraging small patches. I just added this to the FAQ: 8) Does someone have to jump through all these legal hoops just to submit a small patch? The contributor agreement certainly is a heavy process for someone that wants to make a small contribution, such as a patch. These contributions are just as important to the health of an open source project as major code work. Thus, Zope should encourage patch contributions, not create an enormous disincentive. At the same time, integrity of the code base needs to be maintained. For small contributions, simply supply them through a communications channel such as the bug tracker or the mailing lists. Alternatively, contact a committer or ZC directly. A committer will then review the patch and assume the legal issues of committing it themselves. Likely they will contact the patch submitter and get a confirmation that the patch can be used. The committers will have some guidelines on recognizing when it is reasonable to accept a patch. It should be clear when something has little basis for being deemed intellectual property, versus a major change with advanced algorithms. In your note, you mentioned: I suppose that I could assign them those rights, but personally I find that idea repugnant since I don't believe in intellectual property <grin>. (Hmm. If I put my stuff in the public domain, how would that play in?) Repugnancy aside :^) your second comment is on the mark. It isn't so much that you need to assign and "lose" ownership. Rather, the committer needs to ensure that they aren't violating your rights. We'll probably work up some boilerplate such as, "I'm going to commit your patch to Zope. It's going to be available under the ZPL and the joint ownership model of the Zope Contributor Agreement. Please respond agreeing that you understand the ZPL, the joint ownership model, and allow this contribution under these terms." How does that sound? --Paul R. David Murray wrote:
On Thu, 20 Sep 2001, Paul Everitt wrote:
So, let's begin what I'm sure will be a lively and illuminating discussion. :^)
First, would it be possible to put up a copy of the Contributor Agreement in html format? If you feel the only legal version for signing is the PDF one fine, but it would be a lot easier for people to check it out if there is an html version to read.
Second, I suppose you should be aware of my biases before reading anything more. I don't believe in intellectual property, either copyright or patent. On the other hand, they are currently the law of the land; and, within what seems to me to be fair use kinds of standards, I try to respect copyrights while encouraging people to use vehicles that make use of as few of the restrictions imposed by copyrights and patents as possible. (You will guess that I am *not* a fan of the GPL, though I consider it far superior to a traditional copyright <grin>.) Also, I am not a lawyer and don't pretend to be very up on the subtleties of copyright law, so my concern may turn out to be naive.
I very much like the intent stated in the Introduction, that of getting maximal rights into the hands of both the contributors and Zope Corporation to do things in the future with the code without having to get an endless set of sign-offs.
However, I have a concern about the Agreement that isn't covered in the Introduction or the FAQ. I'm worried that the Agreement may exclude us from some of the benefits of the bazaar model of open source development.
My key concern is summed up in this statement from the Introduction:
"Essentially, a committer signs an agreement stating that all code that the committer submits has been created by her."
The actual agreement does *not* say this, but "essentially" it does require it, since the things the committer has to swear to in submitting the code are very difficult to swear to unless he or she is the author of the code.
Now, I have only contributed small amounts of code to Open Source projects so far. But I'm sure there are a lot more people out there who have "only contributed small amounts" than those who have contributed whole modules, and that there are even fewer people who do so much work that jumping through these kinds of legal hoops, and agreeing to a certain amount of liability, is worth while. In the cases where I have contributed, it's just been, "oh, cool, thanks for the patch", with no legal discussion and maybe an acknowledgment in the contributors file.
My concern here is that under a regime such as this one, if I write ten lines of code that adds a feature I and a few other people really need in Zope, it is *not* going to get committed. I'm certainly not going to sign that agreement and become a committer just for ten lines of code, and I much doubt that Zope Corporation is going to want to go to the overhead of vetting my application just for ten lines of code. But if I wrote those ten lines, it hardly seems that any other contributor can commit them, since they don't own any rights to them that they can assign to Zope Corporation. I suppose that I could assign them those rights, but personally I find that idea repugnant since I don't believe in intellectual property <grin>. (Hmm. If I put my stuff in the public domain, how would that play in?) But aside from that, jumping through legal hoops (there would presumably have to be some sort of written assignment of rights) for ten lines of code is at the very least going to have a dampening effect on small contributions.
Of course, you could get around this problem by having the committer rewrite the small submissions, but this seems a bit disingenuous, and it seems to me it might be legally questionable. In other words, under this Agreement, exactly what is the legal status of a one or two line patch?
So, the many small contributions that make a bazaar software project tend rapidly toward high quality, which is one of the things I got the impression you are trying to achieve by opening up the CVS repository, may not materialize under this Agreement. We'll have just about the same situation we have now, except that there will be more committers and therefore, one hopes, an increase in the pace of (controlled) change. An improvement, yes, but can we do even better?
Of course, I could be completely wrong in my guesses about the dynamics, but I figured somebody should play the devil's advocate here <grin>.
--RDM
On Tue, 25 Sep 2001, Paul Everitt wrote:
Repugnancy aside :^) your second comment is on the mark. It isn't so much that you need to assign and "lose" ownership. Rather, the committer needs to ensure that they aren't violating your rights.
We'll probably work up some boilerplate such as, "I'm going to commit your patch to Zope. It's going to be available under the ZPL and the joint ownership model of the Zope Contributor Agreement. Please respond agreeing that you understand the ZPL, the joint ownership model, and allow this contribution under these terms."
How does that sound?
Sounds like a workable process, if an email acknowledgement is enough. Perhaps you could also make some such language part of a click through during the process of submitting a patch to the server? I think for myself just labeling things as public domain will work fine, but I know that won't work for everyone. --RDM
On Tue, 2001-09-25 at 09:19, Paul Everitt wrote:
We'll probably work up some boilerplate such as, "I'm going to commit your patch to Zope. It's going to be available under the ZPL and the joint ownership model of the Zope Contributor Agreement. Please respond agreeing that you understand the ZPL, the joint ownership model, and allow this contribution under these terms."
Might it make sense to require (or perhaps just request) that the confirmation email be signed with a public key? Just my $0.02, Michael Bernstein.
Paul Everitt writes:
We'll probably work up some boilerplate such as, "I'm going to commit your patch to Zope. It's going to be available under the ZPL and the joint ownership model of the Zope Contributor Agreement. Please respond agreeing that you understand the ZPL, the joint ownership model, and allow this contribution under these terms."
How does that sound? We should make this implicit! ... if possible as all under US law (and in view of the overwhelming power of US lawyers ;-)).
When someone submits a patch, then we can assume that the submitter does not only allow but wants that his patch is used in the Zope codebase, under the well known conditions for the Zope code. I once had to sign such a patch use agreement for Python. It has been a 10 line patch including 6 lines of comment. Both me and Guido knew it has been pure stupidity to make such a fuzz about it, just to please lawyers.... Please check, whether it is possible that submitting a patch is sufficient that the patch can be used as far as the submitter is concerned. There may be other rights infringed. That still may need to be checked for significant changes. Dieter
Paul Everitt writes: <http://dev.zope.org/CVS/Contributor.pdf> The "Committer Agreement" does not seem to be even handed: The committer transfers rights immediately and indefinitely to Zope Corporation (the contributions become a gift to Zope Corporation). The agreement states explicitly that no rights are transfered to the committer. This is not a problem in itself. However.... My intention to contribute would be to strengthen the Open Source Movement. A statement that the supported code base (Zope) will remain open source and that committers will be able to use it (indefinitely) under terms comparable to the current ZPL would help to let the agreement to appear more balanced.... The "Commitrer Agreement" is quite threadening: A committer takes over a considerable risk (complete warranty and indemnification with respect to intellectual rights infringement). The risk is far higher than that of a (german) employee. German employment law recognizes that * all people make (sometimes) errors * coping with isolated errors is far easier for a larger community (the big employer) than a single individual. Therefore, it uses the term "Fahrlässigkeit" (carelessness). An employee has to take all care to not make errors during his work. If something bad happens due to slight carelessness (leicht fahrlässig), then this is a general risk which has to be taken by the employer. If serious carelessness (grob fahrlässig) was the cause, then the employee has to take the consequences for himself. We should have something similar for the committer agreement (not restricted to intellectual property rights!). Maybe something like an insurance for slight carelessness cases... Otherwise, commiting anything might easily ruin an individual. Especially with the strange US Patent Laws (where almost everything (such as presenting information in a popup window or integrating a Web Frontend with a baking oven) can be patented) and incredibly high damages amounts (5 billion for a smoker who got cancer) assigned in US courts. I will probably read replies to this message only in several weeks. Don't be surprised when I remain silent for some time.... Dieter
Dieter Maurer wrote:
Paul Everitt writes: <http://dev.zope.org/CVS/Contributor.pdf>
The "Committer Agreement" does not seem to be even handed:
The committer transfers rights immediately and indefinitely to Zope Corporation (the contributions become a gift to Zope Corporation).
This is an inaccurate representation. Transfer means you lose the rights and we gain the rights. Under joint ownership, both have rights. I think this point was abundantly clear, so I'm surprised to see you portray this as a gift.
The agreement states explicitly that no rights are transfered to the committer.
Because they never lost any rights.
This is not a problem in itself. However....
My intention to contribute would be to strengthen the Open Source Movement. A statement that the supported code base (Zope) will remain open source and that committers will be able to use it (indefinitely) under terms comparable to the current ZPL would help to let the agreement to appear more balanced....
I don't think it's really feasible to 100% guarantee things in the future. Rather, the agreement states that current code, and any contribution, will be available under the ZPL. Nothing can be retracted. If someone comes along and gives us one trillion dollars to stop releasing our work as open source, two things would happen: 1) First, we'd take the money. :^) 2) Second, all the existing code has to remain available under the ZPL. We just wouldn't do _new_ things under a ZPL. This is part of the safety of joint ownership. If you don't like what we do in the future, you still have rights on your contribution.
The "Commitrer Agreement" is quite threadening:
A committer takes over a considerable risk (complete warranty and indemnification with respect to intellectual rights infringement).
Yes. You can't make the risk disappear. Someone has to bear the risk. It makes zero sense for ZC to bear the risk of what goes on in someone else's brain. Even in the scenario of carelessness, a case will have to be made regarding what you knew and when you knew it.
The risk is far higher than that of a (german) employee. German employment law recognizes that
* all people make (sometimes) errors * coping with isolated errors is far easier for a larger community (the big employer) than a single individual.
Therefore, it uses the term "Fahrlässigkeit" (carelessness). An employee has to take all care to not make errors during his work. If something bad happens due to slight carelessness (leicht fahrlässig), then this is a general risk which has to be taken by the employer. If serious carelessness (grob fahrlässig) was the cause, then the employee has to take the consequences for himself.
We should have something similar for the committer agreement (not restricted to intellectual property rights!).
Maybe something like an insurance for slight carelessness cases...
Unfortunately we'd have to be the insurer. :^(
Otherwise, commiting anything might easily ruin an individual.
Instead, you'd prefer that it ruin ZC? Or are you asserting that somehow we could make it so that nobody would be held accountable?
Especially with the strange US Patent Laws (where almost everything (such as presenting information in a popup window or integrating a Web Frontend with a baking oven) can be patented) and incredibly high damages amounts (5 billion for a smoker who got cancer) assigned in US courts.
Unfortunately that's the jurisdiction in which we operate. --Paul
On Fri, 2001-09-28 at 08:32, Paul Everitt wrote:
Dieter Maurer wrote:
Paul Everitt writes: <http://dev.zope.org/CVS/Contributor.pdf>
The "Committer Agreement" does not seem to be even handed:
The committer transfers rights immediately and indefinitely to Zope Corporation (the contributions become a gift to Zope Corporation).
This is an inaccurate representation. Transfer means you lose the rights and we gain the rights. Under joint ownership, both have rights. I think this point was abundantly clear, so I'm surprised to see you portray this as a gift.
Hmm. So, the copyright to the contributed code is held jointly? or does the contibutor simply grant a non-exclusive license to Zope Corp (including the right to relicense)?
The agreement states explicitly that no rights are transfered to the committer.
Because they never lost any rights.
This is correct. The contributor gets access to the entire source code under the ZPL anyway, even without making a contribution. No additional rights need be asigned from ZC to the contributor, IMO.
This is not a problem in itself. However....
My intention to contribute would be to strengthen the Open Source Movement. A statement that the supported code base (Zope) will remain open source and that committers will be able to use it (indefinitely) under terms comparable to the current ZPL would help to let the agreement to appear more balanced....
I don't think it's really feasible to 100% guarantee things in the future. Rather, the agreement states that current code, and any contribution, will be available under the ZPL. Nothing can be retracted. If someone comes along and gives us one trillion dollars to stop releasing our work as open source, two things would happen:
1) First, we'd take the money. :^)
2) Second, all the existing code has to remain available under the ZPL. We just wouldn't do _new_ things under a ZPL.
This is part of the safety of joint ownership. If you don't like what we do in the future, you still have rights on your contribution
This prospect (of future ZC code being non-ZPL), while remote, is why I beleive that it is important that the ZPL be GPL-compatible. In that scenario (and I stress again that I think it is unlikely), where future ZC development was proprietary and unavailable to the community, it's important that it be possible for the community to respond by making subsequent community contributed code GPL, and therefore unavailable to proprietary vendors (trhis includes the hypothetical evil mirror-universe ZC, who will all have beards). Unless the ZPL is GPL-compatible (at least), this will not be possible, as it is currently not possible to create GPL licensed products that subclass ZPL'd Zope classes. I am *not* advocating that the opening of the CVS repository be held up for this, I just want to make sure that the goal of making the ZPL GPL compatible remains on the agenda.
The "Commitrer Agreement" is quite threadening:
A committer takes over a considerable risk (complete warranty and indemnification with respect to intellectual rights infringement).
Yes. You can't make the risk disappear. Someone has to bear the risk. It makes zero sense for ZC to bear the risk of what goes on in someone else's brain. Even in the scenario of carelessness, a case will have to be made regarding what you knew and when you knew it.
This is another area where I agree with Paul. Publishers frequently require authors to sign a 'warants and represents' clause that has the same effect. *Good* publishers still cover legal costs for unsuccessful lawsuits, so that the author isn't left hung out to dry when someone files a 'slapsuit'. I think the same standard should be applied here.
Otherwise, commiting anything might easily ruin an individual.
Instead, you'd prefer that it ruin ZC? Or are you asserting that somehow we could make it so that nobody would be held accountable?
The contributor should be held accountable in the event of a *successful* lawsuit. but it isn't reasonable to expect an individual to have to defend against frivolous lawsuits from large corporations.
Especially with the strange US Patent Laws (where almost everything (such as presenting information in a popup window or integrating a Web Frontend with a baking oven) can be patented) and incredibly high damages amounts (5 billion for a smoker who got cancer) assigned in US courts.
Unfortunately that's the jurisdiction in which we operate.
Thankfuly, our legal jurisdiction also has provisions for countersuing those who engage in underhanded legal tactics (such as slapsuits) for legal costs and damages, but a large corporation can still bankrupt an individual, making that option unavailable to them. This is why it is important for individuals to be protected from legal costs, unless the lawsuit is successful. If ZC doesn't take on the burden of defending against frivolous lawsuits (and countersuing where appropriate), then the individual contributor who faces a potentially bankrupting lawsuit, will probably simply withdraw the contribution, and where would that leave ZC? HTH, Michael Bernstein.
Hi Paul! Hi list! In the last couple of weeks I have really looked forward for the CVS to be finally opened. Not that I would be the first to be accepted as a contributor (my Python is still lousy, as Stephan Richter could tell you ...), but I read things from ZC like "We are too busy to get contributed patches from the tracker into the CVS!" and on the other hand guys like Martijn Faassen begging for being allowed to help ... So this decision will be the beginning of a new Zope age ;-) What I haven't found on the CVS site yet is anything about peer-reviewing contributions before they go into the main tree. While I sometimes have the feeling that there are fixes from ZC people that should NOT have made it into a release, there are many patches from the community that are not getting into a release for a long time (this is not a very scientific statement, just my personal feeling). We need rules like "NO FIXES BETWEEN FINAL BETA AND RELEASE" (Absolutely no fixes I mean) -- and those rules should apply to everybody. We maybe also need an improved process for designing new API extensions etc. One case for that is the Zope Internationalization Project (http://www.eurozope.org/zip/FrontPage), which better sooner than later should become a core project. I have the feeling that with the current Wiki approach it will take ages to agree on a syntax for internationalization in Zope. I don't mean that we need a single implementation. But we need an agreed-on syntax that is part of the standard Zope package, so that a ZPT or DTML Method will not break if it uses translation tags. Joachim
Joachim Werner wrote: [snip]
What I haven't found on the CVS site yet is anything about peer-reviewing contributions before they go into the main tree. While I sometimes have the feeling that there are fixes from ZC people that should NOT have made it into a release, there are many patches from the community that are not getting into a release for a long time (this is not a very scientific statement, just my personal feeling).
I imagine that the group will decide rules on peer reviewing. For comparison, the Mozilla group has very elaborate rules for checkins, while Python has pretty much an innocent until proven guilty culture. (That is, you check something in, and if somebody complains, it gets removed.) I don't think it is worthwhile trying to form these rules a priori.
We need rules like "NO FIXES BETWEEN FINAL BETA AND RELEASE" (Absolutely no fixes I mean) -- and those rules should apply to everybody.
Again, we'll let the rules come out of the group. For instance, what if an Emacs #foo.py# accidentally got checked in? Would you really require another beta release for that? Betas are a cost incurred by hundreds of people around the world. I think the group can do their best to adhere to a policy of doing beta cycles for minor changes.
We maybe also need an improved process for designing new API extensions etc. One case for that is the Zope Internationalization Project (http://www.eurozope.org/zip/FrontPage), which better sooner than later should become a core project. I have the feeling that with the current Wiki approach it will take ages to agree on a syntax for internationalization in
Ahh, the "it's the Wiki's fault" argument. I just checked the zip mailing list archive. 9 messages since Aug 1st. So neither email nor Wiki are good choices. Can you point to an example of a process that worked better for designing APIs? As for internationalization, I'm hoping that EuroZope (or ZIP) will recommend a strategy. I'm on the EuroZope list as well, and from what I can tell, there's still a ways to go before consensus is reached. Let's start a discussion over on EuroZope or ZIP and see if consensus can be reached.
Zope. I don't mean that we need a single implementation. But we need an agreed-on syntax that is part of the standard Zope package, so that a ZPT or DTML Method will not break if it uses translation tags.
Yes, that's needed quite badly. But I don't think this has to be done before we open the CVS to external contributors. --Paul
I imagine that the group will decide rules on peer reviewing. For comparison, the Mozilla group has very elaborate rules for checkins, while Python has pretty much an innocent until proven guilty culture. (That is, you check something in, and if somebody complains, it gets removed.)
I don't think it is worthwhile trying to form these rules a priori.
That's fine. I just wanted to put it onto the agenda ...
We need rules like "NO FIXES BETWEEN FINAL BETA AND RELEASE" (Absolutely no fixes I mean) -- and those rules should apply to everybody.
Again, we'll let the rules come out of the group. For instance, what if an Emacs #foo.py# accidentally got checked in? Would you really require another beta release for that? Betas are a cost incurred by hundreds of people around the world.
My personal opinion is that, apart from the version number, a final beta should be exactly the same as the actual release. Accidentally checked-in stuff can cause accidents. So there is some reason for a careful release policy. But in your specific case, if the "final" beta that should lead to a release has been actually released (and tagged in the CVS), how should somebody be able to check something into it afterwards? That could only happen if there are problems with the CVS configuration and usage I guess ...
Ahh, the "it's the Wiki's fault" argument. I just checked the zip mailing list archive. 9 messages since Aug 1st. So neither email nor Wiki are good choices. Can you point to an example of a process that worked better for designing APIs?
I don't blame the Wiki in general. Wikis (together with mailing lists) are a good start. Sometimes we'd just need real meetings on real conferences I guess ... Joachim
Paul Everitt wrote:
At last, the announcement I've been dying to make. After much deliberation -- meaning, I've procrastinated for too long :^) -- I'm pleased to announce our approach for opening the CVS repository to community checkins.
Cool, at last!
This says 'you must indicate your agreement to the term below'; shouldn't it be 'terms'? Regards, Martijn
Martijn Faassen wrote:
This says 'you must indicate your agreement to the term below'; shouldn't it be 'terms'?
Uhh...well...yes! I'll make the change. I'm waiting for news back from the lawyer about provisions for handling patches. I'll then post a new rev of the materials. Does anyone think this is close enough that I can go ahead and get the bootstrap group (under ten, selected by us) going? I'd like to avoid making them sign and mail an agreement, then do it again if there's substantive changes. --Paul
Paul Everitt wrote:
Does anyone think this is close enough that I can go ahead and get the bootstrap group (under ten, selected by us) going? I'd like to avoid making them sign and mail an agreement, then do it again if there's substantive changes.
Yup :-) Chris
Does anyone think this is close enough that I can go ahead and get the bootstrap group (under ten, selected by us) going? I'd like to avoid making them sign and mail an agreement, then do it again if there's substantive changes.
Go for it.
On Tue, 2001-09-25 at 05:27, Paul Everitt wrote:
Does anyone think this is close enough that I can go ahead and get the bootstrap group (under ten, selected by us) going? I'd like to avoid making them sign and mail an agreement, then do it again if there's substantive changes.
Full speed ahead, and damn the torpedoes! Michael Bernstein.
On Tue, 25 Sep 2001 08:27:13 -0400, Paul Everitt <paul@zope.com> wrote:
Martijn Faassen wrote:
This says 'you must indicate your agreement to the term below'; shouldn't it be 'terms'?
Uhh...well...yes! I'll make the change. I'm waiting for news back from the lawyer about provisions for handling patches. I'll then post a new rev of the materials.
Does anyone think this is close enough that I can go ahead and get the bootstrap group (under ten, selected by us) going? I'd like to avoid making them sign and mail an agreement, then do it again if there's substantive changes.
Yes, I think it is close enough to get started. Toby Dickenson tdickenson@geminidataloggers.com
On Thu, 20 Sep 2001 16:13:57 -0400 (Eastern Daylight Time), Paul Everitt <paul@zope.com> wrote:
So, let's begin what I'm sure will be a lively and illuminating discussion. :^)
A question about "Joint Ownership".... The ZPL currently includes a no-liability clause. If one half-owner were to make the source available under a different license without such a clause, would the other half-owner be liable too? Toby Dickenson tdickenson@geminidataloggers.com
participants (10)
-
Chris Withers -
Dieter Maurer -
Joachim Werner -
Martijn Faassen -
Michael R. Bernstein -
Morten W. Petersen -
Paul Everitt -
R. David Murray -
Toby Dickenson -
Zopista