My conversation with Barb at EMO-IP===========================Begin forwarded message: Date: 11 October 2008 10:32:25 BST Subject: Re: A predicament with Jaxen
Hi Barb,
Thanks for the explanation, but in fact I already understood this much. What I was curious about is why the SVN dependencies are considered pre-exempt. Since my goal is (was?) to get Jaxen okayed for interim use, and not to rock the Subversive boat, I think it is probably best to simply say "Thanks Barb" and let the matter lie :-)
My plans are to call Nick White next Wednesday if he has not responded by then.
Cheer, Joel
On 10 Oct 2008, at 22:41, Barb Cochrane wrote: Hi Joel, I’ve checked a little further, and it’s my understanding that in SVN’s case, there was an “exempt pre-req” determination. 4. "pre-req" dependencies fall into two cases: "exempt pre-req" and "non-exempt pre-req". This determination is made by the EMO with input from the relevant PMC and project leadership. a. A pre-req may be classified as "exempt" by the EMO if the software is pervasive in nature, expected to be already on the user's machine, and/or an IP review would be either impossible, impractical, or inadvisable. Exempt pre-req's can be approved for use by the EMO without IP review. Examples: Windows XP, Sun JRE. However, an exempt pre-req may be disallowed by the EMO at its discretion. b. If a pre-req is non-exempt, it must go through the IP review process and be approved or non-approved for use as a pre-req. Based on the foregoing, we would categorize Jaxen as a “non-exempt pre-req”. It has gone through the IP review process, and was not approved for use as a pre-req. I hope this helps. Cheers, Barb P.S. Look forward to hearing back from you on Spring. Just a heads up that it is a statutory holiday here in Canada on Monday. I’ll be in the office on Tuesday as usual. On 8 Oct 2008, at 18:26, Barb Cochrane wrote:
I’ll have to ask around about Subversion because I haven’t worked with that project and don’t know the particulars at all. I’ll get back to you as soon as I get some answers. Fine
Re Spring, since you got further than we did on your first try, it’s probably best if at least the first call comes from you. You can plead your case as to what great things you’d like to do with Spring, and then ask if he would be willing to entertain a couple of questions from the EF. Sound good? Sounds like a plan. I will leave it till mid next week then have a go if they have not replied yet.
On 8 Oct 2008, at 17:50, Barb Cochrane wrote: “Does your response mean that we cannot even use it privately amongst the team?” Not sure what you mean by “privately amongst the team”, but if you mean that it is not now nor will it be placed in CVS, and if it is used solely as a tool and not for redistribution, then there is no restriction on that kind of use. Yes exactly. Someone from the team will create the bundle to fulfil the Jaxen dependency and then email it to the team members. It will never be in CVS/SVN. Btw, I am just curious, but how come Subversion is able to use the separate download route? What are the guidelines around when that is acceptable? “PS - also still no response from Spring I gather?” No, I was hoping they had replied to you privately. It seems as though you got at least one step further than we did there…..have they gone silent again? No, I surely would have let everyone know with loud band playing. Nick White is the CFO at SpringSource and he was given to me as the "right guy" by a staff member in their UK office. Of course he could be on holiday, etc., but people generally send an automated response in those case. The last step is that I have Nick's direct dial phone. I figured on waiting until next week before discussing a phone call. But as long as we are on the topic, if it comes to that do you think I should follow up or would it be better if the call came from the EF? I have already been that route with Jaxen and had as much success as you did :-( I have a very hard time understanding OS projects that fail to at least communicate when they are asked for this type of assistance. I can understand there not being willing to go a lot of effort, but at least they could be polite and say "sorry I (we) am not in a position to sort this out". sigh... Does your response mean that we cannot even use it privately amongst the team? PS - also still no response from Spring I gather? On 8 Oct 2008, at 17:24, Barb Cochrane wrote: Boy, we’d really like to help you out here and say we are okay with this being an exempt pre-req, but we’re very uncomfortable giving +1 on code that has known pedigree issues. Let us know if you would like to try to confirm code provenance with Jaxen as you are trying with Spring. You may have better luck with Jaxen than we did. We can give you the contact names we have if you’re interested. I would appreciate your advice on this. The architecture of ORMF in the initial contribution relies on the dom4j xpath facility, which unfortunately pulls in Jaxen. Since the Jaxen team has been uncooperative on IP matters it is not reusable in Eclipse. The ORMF team is moving away from dom4j in any case in preference to reengineering the framework with EMF. Therefore the Jaxen issue is a short term one of the next six months or so. This does give us a short term problem however. Minimally we would like to have ORMF running end to end again when we complete our migration to OSGi at the end of the first iteration (M1). This would enable us to put functional regression tests in place before we started our EMF reengineering. This would require that the team share copies of a plug-in that provides Jaxen on a private basis, i.e. it would not go into the ORMF repository. What would be better is if we had the permission of the EMO IP team to to allow users to download a copy of the Jaxen plug-in from a none Eclipse site to complete the dependency. This would give us the ability to allow the community to play with and evaluate early release of ORMF. I would site the precedence of Subversive as having a similar dispensation. P Please consider the environment before printing this e-mail. Thank you.
|
