Re: [VOTE] - Ratify Tuscany PPMC vote to release SDO for Java M2 artifacts
On 11/3/06, kelvin goodson [EMAIL PROTECTED] wrote: Hi, I wonder if I could draw your attention to this vote ratification please? Nobody has raised any show-stopping objections to any of the content. On the other hand, nobody has voted yet. I have been reading all the helpful suggestions made in this thread and I have been reporting back on my activities in the light of those suggestions in my earlier posts to this thread. This vote thread has turned into a lot of discussion, how about we take it back to tuscany-dev to make sure we've sorted out all the issues as much as possible and then bring it back here for a fresh vote on a new thread. ...ant
Re: How to get a source OFBiz release WAS: [VOTE] OFBiz Test Snapshot Release: 4.0.0 TS5
On 11/2/06, Jacopo Cappellato [EMAIL PROTECTED] wrote: Hi all, hi Jacopo based on past comments in this list I'd like to add that this is a pre-built release (e.g. the objects and Derby demo database are already set up and packaged in the distribution); we did this because it can take up to 20 minutes (with slower hardware) to build the whole project from scratch and this could waste too much of your (and that of the persons that just want to give a look at it) time. i think some confusion has arisen over the terms we use. in apache terms, a source distribution is a plain export from the source repository whereas a binary distribution is anything else. lots of projects here ship binary releases with source in: just because a release contains some source it doesn't make it a source distribution binary distributions are mainly for the convenience of users. source distributions target other audiences including (potential) developers, downstream packagers and archivists. they are quick and easy to create (all the release manager needs to do is export the tag and compress) so it's recommended that source distributions are produced for each release as well as any binaries. However, if you want to play with a clean source distribution (for example, if you want to run the RAT tool etc...), just run the clean-all ant script: all the objects and the db will be removed. run RAT against binary and source distributions of a release but not very many binary checks have been automated yet. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Publish Yoko M1 release
On 10/31/06, Mosur Ravi, Balaji [EMAIL PROTECTED] wrote: Reminder: Please take a look at the proposed release and vote on it. So far, we have a +1 from Robert. it's a good release :-) hopefully some of the mentors will jump in sometime soon (it might be worth someone giving them a gentle prod) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to bring code to Apache?
The important part here is not to validate the process but the provenance of the code being contributed. It does not matter whether the code was developed in an open or closed manner, by one individual or by many, what we have a responsibility to establish is that the code can legally be contributed to the ASF. Unlike an employer, the ASF has no initial rights to any code; those are granted to it through the ICLA when the code is contributed. We operate on an ongoing assumption that the committer abides by the ICLA and does actually have the rights to contribute that code. However, for any body of code we (the ASF) should have the ability to ask the committer to reconfirm this, especially if there is increased potential that the IP for the code is not owned solely by them (as would be the case if it was developed by multiple people or for an employer outside a CCLA). AIUI, that is the role of the IP Clearance process: to obtain that confirmation. The openness of the development process used is only relevant here to the extent that it exposes the provenance of the code - an open process allows us to backtrack and see who created the code and owns the IP. It's much more of an issue for the receiving PMC in gauging the health of the community. I'd suggest changing that part to something like the important part is whether anyone else may own any of the code, for example if it was developed with other people or as part of your job -- Jeremy On Nov 3, 2006, at 2:09 PM, Henri Yandell wrote: On 11/3/06, Daniel John Debrunner [EMAIL PROTECTED] wrote: Henri Yandell wrote: [snip] Any thoughts on the below? [snip] the important part is that the code was developed outside of the ASF SVN repository and the ASF public mailing lists. I struggle with what that really means. Code is technically developed in IDEs on people's machines, not on mailing lists. Agreed - to the point that I used the text on the documentation page rather than trying to paraphrase it. The other phrase I've heard is: Created using the ASF development process If I create a new file for an ASF project it's developed on my machine and subsequently committed to the project or posted as a patch. So for sometime the new file was outside the ASF SVN repository and not visible on a public mailing list. What really makes something developed inside the ASF? - intention to contribute to a project? Definitely not. - JIRA entry created before the file is created? Not important. - discussion in mailing list before the file is created? Openness is a lot of it - so this is often a good example of openness. - creating the file in a local SVN copy from the ASF SVN? I think this can be a warning sign. If a large 'svn add' commit is done, then it's a warning sign to ask whether the change was developed openly. The barracks-lawyer (aka pain in the arse) in me looks at the documentation and thinks What if it was on a public asf mailing list, was by people with asf clas but didn't use the svn repos?. I think getting the answer for that would not be worth the small effort required to file an ip clearance - but if the style was to have an external svn and then slowly bring pieces over, it might be worth figuring it out. Biggest question here would be 'why not the asf svn?'. Another case that is interesting is 'the big rewrite' style of commit. If someone works on the next version of their project on their own and then code dumps a lot of changes in, that also seems like it's going to need IP clearance. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] - Ratify Tuscany PPMC vote to release SDO for Java M2 artifacts
On 11/4/06, ant elder [EMAIL PROTECTED] wrote: On 11/3/06, kelvin goodson [EMAIL PROTECTED] wrote: Hi, I wonder if I could draw your attention to this vote ratification please? Nobody has raised any show-stopping objections to any of the content. On the other hand, nobody has voted yet. I have been reading all the helpful suggestions made in this thread and I have been reporting back on my activities in the light of those suggestions in my earlier posts to this thread. This vote thread has turned into a lot of discussion, how about we take it back to tuscany-dev to make sure we've sorted out all the issues as much as possible and then bring it back here for a fresh vote on a new thread. FWIW i would have +1'd the release after the clarification about the software grants but i've been away without internet midweek. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get a source OFBiz release WAS: [VOTE] OFBiz Test Snapshot Release: 4.0.0 TS5
Robert, others interested, I'm still not sure whether or not we will want to do this going forward because I'm not sure how a source distribution would be used for a project like OFBiz. Still, if there is any demand for it then I agree we should do it. However we go in the future, this would be a good thing to include in our Test Snapshot process, so I've added src distribution files for this release. They are listed on the release page here: http://docs.ofbiz.org/x/wAE For convenience I'll including the URLs below as well. Thanks again to everyone for reviewing this and for help in moving OFBiz through the incubation process. -David http://people.apache.org/~jonesde/apache-ofbiz-incubating- src-4.0.0.TS5.tgz http://people.apache.org/~jonesde/apache-ofbiz-incubating- src-4.0.0.TS5.tgz.asc http://people.apache.org/~jonesde/apache-ofbiz-incubating- src-4.0.0.TS5.tgz.md5 http://people.apache.org/~jonesde/apache-ofbiz-incubating- src-4.0.0.TS5.zip http://people.apache.org/~jonesde/apache-ofbiz-incubating- src-4.0.0.TS5.zip.asc http://people.apache.org/~jonesde/apache-ofbiz-incubating- src-4.0.0.TS5.zip.md5 On Nov 4, 2006, at 5:20 AM, robert burrell donkin wrote: On 11/2/06, Jacopo Cappellato [EMAIL PROTECTED] wrote: Hi all, hi Jacopo based on past comments in this list I'd like to add that this is a pre-built release (e.g. the objects and Derby demo database are already set up and packaged in the distribution); we did this because it can take up to 20 minutes (with slower hardware) to build the whole project from scratch and this could waste too much of your (and that of the persons that just want to give a look at it) time. i think some confusion has arisen over the terms we use. in apache terms, a source distribution is a plain export from the source repository whereas a binary distribution is anything else. lots of projects here ship binary releases with source in: just because a release contains some source it doesn't make it a source distribution binary distributions are mainly for the convenience of users. source distributions target other audiences including (potential) developers, downstream packagers and archivists. they are quick and easy to create (all the release manager needs to do is export the tag and compress) so it's recommended that source distributions are produced for each release as well as any binaries. However, if you want to play with a clean source distribution (for example, if you want to run the RAT tool etc...), just run the clean-all ant script: all the objects and the db will be removed. run RAT against binary and source distributions of a release but not very many binary checks have been automated yet. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get a source OFBiz release WAS: [VOTE] OFBiz Test Snapshot Release: 4.0.0 TS5
On 11/4/06, David E Jones [EMAIL PROTECTED] wrote: Robert, others interested, I'm still not sure whether or not we will want to do this going forward because I'm not sure how a source distribution would be used for a project like OFBiz. the same way it's used for any other project: as a record of the exact source that created the binary distributions. the source is the release. the binaries are conveniences for users. Still, if there is any demand for it then I agree we should do it. there's already demand from people on this list. we like source :-) in addition, downstream packagers prefer source distributions so they can patch and package them for their particular target platforms. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get a source OFBiz release WAS: [VOTE] OFBiz Test Snapshot Release: 4.0.0 TS5
On 11/4/06, robert burrell donkin [EMAIL PROTECTED] wrote: the same way it's used for any other project: as a record of the exact source that created the binary distributions. the source is the release. the binaries are conveniences for users. +1. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to get a source OFBiz release WAS: [VOTE] OFBiz Test Snapshot Release: 4.0.0 TS5
Unless we change the name to open binary, I'm going to agree with Robert and Justin. Source releases are what we're about here. Craig On Nov 4, 2006, at 10:10 AM, Justin Erenkrantz wrote: On 11/4/06, robert burrell donkin [EMAIL PROTECTED] wrote: the same way it's used for any other project: as a record of the exact source that created the binary distributions. the source is the release. the binaries are conveniences for users. +1. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: clarification on SF license and sandboxes
I notice that the current JIRA attach file form does not default anything, and requires the submitter to choose explicitly the copyright status for the submission. (I think this is a change from previous behavior, and if so, a very welcome change). So it's now very clear that the user must choose whether the submission is intended as a contribution. As far as I'm concerned, this issue is now resolved. If a JIRA submission is marked as Attachment not intended for inclusion it should not be used. Thanks to everyone who commented. Craig On Nov 4, 2006, at 5:08 AM, robert burrell donkin wrote: On 11/2/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Martin, Thanks for your comments. They seem to contradict what Henri is saying. Can we continue this discussion until we reach some conclusion? from a legal perspective: 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. selecting the 'no' checkbox seems to reasonably explicit to me however, if copyright cannot be claimed on a patch then this is not relevant. AIUI US copyright law does not allow copyright to be claimed on unoriginal works or technical works capable of only one reasonable and correct solution. some bug fixes fall into this category. so, it isn't always necessary to gain explicit permission but it's almost always a good idea. from an ethically perspective, i think that an effort should be made to gain active permission whenever the user does not make their intentions clear. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
