Re: SDO IP Issues, was: SDO Java M3 Release Candidate RC1
On 3/21/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Mar 20, 2007, at 1:11 PM, Frank Budinsky wrote: I've confirmed that IBM, the copyright holder, gives permission to Apache to reuse the two EMF files in question. Thanks for confirming this. I've opened TUSCANY-1185 to contribute the two base classes, provided in an attachment. Jeremy, let me know if this is good enough for you, or if you still want me to remove the Tuscany subclasses and resubmit them. I can't ack this for the ASF - that has to be done by an Officer as described in the IP Clearance process. They would probably want something official from IBM (Software Grant). I am a director of the ASF. Apparently the original copyright holder desires to contribute the same code to two different places under two different licenses. They are certainly within their rights to do so. The contribution under the other license isn't particularly relevant to me. Now, concerning the contribution which is presumably being made in good faith under the ASF license to the Tuscany project, I see no ASF wide legal or policy issue here, which means that the only remaining issue a technical one, namely whether or not tuscany wishes to accept this code. Now, if anybody has any reason to believe that the assertion of authorship is false (i.e., if there are Eclipse CVS or SVN logs which show contributions by others), then the issue is an entirely different one... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
On 2/8/07, Jeremy Boynes [EMAIL PROTECTED] wrote: So I think we need a branch to do this stabilization work I'm disturbed by this proposal as I don't think we have consensus in the community yet on this issue. This is not an issue that requires consensus. I've referred previously to a memo tited 'rules for revolutionaries'[1] which addresses the need to reduce friction in times like these. If the issue here is that trunk is unstable, then we should stabilize trunk. That would be wonderful. But let's put that in concrete terms. At least one individual (and possibly several) is interested in working on the 'BigBank' end to end scenario. Other (others?) are interested in verifying fixes to issues reported in JIRA. Which would minimize friction more? Allowing that work to proceed in a branch, or for that individual (or individuals) to start exercising their right to veto any change that impedes their progress? The latter approach would put a significant, albeit short term, damper on refactoring efforts, independent of the long term value in said refactoring. So, to put a not so fine point on it, it would represent essentially a moratorium on all but the most insignificant refactoring efforts. Is that what this group wants? If so, another way to proceed is for the project to adopt a 'review then commit model', whereby all changes are proposed for discussion and voted on before commits are made. Projects which place a high premium on stability, like the Apache HTTPD project operate in this way everyday. - Sam Ruby [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
On 2/8/07, Jeremy Boynes [EMAIL PROTECTED] wrote: On Feb 8, 2007, at 11:41 AM, Sam Ruby wrote: On 2/8/07, Jeremy Boynes [EMAIL PROTECTED] wrote: So I think we need a branch to do this stabilization work I'm disturbed by this proposal as I don't think we have consensus in the community yet on this issue. This is not an issue that requires consensus. I've referred previously to a memo tited 'rules for revolutionaries'[1] which addresses the need to reduce friction in times like these. Consensus may have been the wrong word - common understanding of what the branch is for might have been better phrasing. There's been talk about stabilizing for a release (which is often when branches are used for), but also about developing new features (which is usually done in trunk). Is this someone's personal environment, or a revolution? I simply don't know. It actually is unknowable. It is the nature of the work. The branch could go nowhere. It could become the basis for people to quickly these scenarios to the trunk. It could expose problems earlier than would otherwise be found on the trunk. At a minimum, it will not disrupt continued progress on the trunk, and by being done in the open and under a compatible license, it can be readily cannibalized at any point. I think consensus here though is important - not on whether we create a branch but in the impact this has on how we develop as a community. We were working together, all of a sudden something has changed and now we have friction. That's what we need to fix. Reviewing the archives, what I see is mounting frustration, one that would benefit from a release valve. No-one seems to be questioning that the work that is going on in the trunk is necessary, the only is growing recognition that more parallelism is required. If the issue here is that trunk is unstable, then we should stabilize trunk. That would be wonderful. But let's put that in concrete terms. At least one individual (and possibly several) is interested in working on the 'BigBank' end to end scenario. Other (others?) are interested in verifying fixes to issues reported in JIRA. Which would minimize friction more? Allowing that work to proceed in a branch, or for that individual (or individuals) to start exercising their right to veto any change that impedes their progress? The latter approach would put a significant, albeit short term, damper on refactoring efforts, independent of the long term value in said refactoring. So, to put a not so fine point on it, it would represent essentially a moratorium on all but the most insignificant refactoring efforts. Is that what this group wants? I don't know. Actually, I would seriously doubt it. One of the factors here is the change in the spec APIs from 0.95 to 1.0 which had many incompatible changes. I think we all want to support 1.0 but reality is that all of our samples, end-to-end scenarios and itests are written against the 0.95 level. We knew evolution to 1.0 would be disruptive which is why we have a pre- spec branch as a baseline for ongoing development at the 0.95 level; it seems like some friction is coming because this is not working and perhaps tackling that will make things smoother. Perhaps. But it is also possible that a branch that is closer to the current trunk would be less disruptive long term. And not necessarily just one branch, this process could conceivably even repeat periodically, and eventually converge. People have talked about working on scenarios and Jira issues, but it's not clear if they are intending to do that at the 0.95 level or at the 1.0 level. If at the 1.0 level, the harsh reality is that we don't have a 1.0 level runtime yet to support them - some of us are working on it but it's not done yet. I think joining in that work is the most effective way to get something that can run 1.0 level scenarios, but if people want to start a branch and do it there that's cool too. At some point you hit the mythical man month nine women, one baby issue. re: if people want to start a branch and do it there that's cool too. +1 If so, another way to proceed is for the project to adopt a 'review then commit model', whereby all changes are proposed for discussion and voted on before commits are made. Projects which place a high premium on stability, like the Apache HTTPD project operate in this way everyday. I've been wondering about that too - not for stability, but for the community-building aspect. It's certainly a better option than throwing vetos around. Geronimo recently had this imposed on them. It was just the jolt that they needed, but once that was accomplished, it was quickly disposed of. My thoughts are that it is an option to consider, but one not to be taken lightly. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content for next milestone
On 2/8/07, Jim Marino [EMAIL PROTECTED] wrote: - To satisfy those requirements, is the intent to do that significant work in branch and how will it be moved into trunk? Or, is it intended that the work be done in trunk and rolled into branch? In times like these, generally the intent is to do the work and then to assess based on taking a look at the actual code what the best path forward is. Until that code is written, it is premature to speculate what the outcome will be. - If it is the latter, how is this any different than the process of using Maven snapshots that we have already set up? - If the goal is to do significant work in branch, what happens when changes in trunk are incompatible with new work in the branch? As I understand it, the goal is to do whatever it takes to get some specific user scenarios working. Whatever it takes generally includes changes. Given the discussion to date, I think that it is taken as a given that some portion of the changes in the trunk will be incompatible with the work done in this branch. The only way to prevent this is to either cease work on the trunk, continue to impede progress towards getting these scenarios working, or a branch. I'm all for people doing revolutions or blowing off steam but more clarity and discussion about what is going on would be helpful for me. Referring to this as blowing off steam is counter productive. Getting the scenarios working is productive, even if only 85%, 65%, or 35% of the work ultimately ends up being reusable. The other question I had is how this relates to the release process others of us are working toward that was started back in January. I think having this branch called the next milestone release is confusing. I'm all for simultaneous release processes if that helps ease friction or provides people what they need but what then do we call the work going on in trunk? In keeping with our Italian theme and the idea of blowing off smoke, maybe the branch can be tagged fumo :-) Are there some precedents for this in other projects? This I agree with. Statements or nomenclature that imply any form of succession cause friction. Jim - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts]
More than 72 hours have passed, and presumably everybody on the incubator PMC that cares to vote has done so (Thanks Robert!). Please proceed with the release. If anybody objects to this process, point them my way. - Sam Ruby Original Message Subject: [VOTE] Ratify Tuscany PPMC vote to release DAS for Java M2 artifacts Date: Sun, 5 Nov 2006 14:10:40 -0800 From: Luciano Resende [EMAIL PROTECTED] Reply-To: general@incubator.apache.org To: general@incubator.apache.org The Tuscany PPMC has voted to Release DAS for Java API Implementation as part of the M2 release. In accordance with Incubator release procedures we are asking the Incubator PMC to approve this release. Vote thread : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg10257.html Vote result : http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg10373.html The release candidate is available at: http://people.apache.org/~kelvingoodson/das_java/RC4b/http://people.apache.org/%7Ekelvingoodson/das_java/RC4b/ The release is taged at : https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubator-M2/ What's new in DAS Java M2 DAS Core features - MySQL support - Static Data Objects - Dynamic root for static graphs - Unique attribute on relationships - Explicit ResultSet shape definition - Improved logging - Programmatic Configuration - Helper for empty SDO Graph - Convention over configuration - Column named ID is the PK - Column named xxx_ID is the FK to table xxx DAS Samples - Tomcat integration and automated DAS samples testing (htmlUnit) - DAS Samples now have all dependencies and source code inside the sample war For detailed user documentation and feature descriptions, access Tuscany DAS Wiki page - http://wiki.apache.org/ws/Tuscany/TuscanyJava/DAS_Java_Overview https://svn.apache.org/repos/asf/incubator/tuscany/tags/java/das/1.0-incubator-M2/ Thanks - Luciano Resende - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving chianti to trunk
Jim Marino wrote: On Jul 19, 2006, at 2:07 AM, Simon Nash wrote: I wasn't asking for an official policy statement on this, and I wasn't suggesting that we stop all innovation and move into a phase where we only work on things that were part of M1. By releasing M1, we moved from a phase of focusing purely on the developer community into a phase of starting to attract potential users as well. I think we need to strike a balance between the needs of developers and users. We met some potential users at ApacheCon, and I expect that we will meet more at OSCON. For now we can point them to M1, but given our desire to focus around a single codebase that is actively being enhanced, I would expect that we would want to be able to start to point these people to the new codebase in the fairly near future. And we should. In fact, I would point them at the new code now, not just in the future. That is the codebase chosen by the community. That is our code. If you believe the decision to adopt chianti as our code to be in error, you are free to ask the community to reconsider, although I believe the vote last week accurately expressed the community will (as willful an act as it may have been ;-) ). Of course, people can also resort to M1 if they prefer to experiment with the .9 version of the SCA specification or features specific to that milestone. If history is any guide, the path that has been chosen will result in another revolution in a year or so's time, reverting a number of architectural decisions that have been made with this revolution. However, not *all* will be lost as much of the additions will also have been retained. What will have been lost is much time. The Rules for Revolutionaries was penned in a time when Tomcat 4 was poised to replace Tomcat 3. Tomcat 5 was the inevitable result. Even from a developer community standpoint, I think there is considerable value in maintaining a working base level of functionality that can support end-to-end scenarios. This allows developers creating new code to exercise that code in the context of real-world usage, in addition to unit tests. I would imagine there is unanimous agreement on this point as we are working hard to add real-world functionality that interests members of the community. Based on your statements, it sounds as if there is functionality you would like to see added. The somewhat, although not completely, flippant response to this is: Thanks for volunteering! Votes work best when the victors are understanding and gracious. This response treads awfully near towards being rather gloating. If you would like to see a particular set of functionality in Tuscany you can either request it (preferably in JIRA) or develop it and submit a patch. Depending on the importance of the feature to the community, I suspect the latter approach has a higher probability of success in the short-term. It is also the option I would personally prefer as it expands the active, contributing segment of the community. Votes in the ASF imply a level of commitment. They mean I will stand behind this course of action and make it work, not Hey! I won! Deal with it!. If there are things that used to work in the M1 trunk that aren't yet handled completely in Chianti, then I fully expect those that participated in this vote to pro-actively and expediently work to close those gaps. And with an eye towards giving the benefit of the doubt to the codebase it replaces (i.e., no: see, it didn't handle this obscure edge case, so the entire function wasn't fully implemented in M1, and yes, I've been around the block once or twice). The alternative is for the people who voted to say that the rules for voting weren't fully explained to them, in which case, I will simply say my bad, and we can hold the vote again. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Rules for Revolutionaries [was: M2]
Jeremy Boynes wrote: Ant I'm disappointed that you have chosen this path. I will ask one more time if you and Sebastien would consider collaborating with those of us working on core2. A while ago, I agreed to be a mentor for this project. I guess it is about time that I start acting like one. If this project ever hopes to exit incubation, it had better start acting like an ASF project. For starters, I suggest that all committers read the Rules for Revolutionaries[1][2][3]. For those who want the Cliff notes version: anybody who wants to work in an evolutionary fashion on the main trunk is welcome to do so. Anybody who wants to work on a revolutionary branch is welcome to do so. Multiple concurrent revolutionary branches are OK too. One thing that is decidedly NOT OK is to include a version number in the name, as it causes friction. Hence, I'd suggest that core2 immediately get renamed to something that neither reflects the term core or the number 2. Something implicit in the R4R document is that the burden of proof is on the revolutionaries. If you would like to see your particular branch merged back onto the trunk, be prepared to demonstrate why your particular branch is not merely better, but necessary. My experience it that the more concrete and the less hand-wavy the argument, the more likely it will be accepted. So, if you chose to believe that scenarios and test cases are optional, just remember, merging your sandbox back to the trunk is optional too. That does not mean that scenarios and test cases are required, but it does mean that if these aren't present, you need to come up with something just as compelling. - Sam Ruby [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html [2] http://incubator.terra-intl.com/rules-for-revolutionaries.pdf [3] http://marc2.theaimsgroup.com/?l=apache-communitym=105712356508947 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
