Re: Issues with XMLBeans proposal
Greg Stein wrote, On 08/07/2003 9.58: On Fri, Jul 04, 2003 at 08:43:36AM +0200, Nicola Ken Barozzi wrote: Greg Stein wrote, On 04/07/2003 1.24: ... Agreed. That's what I was trying to say, and my read on the board.. ... You guys are misconstruing my statements. Greg, I'm trying to explain in my own words what you have said. I agree with you :-) And no, Jakarta is not just about "server side Java", when you look at things like Gump, Regexp, Taglibs, etc. +1 When Grisha Trubetskoy wanted to contribute mod_python to the ASF, a good number of people called for creating a 'python' TLP. I'd do it when they'll donate Python itself ;-) Does wishful thinking work? Believe me, I suggested that years ago. The Python Software Foundation was started instead (Dick Hardt and I crafted the PSF bylaws based on the ASF's bylaws). The main backers of a PSF effort thought that the ASF was still too confusingly tied to the Apache HTTP Server (despite my protests). I think if we asked again, today, that the answer would be that Apache stands for much more. But the PSF has got its own momentum now, so there wouldn't be much benefit for them to fold up and merge the Python assets into the ASF. Thanks for the explanation :-) Why not add them as a "sister project"? . (No replies necessary here, the "sister project" idea has some tangled implications with another discussion, but you can still read it with your Pythonic hat on ;-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
On Thu, Jul 03, 2003 at 10:12:17PM -0400, Andrew C. Oliver wrote: > On 7/3/03 7:24 PM, "Greg Stein" <[EMAIL PROTECTED]> wrote: > >> 3. Jakarta - IMHO this the best place for it. > >> > >> The division of XML vs Jakarta predates me for certain, but I think the main > >> issues surrounding that are rusty. > > > > The problem is Jakarta itself. Centering a PMC around a *language* rather > > than functionality is the inherent problem. These questions will continue to > > arise over and over. > > What's done is done. As a Jakarta committer I always feel like the guy > wearing a "I'm here I'm queer deal with it" shirt at a Republican National > Convention. Heh :-) Oh, what was done [Jakarta] was done *very well*. Don't get me wrong on that. I'm simply trying to point out that a language-oriented PMC is going to continue to cause decision-making problems like this. Am I suggesting unwinding Jakarta *because* it is language-oriented? Not at all. I *would* like to see more TLPs spin out of Jakarta, though. The Board doesn't have near enough insight into the major Jakarta projects: Tomcat, Struts, Turbine, Velocity, Gump, etc. > > When Grisha Trubetskoy wanted to contribute mod_python to the ASF, a good > > number of people called for creating a 'python' TLP. The Board decided to > > stop perpetrating the per-language concept. Instead, mod_python was added to > > the Apache HTTP Server Project (it *is* a module for Apache httpd, after > > all). mod_php, mod_perl, and mod_tcl fall under the same argument, of > > course, but they get a Grandfather Pass :-) > > I'm getting de ja vu... You don't like this community. I get it... I'll > file this on the appropriate file system for such information. So Jakarta > is the grandfather of them all... Etc etc Feh. I didn't say that, and you know it :-) The community is just fine and has done great stuff. I think the language focus of the Jakarta, Perl, PHP, and TCL TLPs is the wrong axis for slicing up where to put codebases. I also think Jakarta is "too big" and needs to spin out some TLPs. But "don't like this community" ?!?! Hah. >... > I agree. The question for them: "Are you a good witch or a bad witch?" ;-) Euh... :-) Cheers, -g -- [EMAIL PROTECTED] ... ASF Chairman ... http://www.apache.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
On Fri, Jul 04, 2003 at 08:43:36AM +0200, Nicola Ken Barozzi wrote: > Greg Stein wrote, On 04/07/2003 1.24: > >On Thu, Jul 03, 2003 at 04:22:10PM -0400, Andrew C. Oliver wrote: > > > >>... > >>1. Top level project - IMHO this isn't big enough and you don't have the > >>open source experience or robust community to pull that off (not intended > >>to > >>be a criticism) > > > >There is no size minimum for a TLP, but I believe the Board would want to > >see the PMC has more direct experience at the ASF. So yes, I don't see that > >the Board would approve constructing a new PMC for this. > > As incubation goes, making a project a TLP right away is a *major* > problem. If it isn't already a big and stable project with knowledge of > Apache rules and a big sane OS community around it, I really prefer it > to be under another PMC that can do the "practical" part of the incubation. Agreed. That's what I was trying to say, and my read on the board. >... > At that time it made sense. Java is not only a language, and is so > separated from other environments, that it was IMHO the only way of > aggregating enough resources to launch something out of it. > > But things that go well one time (and Jakarta has been a major success), > don't necessarily go well the second. You guys are misconstruing my statements. The language focus of Jakarta creates an inherent problem in deciding where to put anything that happens to be written in Java. There isn't anything wrong with Jakarta (other than its size, imo), and the decision to create it in the first place was quite proper. And no, Jakarta is not just about "server side Java", when you look at things like Gump, Regexp, Taglibs, etc. > >When Grisha Trubetskoy wanted to contribute mod_python to the ASF, a good > >number of people called for creating a 'python' TLP. > > I'd do it when they'll donate Python itself ;-) > Does wishful thinking work? Believe me, I suggested that years ago. The Python Software Foundation was started instead (Dick Hardt and I crafted the PSF bylaws based on the ASF's bylaws). The main backers of a PSF effort thought that the ASF was still too confusingly tied to the Apache HTTP Server (despite my protests). I think if we asked again, today, that the answer would be that Apache stands for much more. But the PSF has got its own momentum now, so there wouldn't be much benefit for them to fold up and merge the Python assets into the ASF. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
Nicola Ken Barozzi wrote: Greg Stein wrote, On 04/07/2003 1.24: On Thu, Jul 03, 2003 at 04:22:10PM -0400, Andrew C. Oliver wrote: To that extent, I'd say it is an XML project. There is another more simple rule. Who has shown that they want the project most? Apache.XML. Then let them have it. However, I think it is mostly up to the XMLBeans community to ask for one or the other. If that PMC says "okay", then everything is fine. (and no... PMCs are not allowed to meet at sundown to duel for an arriving project :-) No? ;-P If XML.Apache is willing, as it seems, to cater for this project, I'll wait for a vote from them, an ACK from the Bea guys, and start preparing the hatcher :-) I'm happy to invest some time in helping XMLBean get throught the incubator -- speaking with my XML PMC and ASF member hat on. Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
On 7/4/03 7:26 PM, "Santiago Gala" <[EMAIL PROTECTED]> wrote: >> > > Don't forget that sundown occurs continuously in a slice of the world, > and that the probability of an Apache committer seeing a sundown is high > at any given moment ( http://cvs.apache.org/~sgala/nightmap.html ) > > Regards I think that is a conversation best held at [EMAIL PROTECTED] :-p ;-) -Andy -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
Nicola Ken Barozzi escribió: Greg Stein wrote, On 04/07/2003 1.24: On Thu, Jul 03, 2003 at 04:22:10PM -0400, Andrew C. Oliver wrote: (...) The division of XML vs Jakarta predates me for certain, but I think the main issues surrounding that are rusty. The problem is Jakarta itself. Centering a PMC around a *language* rather than functionality is the inherent problem. These questions will continue to arise over and over. This can be paraphrased as "Centering a PMC around *the new ASCII spec* rather than functionality is the inherent problem". In a lot of senses, XML has permeated the whole playing field. "Pure" XML projects will either be XML-functionality-toolkit projects or architectural "slices" of other projects. All classification attempts are doomed to failure ( http://www.crockford.com/wrrrld/wilkins.html ) unless we take them with a grain of salt. At that time it made sense. Java is not only a language, and is so separated from other environments, that it was IMHO the only way of aggregating enough resources to launch something out of it. But things that go well one time (and Jakarta has been a major success), don't necessarily go well the second. Things are not static. In the late 80's/early 90's I worked for a company where a Technology department for LA Networking existed. As LAN technology was more and more widespread and standard, the need for such a dept. disappeared. Today it would not make sense, but companies do have "WiFi Technology Depts." which will vanish in a couple of years... When Grisha Trubetskoy wanted to contribute mod_python to the ASF, a good number of people called for creating a 'python' TLP. I'd do it when they'll donate Python itself ;-) Does wishful thinking work? ... To that extent, I'd say it is an XML project. There is another more simple rule. Who has shown that they want the project most? Apache.XML. Then let them have it. This is a good heuristic, I think. However, I think it is mostly up to the XMLBeans community to ask for one or the other. If that PMC says "okay", then everything is fine. (and no... PMCs are not allowed to meet at sundown to duel for an arriving project :-) No? ;-P Don't forget that sundown occurs continuously in a slice of the world, and that the probability of an Apache committer seeing a sundown is high at any given moment ( http://cvs.apache.org/~sgala/nightmap.html ) Regards -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
Greg Stein wrote, On 04/07/2003 1.24: On Thu, Jul 03, 2003 at 04:22:10PM -0400, Andrew C. Oliver wrote: ... 1. Top level project - IMHO this isn't big enough and you don't have the open source experience or robust community to pull that off (not intended to be a criticism) There is no size minimum for a TLP, but I believe the Board would want to see the PMC has more direct experience at the ASF. So yes, I don't see that the Board would approve constructing a new PMC for this. As incubation goes, making a project a TLP right away is a *major* problem. If it isn't already a big and stable project with knowledge of Apache rules and a big sane OS community around it, I really prefer it to be under another PMC that can do the "practical" part of the incubation. 2. XML - I'm sure it would be fine. 3. Jakarta - IMHO this the best place for it. The division of XML vs Jakarta predates me for certain, but I think the main issues surrounding that are rusty. The problem is Jakarta itself. Centering a PMC around a *language* rather than functionality is the inherent problem. These questions will continue to arise over and over. At that time it made sense. Java is not only a language, and is so separated from other environments, that it was IMHO the only way of aggregating enough resources to launch something out of it. But things that go well one time (and Jakarta has been a major success), don't necessarily go well the second. When Grisha Trubetskoy wanted to contribute mod_python to the ASF, a good number of people called for creating a 'python' TLP. I'd do it when they'll donate Python itself ;-) Does wishful thinking work? ... To that extent, I'd say it is an XML project. There is another more simple rule. Who has shown that they want the project most? Apache.XML. Then let them have it. However, I think it is mostly up to the XMLBeans community to ask for one or the other. If that PMC says "okay", then everything is fine. (and no... PMCs are not allowed to meet at sundown to duel for an arriving project :-) No? ;-P If XML.Apache is willing, as it seems, to cater for this project, I'll wait for a vote from them, an ACK from the Bea guys, and start preparing the hatcher :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
On 4/07/2003 5:48 [EMAIL PROTECTED] wrote: Out of curiosity - does it have to be decided now? I guess not, if some actual people are willing to help XMLBeans out during incubation, setting up CVS, lists and all that, and monitor how they are doing - so that they can inform the eventually receiving PMC on the Apachiness of the incubating project. A clear sense direction might of course help, especially w.r.t. infrastructure - in a sense that CVS repos don't need to be moved, lists recreated and all that. Cfr. Lenya's incubation, which is still in progress, but already they have been made an integral part of the Cocoon project infrastructure. Less fuzz afterwards, and if incubation fails, deletion is still a no-brainer. If there is a general feeling from the two PMCs that they would be comfortable, then maybe we both sponsor into the incubator and give the committers time to migrate everything to Apache. Presumably in that time they are also getting used to Apache and can develop an understanding of where they feel their project fits best. Not jumping to any conclusion, I'm very happy to see a positive and constructive discussion happening. Thanks, all. -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
> From: "Andrew C. Oliver" <[EMAIL PROTECTED]> > On 7/3/03 7:24 PM, "Greg Stein" <[EMAIL PROTECTED]> wrote: ... > > "okay", then everything is fine. (and no... PMCs are not allowed to meet at > > sundown to duel for an arriving project :-) Everyone always takes all the fun out of my life :>. Out of curiosity - does it have to be decided now? If there is a general feeling from the two PMCs that they would be comfortable, then maybe we both sponsor into the incubator and give the committers time to migrate everything to Apache. Presumably in that time they are also getting used to Apache and can develop an understanding of where they feel their project fits best. Cheers, Berin This message was sent through MyMail http://www.mymail.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
On 7/3/03 7:44 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > I'd prefer to see things copied to [EMAIL PROTECTED] for > now. Even if the final decision is made to move > into Jakarta post incubation, there are people in > the xml project interested in the idea and who > might want to get involved, assuming this moves > ahead. > That¹s why I said pick a direction..otherwise we're stuck triple posting.. . Once a direction is picked, a preliminary "yes" or "no" decision can be made in whatever community and then they move to the incubator gauntlet, can create their own mailing lists and move forward Then those interested can subscribe to that particular list and [EMAIL PROTECTED] (if their interested in only the incubation rather than development issued) and I'll have less megs in my mail box. If they discuss on XML and apply to Jakarta then no one will know anything about it... Though hopefully they're close to picking a direction and the discussion should then be short ;-) -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
On 7/3/03 7:24 PM, "Greg Stein" <[EMAIL PROTECTED]> wrote: >> 3. Jakarta - IMHO this the best place for it. >> >> The division of XML vs Jakarta predates me for certain, but I think the main >> issues surrounding that are rusty. > > The problem is Jakarta itself. Centering a PMC around a *language* rather > than functionality is the inherent problem. These questions will continue to > arise over and over. > What's done is done. As a Jakarta committer I always feel like the guy wearing a "I'm here I'm queer deal with it" shirt at a Republican National Convention. > When Grisha Trubetskoy wanted to contribute mod_python to the ASF, a good > number of people called for creating a 'python' TLP. The Board decided to > stop perpetrating the per-language concept. Instead, mod_python was added to > the Apache HTTP Server Project (it *is* a module for Apache httpd, after > all). mod_php, mod_perl, and mod_tcl fall under the same argument, of > course, but they get a Grandfather Pass :-) > I'm getting de ja vu... You don't like this community. I get it... I'll file this on the appropriate file system for such information. So Jakarta is the grandfather of them all... Etc etc > To that extent, I'd say it is an XML project. > However, I think it is mostly > up to the XMLBeans community to ask for one or the other. If that PMC says > "okay", then everything is fine. (and no... PMCs are not allowed to meet at > sundown to duel for an arriving project :-) > I agree. The question for them: "Are you a good witch or a bad witch?" ;-) -Andy > Cheers, > -g -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
> From: "Andrew C. Oliver" <[EMAIL PROTECTED]> > > This is definitely a Java-only project right now. If that is a clear > > line of separation, I will stop posting to the XML list. The reason > > I posted to both lists was partly due to the fact that XMLBeans is much > > more XML-centric than Java centric (in terms of data modeling and the > > full fidelity availability of the XML Infoset); I really feel like this > > is one of those projects that could go either way. The other reason > > for posting to both lists is that three different Apache people (two of > > them ASF members) advised me to do so. I'm definitely interested in > > feedback as to whether to just limit the discussion to Jakarta right > > now. > > > I'd prefer to see things copied to [EMAIL PROTECTED] for now. Even if the final decision is made to move into Jakarta post incubation, there are people in the xml project interested in the idea and who might want to get involved, assuming this moves ahead. > options: > > 1. Top level project - IMHO this isn't big enough and you don't have the > open source experience or robust community to pull that off (not intended to > be a criticism) > > 2. XML - I'm sure it would be fine. > > 3. Jakarta - IMHO this the best place for it. > > The division of XML vs Jakarta predates me for certain, but I think the main > issues surrounding that are rusty. > Can see good reasons for either XML or Jakarta. Maybe (again assuming this goes ahead) this is something that could be decided by the committers within the incubator? > (BTW acceptance to Jakarta is a majority of the Jakarta PMC vote)... It > would be nice if other Jakarta PMC members sounded off a little so the > incubator can hear. Similarly XML. Be particularly interested in anyone (in either project) who would -1. Cheers, Berin This message was sent through MyMail http://www.mymail.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
On 7/3/03 3:50 PM, "Cliff Schmidt" <[EMAIL PROTECTED]> wrote: > > On Thursday, July 03, 2003 8:57 AM, Andrew C. Oliver wrote: > >> 2. Pick your project. I think it would have been a lot less >> confusing to mail the proposal to Jakarta or XML. Personally, if >> this is a Java only project, I think it should go to Jakarta. If it >> is a mult-platform C a/o C++ and Java, then it make sense for it to >> be part of XML. The proposers and sponsors should just decide and go >> in a single direction rather than kicking off a big debate. > > This is definitely a Java-only project right now. If that is a clear > line of separation, I will stop posting to the XML list. The reason > I posted to both lists was partly due to the fact that XMLBeans is much > more XML-centric than Java centric (in terms of data modeling and the > full fidelity availability of the XML Infoset); I really feel like this > is one of those projects that could go either way. The other reason > for posting to both lists is that three different Apache people (two of > them ASF members) advised me to do so. I'm definitely interested in > feedback as to whether to just limit the discussion to Jakarta right > now. > options: 1. Top level project - IMHO this isn't big enough and you don't have the open source experience or robust community to pull that off (not intended to be a criticism) 2. XML - I'm sure it would be fine. 3. Jakarta - IMHO this the best place for it. The division of XML vs Jakarta predates me for certain, but I think the main issues surrounding that are rusty. > I've tried to address some of the differences with XMLBeans and why I > think it adds a lot more than currently existing projects (see my > response to Howard -- http://archives.apache.org/eyebrowse/ReadMsg? > [EMAIL PROTECTED]&msgNo=15061). However, this might > be a good time for David Bau, the architect behind XMLBeans, to jump in > with his views. > Okay. It sounds like there are some issues which warrant this over others. I could see this being useful in things like web services as well... Limit object creation/serialization and yada yada yada... Though from reading the 10k foot view you could support JAXB if you wanted to. Just an element of curio for me...Offtopic...nevermind ;-) > > We would appreciate any help anyone has to offer, but I'm hoping we > don't appear to need any special treatment. I've spent the last few > months talking to everyone I can and reading everything I can about > how to do this right. You and Howard have brought up some very > reasonable points and I want to make sure I address them (either with > further explanation or by making whatever changes to this proposal are > necessary). > Well the homogony is a big issue. Apache isn't a panacea, you'll have to work at it but I think you're sincere and motivated. Steven can help you through the gauntlet^M^M^M^M^M^M^Mincubator process and provided the committership had rounded out, and you integrated with Gump I'd vote in favor of Jakarta acceptance. (BTW acceptance to Jakarta is a majority of the Jakarta PMC vote)... It would be nice if other Jakarta PMC members sounded off a little so the incubator can hear. -Andy > Thanks, > Cliff > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Issues with XMLBeans proposal
Now to address, Andy's other issues (the first issue has spun off into a different thread)... On Thursday, July 03, 2003 8:57 AM, Andrew C. Oliver wrote: > 2. Pick your project. I think it would have been a lot less > confusing to mail the proposal to Jakarta or XML. Personally, if > this is a Java only project, I think it should go to Jakarta. If it > is a mult-platform C a/o C++ and Java, then it make sense for it to > be part of XML. The proposers and sponsors should just decide and go > in a single direction rather than kicking off a big debate. This is definitely a Java-only project right now. If that is a clear line of separation, I will stop posting to the XML list. The reason I posted to both lists was partly due to the fact that XMLBeans is much more XML-centric than Java centric (in terms of data modeling and the full fidelity availability of the XML Infoset); I really feel like this is one of those projects that could go either way. The other reason for posting to both lists is that three different Apache people (two of them ASF members) advised me to do so. I'm definitely interested in feedback as to whether to just limit the discussion to Jakarta right now. > 3. Duplication of effort. The project encompasses schema validation > which is done my XML parsers and it is Yet Another XML->Java binding > API (there are some here and several elsewhere). From the standpoint > of something I'd commit code to, this bores the crap out of me. From > the standpoint of acceptability, its totally irrelevant. Choice is > good, competition and cooperation exist not only in opensource but > often in the same area of given projects. Thus if it can become an > Apache community, then its irrelevant. I've tried to address some of the differences with XMLBeans and why I think it adds a lot more than currently existing projects (see my response to Howard -- http://archives.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]&msgNo=15061). However, this might be a good time for David Bau, the architect behind XMLBeans, to jump in with his views. > 4. Machiavelli - I originally posted this to a private list because I > didn¹t think it was good to say publicly, but rounding things out > here might be good. Thus anointing BEA into the real open source and > Apache world is a motivation. I don't think this project should be > accepted without meeting the basic qualifications because of that, > but maybe its a motivation to be a little more helpful than usual > ;-). It might also round out the power structure at Apache a little > if BEA began participating. We would appreciate any help anyone has to offer, but I'm hoping we don't appear to need any special treatment. I've spent the last few months talking to everyone I can and reading everything I can about how to do this right. You and Howard have brought up some very reasonable points and I want to make sure I address them (either with further explanation or by making whatever changes to this proposal are necessary). Thanks, Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Issues with XMLBeans proposal
Hi Cliff,
I think the copy list of your note to Howard must have been a good bit
narrower than the copy list of this response to Andy. :) Any chance you
could enlighten those of us in this broader group who are interested as to
the technical points on which XMLBeans differs from other technologies?
Cheers!
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
|-+>
| | "Cliff Schmidt" |
| | <[EMAIL PROTECTED]> |
| ||
| | 07/03/2003 02:22 |
| | PM |
| | Please respond to|
| | general |
| ||
|-+>
>-|
|
|
| To: "Jakarta General List" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> |
| cc:
|
| Subject: RE: Issues with XMLBeans proposal
|
|
|
|
|
>-|
On Thursday, July 03, 2003 11:01 AM, Andrew C. Oliver wrote:
> So what in this ensures this will be a community-developed project
> and not just an Apache branded extension of BEA? I really would like
> to see you guys involved in Apache, but not in a way the compromises
> Apache. There is a challenge that limits the excitement of others in
> that there are so many other similar projects that do exactly the
> same thing. Perhaps it would benefit the effort if you explained why
> we needed another one. That has no bearing on its suitability but it
> might make people more interested who wouldn't be otherwise.
As Santiago points out, the veto rule provides some protection over
pure majority, but I don't think anyone here wants to rely on that.
All I can tell you is that BEA is more concerned about establishing a
long term relationship with Apache and other open source communities
than controlling the future development of XMLBeans. From our
perspective, we have much more to gain by proving ourselves as credible
and positive contributors to open source, especially since we would
like XMLBeans to be the first in a series of open source contributions.
If the BEA committers attempt to make decisions against the wishes of
the rest of the community and are viewed negatively for doing so, we
have absolutely failed in what we set out to do.
See my response to Howard's questions for more on how the project
differs technically from other open source projects.
Cliff
-
In case of troubles, e-mail: [EMAIL PROTECTED]
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: Issues with XMLBeans proposal
Sorry about that -- looks like that mail didn't make it out of my outbox. I'll resend right now to all three lists. Cliff On Thursday, July 03, 2003 11:50 AM, Andrew C. Oliver wrote: > +1 > > On 7/3/03 2:26 PM, "Neil Graham" <[EMAIL PROTECTED]> wrote: > >> Hi Cliff, >> >> I think the copy list of your note to Howard must have been a good >> bit narrower than the copy list of this response to Andy. :) Any >> chance you could enlighten those of us in this broader group who are >> interested as to the technical points on which XMLBeans differs from >> other technologies? >> >> Cheers! >> Neil >> Neil Graham >> XML Parser Development >> IBM Toronto Lab >> Phone: 905-413-3519, T/L 969-3519 >> E-mail: [EMAIL PROTECTED] >> >> >> >> >>> -+> >>> | "Cliff Schmidt" | >>> | <[EMAIL PROTECTED]> | >>> || >>> | 07/03/2003 02:22 | >>> | PM | >>> | Please respond to| >>> | general | >>> || >>> -+> >>> ------------- >>> | >>> >>> >>> To: "Jakarta General List" <[EMAIL PROTECTED]>, >> <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> >> | >>> cc: >>> >>> Subject: RE: Issues with XMLBeans proposal >>> >>> >>> >>> >>> >>> - >>> | >> >> >> >> On Thursday, July 03, 2003 11:01 AM, Andrew C. Oliver wrote: >> >>> So what in this ensures this will be a community-developed project >>> and not just an Apache branded extension of BEA? I really would >>> like to see you guys involved in Apache, but not in a way the >>> compromises Apache. There is a challenge that limits the >>> excitement of others in that there are so many other similar >>> projects that do exactly the same thing. Perhaps it would benefit >>> the effort if you explained why we needed another one. That has no >>> bearing on its suitability but it might make people more interested >>> who wouldn't be otherwise. >> >> As Santiago points out, the veto rule provides some protection over >> pure majority, but I don't think anyone here wants to rely on that. >> All I can tell you is that BEA is more concerned about establishing a >> long term relationship with Apache and other open source communities >> than controlling the future development of XMLBeans. From our >> perspective, we have much more to gain by proving ourselves as >> credible and positive contributors to open source, especially since >> we would like XMLBeans to be the first in a series of open source >> contributions. If the BEA committers attempt to make decisions >> against the wishes of the rest of the community and are viewed >> negatively for doing so, we have absolutely failed in what we set >> out to do. >> >> See my response to Howard's questions for more on how the project >> differs technically from other open source projects. >> >> Cliff >> >> - >> In case of troubles, e-mail: [EMAIL PROTECTED] >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> >> - >> In case of troubles, e-mail: [EMAIL PROTECTED] >> 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: Issues with XMLBeans proposal
On 7/3/03 2:22 PM, "Cliff Schmidt" <[EMAIL PROTECTED]> wrote: > As Santiago points out, the veto rule provides some protection over > pure majority, but I don't think anyone here wants to rely on that. > All I can tell you is that BEA is more concerned about establishing a > long term relationship with Apache and other open source communities > than controlling the future development of XMLBeans. From our > perspective, we have much more to gain by proving ourselves as credible > and positive contributors to open source, especially since we would > like XMLBeans to be the first in a series of open source contributions. > If the BEA committers attempt to make decisions against the wishes of > the rest of the community and are viewed negatively for doing so, we > have absolutely failed in what we set out to do. > That is encouraging. That would be a nice development. Of course you understand that I don't want us to totally make an exception just because of this. At the moment, on the merits, the project has some difficulty. However using this motivation that you're expressing, I think this is a bridge that can be crossed. -andy > See my response to Howard's questions for more on how the project > differs technically from other open source projects. > > Cliff > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
+1 On 7/3/03 2:26 PM, "Neil Graham" <[EMAIL PROTECTED]> wrote: > Hi Cliff, > > I think the copy list of your note to Howard must have been a good bit > narrower than the copy list of this response to Andy. :) Any chance you > could enlighten those of us in this broader group who are interested as to > the technical points on which XMLBeans differs from other technologies? > > Cheers! > Neil > Neil Graham > XML Parser Development > IBM Toronto Lab > Phone: 905-413-3519, T/L 969-3519 > E-mail: [EMAIL PROTECTED] > > > > > |-+> > | | "Cliff Schmidt" | > | | <[EMAIL PROTECTED]> | > | || > | | 07/03/2003 02:22 | > | | PM | > | | Please respond to| > | | general | > | || > |-+> >> - >> | > | > | > | To: "Jakarta General List" <[EMAIL PROTECTED]>, > <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> | > | cc: > | > | Subject: RE: Issues with XMLBeans proposal > | > | > | > | > | >> - >> | > > > > On Thursday, July 03, 2003 11:01 AM, Andrew C. Oliver wrote: > >> So what in this ensures this will be a community-developed project >> and not just an Apache branded extension of BEA? I really would like >> to see you guys involved in Apache, but not in a way the compromises >> Apache. There is a challenge that limits the excitement of others in >> that there are so many other similar projects that do exactly the >> same thing. Perhaps it would benefit the effort if you explained why >> we needed another one. That has no bearing on its suitability but it >> might make people more interested who wouldn't be otherwise. > > As Santiago points out, the veto rule provides some protection over > pure majority, but I don't think anyone here wants to rely on that. > All I can tell you is that BEA is more concerned about establishing a > long term relationship with Apache and other open source communities > than controlling the future development of XMLBeans. From our > perspective, we have much more to gain by proving ourselves as credible > and positive contributors to open source, especially since we would > like XMLBeans to be the first in a series of open source contributions. > If the BEA committers attempt to make decisions against the wishes of > the rest of the community and are viewed negatively for doing so, we > have absolutely failed in what we set out to do. > > See my response to Howard's questions for more on how the project > differs technically from other open source projects. > > Cliff > > - > In case of troubles, e-mail: [EMAIL PROTECTED] > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > In case of troubles, e-mail: [EMAIL PROTECTED] > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Issues with XMLBeans proposal
On Thursday, July 03, 2003 11:01 AM, Andrew C. Oliver wrote: > So what in this ensures this will be a community-developed project > and not just an Apache branded extension of BEA? I really would like > to see you guys involved in Apache, but not in a way the compromises > Apache. There is a challenge that limits the excitement of others in > that there are so many other similar projects that do exactly the > same thing. Perhaps it would benefit the effort if you explained why > we needed another one. That has no bearing on its suitability but it > might make people more interested who wouldn't be otherwise. As Santiago points out, the veto rule provides some protection over pure majority, but I don't think anyone here wants to rely on that. All I can tell you is that BEA is more concerned about establishing a long term relationship with Apache and other open source communities than controlling the future development of XMLBeans. From our perspective, we have much more to gain by proving ourselves as credible and positive contributors to open source, especially since we would like XMLBeans to be the first in a series of open source contributions. If the BEA committers attempt to make decisions against the wishes of the rest of the community and are viewed negatively for doing so, we have absolutely failed in what we set out to do. See my response to Howard's questions for more on how the project differs technically from other open source projects. Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
So what in this ensures this will be a community-developed project and not just an Apache branded extension of BEA? I really would like to see you guys involved in Apache, but not in a way the compromises Apache. There is a challenge that limits the excitement of others in that there are so many other similar projects that do exactly the same thing. Perhaps it would benefit the effort if you explained why we needed another one. That has no bearing on its suitability but it might make people more interested who wouldn't be otherwise. Note that I didn't come up with the "shouldn't be all from the same company" requirement...that was noted long before my time.. -Andy On 7/3/03 1:27 PM, "Cliff Schmidt" <[EMAIL PROTECTED]> wrote: > I understand Andy's concern here, but I think Craig does a good job > of pointing out the consequences of less participation by the core > developers of a project, and the possibly invalid assumptions > around that. > > As any of the committers can tell you, I wrestled with the list and > really tried to limit the BEA involvement to a functional minimum. > There are a few reasons why I ended up with 6 out of 9 being BEA > folks: > > 1) I'm really hoping that other members of the Apache community will > find this project interesting enough that we will end up with a > couple experienced Apache people on our committer list, thereby > reducing the BEA percentage. > > 2) The core XMLBeans developers (all BEA employees) are really > excited about this stuff and want to do what ever they can to keep > improving it. They are open to all kind of possibilities for > refactoring, integration with other projects, and especially working > with others on it...but they really all wanted to stay involved. It > would probably be more efficient for BEA to have only a couple > developers on the project, but the individuals wanted to be as > involved as possible. > > 3) In the end, I had to go with the people I thought would have the > most knowledge and experience with the code to lead by example. I > am hoping that an active committer list will inspire community > participation. I found three non-BEA people who I know will fill > this role, plus the six BEA people. > > (I'll be responding to Andy's other points and Howard's email > shortly.) > > Cliff > > > On Thursday, July 03, 2003 10:01 AM, Craig R. McClanahan wrote: > >> Snipping to an issue I have with one particular comment. >> >> On Thu, 3 Jul 2003, Andrew C. Oliver wrote: >> >>> >>> In summary the most serious issues to this proposal are: >>> >>> 1. diversity of committership. I'd personally like to see >51% of >>> the ACTIVE committership from a different company. So long as a >>> decision in one company can MAKE the vote, you don't have an Apache >>> project, you have a corporate subproject at Apache. >>> >> >> Andy, I agree with you that diversity is important, but your proposed >> standard (more than half the committers from "elsewhere") has some >> distrubing implications that are worth exploring. >> >> * There is an implied assumption that the proposed committers >> will behave the way that their employer wants, not the way >> that they want. Although it is too simplistic to say that >> this never happens (our individual actions are public record, >> so of course you take into consideration what your employer >> might think), developers that are solely "corporate mouthpiece" >> players should never have been elected as committers >> in the first place. >> >> * There is an implied assumption that all the committers from >> the same company will vote the same way. I can tell you from >> lots of experience over the last few years (some of it pretty >> painful and personal) that this is not likely to be a problem. >> If it is, then we screwed up on accepting the original committers >> in the first place. >> >> * There is an implied assumption that a person's employer (and >> therefore their corporate email address) should have anything to do >> with whether or not that person is individually a good choice for >> being an Apache committer. THAT should be the overriding concern >> -- after all, they will be able to stay a committer even if they >> move to a different job (within the same company or elsewhere). >> >> * What happens to your "diversity" statistics if a committer that was >> originally outside the originating company is then hired by that >> company to continue working on the project? One of the company's >> goals might well be to support open source by allowing that person >> to work on the project on company time; yet your proposed standard >> would view the change of employment as a negative and not a >> positive. >> >> Apache is about individuals, not about companies. Apache is about >> attracting high quality software projects, not about conspiracy >> theories (go back in the archives a couple years before you joined, >> and you'll see LOTS of
Re: Issues with XMLBeans proposal
> Simplistic standards like "> 51% of the ACTIVE committership from a > different company" might work for making simplistic decisions. They are > not appropriate for a decision to accept a new project into Apache, which > should be based on the quality of the proposed code and the proposed > initial committers, not on the email addresses of the proposed initial > committers. > Maybe that¹s not a candidate for policy however it is required for MY vote. If your boss came and said "Craig, if you don't vote X then you're fired" and said this to a number of committers... While some might quit or whatever, I suspect the vote would be decided supposing they dominate the project. Furthermore, the interests of a set of employees of a company using a project for a particular purpose will tend to have homogenous interests. Thus will *tend* to vote similarly (if not the same way). It is my experience that developers who counter their employers interest do not stay employed for long. Lastly, developers who work together at work tend to communicate directly versus on community resources more frequently. In a NEW project it is my opinion that diversity should be settled up front so that no one company controls any new project. This is MY criteria for certain and required for my vote -- perhaps its not yours. -Andy > Craig McClanahan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues with XMLBeans proposal
Craig R. McClanahan escribió: Snipping to an issue I have with one particular comment. I snip the whole thing, just to add. Read Craig's mail if you haven't :-) The Apache voting rules, where one -1 vetoes (and at the same time it is required to give substantial arguments about the veto) is, I think, precisely designed to enhance dialog and consensus over pure majority. I think this fact does a lot towards avoiding this kind of control traps and hidden agendas. This and the public discussions on the rationale of decisions. Regards -- Santiago Gala High Sierra Technology, S.L. (http://hisitech.com) http://memojo.com?page=SantiagoGalaBlog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Issues with XMLBeans proposal
I understand Andy's concern here, but I think Craig does a good job of pointing out the consequences of less participation by the core developers of a project, and the possibly invalid assumptions around that. As any of the committers can tell you, I wrestled with the list and really tried to limit the BEA involvement to a functional minimum. There are a few reasons why I ended up with 6 out of 9 being BEA folks: 1) I'm really hoping that other members of the Apache community will find this project interesting enough that we will end up with a couple experienced Apache people on our committer list, thereby reducing the BEA percentage. 2) The core XMLBeans developers (all BEA employees) are really excited about this stuff and want to do what ever they can to keep improving it. They are open to all kind of possibilities for refactoring, integration with other projects, and especially working with others on it...but they really all wanted to stay involved. It would probably be more efficient for BEA to have only a couple developers on the project, but the individuals wanted to be as involved as possible. 3) In the end, I had to go with the people I thought would have the most knowledge and experience with the code to lead by example. I am hoping that an active committer list will inspire community participation. I found three non-BEA people who I know will fill this role, plus the six BEA people. (I'll be responding to Andy's other points and Howard's email shortly.) Cliff On Thursday, July 03, 2003 10:01 AM, Craig R. McClanahan wrote: > Snipping to an issue I have with one particular comment. > > On Thu, 3 Jul 2003, Andrew C. Oliver wrote: > >> >> In summary the most serious issues to this proposal are: >> >> 1. diversity of committership. I'd personally like to see >51% of >> the ACTIVE committership from a different company. So long as a >> decision in one company can MAKE the vote, you don't have an Apache >> project, you have a corporate subproject at Apache. >> > > Andy, I agree with you that diversity is important, but your proposed > standard (more than half the committers from "elsewhere") has some > distrubing implications that are worth exploring. > > * There is an implied assumption that the proposed committers > will behave the way that their employer wants, not the way > that they want. Although it is too simplistic to say that > this never happens (our individual actions are public record, > so of course you take into consideration what your employer > might think), developers that are solely "corporate mouthpiece" > players should never have been elected as committers > in the first place. > > * There is an implied assumption that all the committers from > the same company will vote the same way. I can tell you from > lots of experience over the last few years (some of it pretty > painful and personal) that this is not likely to be a problem. > If it is, then we screwed up on accepting the original committers > in the first place. > > * There is an implied assumption that a person's employer (and > therefore their corporate email address) should have anything to do > with whether or not that person is individually a good choice for > being an Apache committer. THAT should be the overriding concern > -- after all, they will be able to stay a committer even if they > move to a different job (within the same company or elsewhere). > > * What happens to your "diversity" statistics if a committer that was > originally outside the originating company is then hired by that > company to continue working on the project? One of the company's > goals might well be to support open source by allowing that person > to work on the project on company time; yet your proposed standard > would view the change of employment as a negative and not a > positive. > > Apache is about individuals, not about companies. Apache is about > attracting high quality software projects, not about conspiracy > theories (go back in the archives a couple years before you joined, > and you'll see LOTS of discussion along these lines :-). > > Diversity is important -- a proposal that ONLY has committers from one > company needs to be analyzied. But a proposal that includes a > software contribution from a company, but WITHOUT any committers from > that company willing to continue working on the software (the "throw > it over the wall" scenario) would also be problematic. > > Simplistic standards like "> 51% of the ACTIVE committership from a > different company" might work for making simplistic decisions. They > are not appropriate for a decision to accept a new project into > Apache, which should be based on the quality of the proposed code and > the proposed initial committers, not on the email addresses of the > proposed initial committers. > > Craig McClanahan > > - > To unsu
Re: Issues with XMLBeans proposal
Snipping to an issue I have with one particular comment. On Thu, 3 Jul 2003, Andrew C. Oliver wrote: > > In summary the most serious issues to this proposal are: > > 1. diversity of committership. I'd personally like to see >51% of the > ACTIVE committership from a different company. So long as a decision in one > company can MAKE the vote, you don't have an Apache project, you have a > corporate subproject at Apache. > Andy, I agree with you that diversity is important, but your proposed standard (more than half the committers from "elsewhere") has some distrubing implications that are worth exploring. * There is an implied assumption that the proposed committers will behave the way that their employer wants, not the way that they want. Although it is too simplistic to say that this never happens (our individual actions are public record, so of course you take into consideration what your employer might think), developers that are solely "corporate mouthpiece" players should never have been elected as committers in the first place. * There is an implied assumption that all the committers from the same company will vote the same way. I can tell you from lots of experience over the last few years (some of it pretty painful and personal) that this is not likely to be a problem. If it is, then we screwed up on accepting the original committers in the first place. * There is an implied assumption that a person's employer (and therefore their corporate email address) should have anything to do with whether or not that person is individually a good choice for being an Apache committer. THAT should be the overriding concern -- after all, they will be able to stay a committer even if they move to a different job (within the same company or elsewhere). * What happens to your "diversity" statistics if a committer that was originally outside the originating company is then hired by that company to continue working on the project? One of the company's goals might well be to support open source by allowing that person to work on the project on company time; yet your proposed standard would view the change of employment as a negative and not a positive. Apache is about individuals, not about companies. Apache is about attracting high quality software projects, not about conspiracy theories (go back in the archives a couple years before you joined, and you'll see LOTS of discussion along these lines :-). Diversity is important -- a proposal that ONLY has committers from one company needs to be analyzied. But a proposal that includes a software contribution from a company, but WITHOUT any committers from that company willing to continue working on the software (the "throw it over the wall" scenario) would also be problematic. Simplistic standards like "> 51% of the ACTIVE committership from a different company" might work for making simplistic decisions. They are not appropriate for a decision to accept a new project into Apache, which should be based on the quality of the proposed code and the proposed initial committers, not on the email addresses of the proposed initial committers. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
