Re: [VOTE] Accept Glasgow into Incubator
On Thu, Aug 10, 2006 at 04:32:02PM -0700, Cliff Schmidt wrote: Spec process concerns (without voting): Mads, Leo Mine would be a -1 if I was on the incubator PMC (but no thanks, I'd rather not). I don't find the excuse that a mistake has been made in the past sufficient to repeat it. I'm also far from convinced that we should use the ASF name to promote this specific spec - I'd much rather give them a while longer to prove that it is the right choice. But, not my call - and kind of useless to object anyway because they seem to have aquired plenty of support already. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
The official vote closed three days ago, but I didn't want to close it out while discussions were still going, especially when there were binding -1s involved. While a -1 does not veto a proposal, it is important to make sure that anyone who has a concern has had a chance to make it heard or clarify it. The vote currently stands at: (6) +1s, (1) +/-0, and (2) -1s. With these results, the proposal would be accepted for incubation. However, since there has been quite a bit of discussion during the voting and two standing -1s, I'd like to give one last call for any additional votes or changed votes, and extend the voting period just another 24 hours to Saturday, August 12th 00:00 UTC / Friday, August 11th 17:00 PDT (see http://www.timeanddate.com/worldclock/fixedtime.html?month=8day=12year=2006hour=00min=0sec=0p1=0). Please submit any last votes now, and I will send out the final results shortly after the new closing time. Also, for those interested in a summary of who voted what so far, see below. Thanks, Cliff Binding +1 Dims, Jason, Jim, JAaron, Susan, Robert Paul stated support for the project and offered to mentor, but did not officially vote. Binding +/-0 Bill Binding -1s: Garrett, Brian Non-binding +1: Matthias, Craig Russell, Coach, Kim, Adi Spec process concerns (without voting): Mads, Leo Name concerns: Danny (non-binding -1), Rich (no vote) On 8/3/06, Cliff Schmidt [EMAIL PROTECTED] wrote: I believe all open questions about the Glasgow proposal (originally submitted as Blaze) have now been addressed enough to call a vote for accepting the project for incubation. Therefore, as the champion of this project, I am calling a vote. As usual, the binding votes will be those case by Incubator PMC members (since the project is requesting sponsorship from the Incubator PMC); however all participants on this list are encouraged to vote if they have a strong feeling one way or another. The traditional 72-hour voting period would end during a weekend for most timezones; so I propose extending that by an additional day, with the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see http://www.timeanddate.com/worldclock/fixedtime.html?month=8day=7year=2006hour=17min=0sec=0p1=0) Please vote on the Glasgow proposal, as described below, which can also be found at: http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1. Note the old wiki page (with the full history of changes since the original proposal) can be found here: http://wiki.apache.org/incubator/Blaze Cliff = Glasgow Proposal (renamed from Blaze) = == RATIONALE == Glasgow provides multiple language implementations of the Advanced Messaged Queuing Protocol (AMQP) specification and related technologies including PGM, transaction management, queuing, distribution, security, management and heterogeneous multi-platform support for messaging (links to these specifications are in the Initial Source section of this proposal.) Glasgow's overall goal is to create an open and interoperable implementation for messaging which implements the emerging AMQP specification, in keeping with the philosophy of the Foundation. This implementation will provide a messaging solution that will be language and platform agnostic by using a well defined wire specification. Providing both libraries for the framing and protocol in addition to brokers in both Java and C/C++ allows for integration with Apache and non-Apache projects in a manner that facilitates heterogeneous deployment with full interoperability for SOA distributed systems. The seed code for the project will consist of in-progress C/C++ and Java implementations of the AMQP specification that we intend to continue development on in conjunction with other Apache communities. More information on the scope of the seed code can be found in subsequent sections of this proposal. == CRITERIA == === Meritocracy: === The Glasgow committers recognize the desirability and necessity of running this project as a full meritocracy; indeed, the scope of the project's technical aspects are so varied that we find it hard to envision success any other way. One of the most important lessons that can be derived from the historic evolution of middleware is that specifications architected in isolation from real usable code that has been developed to solve tangible, real world problems or amongst a narrowly restricted list of contributors often do not see widespread adoption. Our goal in crafting this implementation and providing our learning to the specification team is to develop the best possible language agnostic advanced message queuing platform. We understand that in order to do so, we will need to engage all interested members of the community and operate to the standard of meritocracy that characterizes successful Apache projects. === Community: === The project's primary objective is to build a vibrant community of users and active contributors. Although Glasgow is not
Re: [VOTE] Accept Glasgow into Incubator
On 8/3/06, Cliff Schmidt [EMAIL PROTECTED] wrote: snip Please vote on the Glasgow proposal, as described below, which can also be found at: http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1. +1 i do have a few comments i agree with the substance of a couple of important points which have led some people to vote -1 but i disagree about the right way to proceed. upon reflection, the use of proper nouns to name projects is a habit that we need to break. however, IMHO this is something that does not need to be addressed immediately for this project. i also definitely agree with the importance of open standards. however, apache has already achieved a great deal of good by engaging with creators of standards. there seems to me to be a willingness to move towards an open standards process. i think that we should (at this stage of the process and given that the body is still bootstrapping) be willing to give them the benefit of the doubt. we can (and should) revisit the issue of standards later (perhaps at the time of the first board report). we should know more then. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
+1 (non-binding). -Adi On 8/3/06, Cliff Schmidt [EMAIL PROTECTED] wrote: I believe all open questions about the Glasgow proposal (originally submitted as Blaze) have now been addressed enough to call a vote for accepting the project for incubation. Therefore, as the champion of this project, I am calling a vote. As usual, the binding votes will be those case by Incubator PMC members (since the project is requesting sponsorship from the Incubator PMC); however all participants on this list are encouraged to vote if they have a strong feeling one way or another. The traditional 72-hour voting period would end during a weekend for most timezones; so I propose extending that by an additional day, with the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see http://www.timeanddate.com/worldclock/fixedtime.html?month=8day=7year=2006hour=17min=0sec=0p1=0) Please vote on the Glasgow proposal, as described below, which can also be found at: http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1. Note the old wiki page (with the full history of changes since the original proposal) can be found here: http://wiki.apache.org/incubator/Blaze Cliff = Glasgow Proposal (renamed from Blaze) = == RATIONALE == Glasgow provides multiple language implementations of the Advanced Messaged Queuing Protocol (AMQP) specification and related technologies including PGM, transaction management, queuing, distribution, security, management and heterogeneous multi-platform support for messaging (links to these specifications are in the Initial Source section of this proposal.) Glasgow's overall goal is to create an open and interoperable implementation for messaging which implements the emerging AMQP specification, in keeping with the philosophy of the Foundation. This implementation will provide a messaging solution that will be language and platform agnostic by using a well defined wire specification. Providing both libraries for the framing and protocol in addition to brokers in both Java and C/C++ allows for integration with Apache and non-Apache projects in a manner that facilitates heterogeneous deployment with full interoperability for SOA distributed systems. The seed code for the project will consist of in-progress C/C++ and Java implementations of the AMQP specification that we intend to continue development on in conjunction with other Apache communities. More information on the scope of the seed code can be found in subsequent sections of this proposal. == CRITERIA == === Meritocracy: === The Glasgow committers recognize the desirability and necessity of running this project as a full meritocracy; indeed, the scope of the project's technical aspects are so varied that we find it hard to envision success any other way. One of the most important lessons that can be derived from the historic evolution of middleware is that specifications architected in isolation from real usable code that has been developed to solve tangible, real world problems or amongst a narrowly restricted list of contributors often do not see widespread adoption. Our goal in crafting this implementation and providing our learning to the specification team is to develop the best possible language agnostic advanced message queuing platform. We understand that in order to do so, we will need to engage all interested members of the community and operate to the standard of meritocracy that characterizes successful Apache projects. === Community: === The project's primary objective is to build a vibrant community of users and active contributors. Although Glasgow is not based on an existing open source community, many of the initial contributors have experience participating in and building other open source communities. Several of the contributors have previously participated in Apache communities. We understand that Apache's community governance protocols are a unique contributor to the success of Apache's project communities and we are eager to learn from our Incubator mentors so that we can evolve Glasgow into a healthy and sustainable community. === Core Developers: === Most of the initial committers are members of Red Hat, IONA, and JP Morgan Chase's (JPMC) development teams. Additional developers will be added through the Apache community process. === Alignment: === An initial implementation has been written in Java and C++, which will be refactored into this project to form the initial code base. We have had a few exploratory conversations about integration with individuals of other communties such as Apache Geronimo, Tuscany, ActiveMQ, Fedora and ObjectWeb's Celtix and hope to work towards future collaboration with these communities. Our current implementation makes extensive use of projects from the Apache Jakata Commons, Mina and other Apache infrastructure projects. A compatibility binding for JMS also exists. It is however important to note that this is NOT a JMS project and aims to solve a
Re: [VOTE] Accept Glasgow into Incubator
On Aug 4, 2006, at 08:31, Danny Angus wrote: Hi everybody, I don't have a binding vote here, but.. -1 I strongly object to the name, in some sense I object to this name because it is also the name of the city in which I work, and conversations about Glasgow will be a bit wierd. But very much more importantly I would also like to publicly stand up and say that I think it is ridiculous that time after time we misappropriate proper nouns to name our projects with. Stop it. Stop it now. It is misguided to think that it can be done without making a cultural reference, and it is naieve to think that all such references will be appropriate or well received by those whose culture is being misrepresented. The fact that Glasgow is not an impoverished and exploited region of Africa or Asia doesn't make it any less inappropriate to use it as a project name. I think it is about time that we grew up and introduced a rule which prevents words already used as proper nouns from being proposed as project names unless there is some real and relevant on-topic connection. Don't be lazy, if trademarks and IP make it difficult to pick an apropriate name straight away don't just revert to sticking a pin in the map, get out a thesaurus. With the notable and highly significant exceptions of Apache and Jakarta (both of which raise difficult questions) it seems as if it has only really become common practice since the incubator with Derby, Geronimo, Tuscany, Woden to name some that I know about. You guys have the chance to stop it by rejecting this project on the basis of its name. Danny has stated something here that I have also begun to feel rather strongly about. Consider, for a moment, how it would feel if we called a project Canada, or perhaps Russia. Yet we have Trinidad and Tobago. Someone on IRC mentioned that they hear of Jakarta in two contexts - one, the Apache project, and the other, when something unpleasant is happening in that part of the world. While I wouldn't necessarily vote to reject the proposal solely on this one point (although I do agree with all of the points so eloquently stated by Garrett - but I'm not a member of the Incubator PMC) I would strongly request that the changing of the name be a prerequisite for graduation, if this proposal is indeed accepted. -- http://feathercast.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Project Naming (was Re: [VOTE] Accept Glasgow into Incubator)
On 8/5/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: IMO the reason this naming debate hasn't been settled is because of the way in which the change from Blaze to Glasgow was achieved: it was done privately and the result was announced here. +1 I can imagine how frustrating this must be to folks who are new to Apache, but folks here don't like private stuff. If you come here you must be willing to open your kimono all the way, not just let us take a peek thru a small crack. An example was the Ajax proposal .. the name got rejected and we had a public debate here and created Kabuki (which of course proceeded to have a failure to launch but that's another movie). +1 In any case, if there are naming issues we can certainly deal with them during incubation and simply make it a graduation criteria to come up with a better name. I can see why marketing types will get upset by that but again educating the marketing community to deal with the Apache Way is a requirement to survive here too :-). The PRC folks will take the sledge hammer on that one! IMO good names for open source projects are very different from good names for commercial products. marketing types will talk about postive and negative associations. for open source projects, the more unique the name the better. it's better for everyone if downstream commercial vendors create their own good marketing names and leave us to pick something unique. as a not-for-profit, apache has different priorities. ethics is definitely important. as a gorilla, we should be careful to aviod throwing our weight around unfairly. legal considerations are also important. trademarks are a vital tool in enforcing key apache policies. without decent uniqueness, we lose some control. we also really want to avoid being sued for trademark enfringement. infringing a trademark would mean (at the very least) having to close the project. i think that danny's right that we need to do something about the problem of naming. it's causing too many unnecessary issues. as a first step, i'll try to find some time tomorrow to add some documentation about naming to the entry guide so at least folks understand that we are likely to be sensitive to this issue. We're *such* a whacky bunch. that's true enough :-) given the amount of upset caused by names, i think that we should appoint sanjiva as chief-name-wangler. his role would be to seek out remote parts of the world with languages as yet untouched by commercial name mining and come back with a harvest of great new names for apache projects ;-) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Project Naming (was Re: [VOTE] Accept Glasgow into Incubator)
On 8/4/06, Sanjiva Weerawarana [EMAIL PROTECTED] wrote: IMO the reason this naming debate hasn't been settled is because of the way in which the change from Blaze to Glasgow was achieved: it was done privately and the result was announced here. hmm...sounds like we should have some docs that suggest that the moment a group of people proposes a new project for incubation (if they don't already have an existing open project mailing list), they should use the [EMAIL PROTECTED] list as their pre-project discussion list. When any question about the proposal comes up, all proposed committers (10-20 of them) are encouraged to have their own discussion on our lists to work out what they'd like to do. Might even be better to say that the moment a few of them have an idea for the proposal, they should use our general list to discuss the proposal drafts before proposing it to us. ;-) I have no doubt that every committer of every proposal I've ever been involved has understood the importance of open discussions on apache lists once the project starts. However, I think most of them have hesitated to use apache lists for project-specific discussions before their proposal has even been accepted (other than to respond to concerns/questions from the incubator community). We're *such* a whacky bunch. indeed, we are. Clif - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
Garrett Rooney wrote: Finally, and I hate to say this because it may very well be just a cultural difference between projects the Glasgow developers have worked on and the way things work in ASF projects I'm familiar with, I think it's disturbing that all answers to questions concerning this proposal have been discussed in private and fed back to us through a single person. I don't see a community of individuals here, I see a collection of companies working to bring a new project to the ASF because they can benefit from the brand, and while that can certainly change with time its combination with the other problems means I can't vote in favor of the proposal. One reason for this may be that many of the issues questions raised have been about the ownership and control of the specification and not the glasgow project itself. I accept that a project whose goal is the implementation of a specification must necessarily be judged with reference to that specification. However, that not all the developers of a particular implementation of a specification feel qualified to comment on legal issues relating to that specification, or to the processes that govern it, should not be taken as implying that they do not participate as individuals within their project. Questions for the protocol group may well require discussion and agreement amongst the members of that group and as those members do not correspond to the members of the glasgow proposal this list would not be an appropriate place for that discussion. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
Hi everybody, I don't have a binding vote here, but.. -1 I strongly object to the name, in some sense I object to this name because it is also the name of the city in which I work, and conversations about Glasgow will be a bit wierd. But very much more importantly I would also like to publicly stand up and say that I think it is ridiculous that time after time we misappropriate proper nouns to name our projects with. Stop it. Stop it now. It is misguided to think that it can be done without making a cultural reference, and it is naieve to think that all such references will be appropriate or well received by those whose culture is being misrepresented. The fact that Glasgow is not an impoverished and exploited region of Africa or Asia doesn't make it any less inappropriate to use it as a project name. I think it is about time that we grew up and introduced a rule which prevents words already used as proper nouns from being proposed as project names unless there is some real and relevant on-topic connection. Don't be lazy, if trademarks and IP make it difficult to pick an apropriate name straight away don't just revert to sticking a pin in the map, get out a thesaurus. With the notable and highly significant exceptions of Apache and Jakarta (both of which raise difficult questions) it seems as if it has only really become common practice since the incubator with Derby, Geronimo, Tuscany, Woden to name some that I know about. You guys have the chance to stop it by rejecting this project on the basis of its name. Please take this opportunity to stop the rot. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
Danny Angus wrote: I think it is about time that we grew up and introduced a rule which prevents words already used as proper nouns from being proposed as project names unless there is some real and relevant on-topic connection. Just by way of explanation, this name was proposed as (a) it is where the project began and (b) it is a port, which was felt to have a loose association with messaging. As a connection (a) is certainly real, though I can understand that the relevance of (b) might be viewed as rather tenuous. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
On 8/4/06, Gordon Sim [EMAIL PROTECTED] wrote: Danny Angus wrote: I think it is about time that we grew up and introduced a rule which prevents words already used as proper nouns from being proposed as project names unless there is some real and relevant on-topic connection. Just by way of explanation, this name was proposed as (a) it is where the project began and (b) it is a port, which was felt to have a loose association with messaging. As a connection (a) is certainly real, though I can understand that the relevance of (b) might be viewed as rather tenuous. Note that these reasons would have been obvious if the discussion on what to change the name to had happened in public... -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
On 04/08/06, Garrett Rooney [EMAIL PROTECTED] wrote: Note that these reasons would have been obvious if the discussion on what to change the name to had happened in public... Quite. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
On 04/08/06, Gordon Sim [EMAIL PROTECTED] wrote: Danny Angus wrote: I think it is about time that we grew up and introduced a rule which prevents words already used as proper nouns from being proposed as project names unless there is some real and relevant on-topic connection. Just by way of explanation, this name was proposed as (a) it is where the project began and (b) it is a port, which was felt to have a loose association with messaging. As a connection (a) is certainly real, though I can understand that the relevance of (b) might be viewed as rather tenuous. If pressed I wouldn't think that those were good reasons, a) is just a coincidence and b) is a pun. A good reason would be that it had been funded by the city, or had become associated with one if the city's institutions. like the GHC and JAF. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
So it would be fine if development had been funded by the public sector (in the form of Glasgow City Council) but since it was funded by a private organisation it's not ok? Robert |-+ | | Danny Angus| | | [EMAIL PROTECTED]| | | l.com | | || | | 04/08/2006 14:47 | | | Please respond to| | | general | |-+ | | | | To: general@incubator.apache.org | | cc: | | Subject: Re: [VOTE] Accept Glasgow into Incubator | | On 04/08/06, Gordon Sim [EMAIL PROTECTED] wrote: Danny Angus wrote: I think it is about time that we grew up and introduced a rule which prevents words already used as proper nouns from being proposed as project names unless there is some real and relevant on-topic connection. Just by way of explanation, this name was proposed as (a) it is where the project began and (b) it is a port, which was felt to have a loose association with messaging. As a connection (a) is certainly real, though I can understand that the relevance of (b) might be viewed as rather tenuous. If pressed I wouldn't think that those were good reasons, a) is just a coincidence and b) is a pun. A good reason would be that it had been funded by the city, or had become associated with one if the city's institutions. like the GHC and JAF. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase Co., its subsidiaries and affiliates. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Project Naming (was Re: [VOTE] Accept Glasgow into Incubator)
The project formerly known as Blaze changed its name to Glasgow based on previous feedback and decided to follow Apache precedent (e.g. Tuscany). Apparently there are strong objections to this precendent. In our discussions, the group did come up with some ingenious names for the project, but most had legal concerns or conflicted with existing software. Glasgow was the winner mostly by process of elimination. Danny, I'm confident that none of the committers are particularly attached to the name and no one wants to see the proposal sidetracked over the name of the project. So, we welcome any help in selecting a name that does not have any software trademarks in the USPTO and isn't connected to other relevant software projects. -- Archit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
On 8/3/06, Mads Toftum [EMAIL PROTECTED] wrote: On Thu, Aug 03, 2006 at 05:54:14PM -0400, Garrett Rooney wrote: I'm sorry, but I have to vote -1 (binding). I very much agree with Garretts concerns - and would be much in favor of not bringing the project into incubation before they have proven an actual community and that they can work the standard the apache way. I feel it would look very much as an ASF endorsement of a standard that we may not have any influence on at all - maybe things will look different in a few months time, but right now I'm far from convinced. I understand that there are some specific circumstances in this case, but in general I believe this sort of criteria is why we get complaints that it's impossible to innovate at Apache any more. We require all the grunt work of innovation to occur outside of Apache. The issues of an open specification is one thing. But aren't proven an actual community and work the standard 'apache way' graduation requirements, not entry requirements? If we expect something coming into the incubator to already have a fully functioning, health Apache-style community, then the only point of the Incubator is for handling licensing issues. -- jaaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
On 8/4/06, J Aaron Farr [EMAIL PROTECTED] wrote: On 8/3/06, Mads Toftum [EMAIL PROTECTED] wrote: On Thu, Aug 03, 2006 at 05:54:14PM -0400, Garrett Rooney wrote: I'm sorry, but I have to vote -1 (binding). I very much agree with Garretts concerns - and would be much in favor of not bringing the project into incubation before they have proven an actual community and that they can work the standard the apache way. I feel it would look very much as an ASF endorsement of a standard that we may not have any influence on at all - maybe things will look different in a few months time, but right now I'm far from convinced. I understand that there are some specific circumstances in this case, but in general I believe this sort of criteria is why we get complaints that it's impossible to innovate at Apache any more. We require all the grunt work of innovation to occur outside of Apache. The issues of an open specification is one thing. But aren't proven an actual community and work the standard 'apache way' graduation requirements, not entry requirements? If we expect something coming into the incubator to already have a fully functioning, health Apache-style community, then the only point of the Incubator is for handling licensing issues. For what it's worth, I don't have any intrinsic problem with a group bringing some code to the ASF in an attempt to start a community around it, as long as that's what's actually happening. The general feeling I got from reading the mail around this proposal wasn't leaning in that direction, now that could just be a missunderstanding on my part, but it is part of what convinced me to vote -1. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Project Naming (was Re: [VOTE] Accept Glasgow into Incubator)
Archit, I'm very happy to here you say so, I certainly don't want to affect your progress through the incubator, in many ways I've unfairly sigled you out as an example of a prectice I feel strongly about. Unfortunately I will be away, offline, for the next four days, but if it is still relevant I will be happy to take up your kind offer and put in time helping to find an acceptable, strike that, a good name. d. On 04/08/06, Archit Shah [EMAIL PROTECTED] wrote: The project formerly known as Blaze changed its name to Glasgow based on previous feedback and decided to follow Apache precedent (e.g. Tuscany). Apparently there are strong objections to this precendent. In our discussions, the group did come up with some ingenious names for the project, but most had legal concerns or conflicted with existing software. Glasgow was the winner mostly by process of elimination. Danny, I'm confident that none of the committers are particularly attached to the name and no one wants to see the proposal sidetracked over the name of the project. So, we welcome any help in selecting a name that does not have any software trademarks in the USPTO and isn't connected to other relevant software projects. -- Archit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Project Naming (was Re: [VOTE] Accept Glasgow into Incubator)
Martin- yes we solved it recently. But... the process of solving that is not quite clear. I created an issue / task in JIRA for that. I am only refering to the trademark issue; the rest was pretty easy, the community voted on the name. We only ensured that no names with *potential* trademark troubles we available in the vote. We collected the names with a JIRA ticket :-) -Matthias On 8/4/06, Martin van den Bemt [EMAIL PROTECTED] wrote: Also if I recall correctly, naming issues can also be solved while in the incbuator... (like adffaces has) Mvgr, Martin Danny Angus wrote: Archit, I'm very happy to here you say so, I certainly don't want to affect your progress through the incubator, in many ways I've unfairly sigled you out as an example of a prectice I feel strongly about. Unfortunately I will be away, offline, for the next four days, but if it is still relevant I will be happy to take up your kind offer and put in time helping to find an acceptable, strike that, a good name. d. On 04/08/06, Archit Shah [EMAIL PROTECTED] wrote: The project formerly known as Blaze changed its name to Glasgow based on previous feedback and decided to follow Apache precedent (e.g. Tuscany). Apparently there are strong objections to this precendent. In our discussions, the group did come up with some ingenious names for the project, but most had legal concerns or conflicted with existing software. Glasgow was the winner mostly by process of elimination. Danny, I'm confident that none of the committers are particularly attached to the name and no one wants to see the proposal sidetracked over the name of the project. So, we welcome any help in selecting a name that does not have any software trademarks in the USPTO and isn't connected to other relevant software projects. -- Archit - 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] -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
On 8/4/06, Garrett Rooney [EMAIL PROTECTED] wrote: On 8/4/06, J Aaron Farr [EMAIL PROTECTED] wrote: On 8/3/06, Mads Toftum [EMAIL PROTECTED] wrote: On Thu, Aug 03, 2006 at 05:54:14PM -0400, Garrett Rooney wrote: I'm sorry, but I have to vote -1 (binding). I very much agree with Garretts concerns - and would be much in favor of not bringing the project into incubation before they have proven an actual community and that they can work the standard the apache way. I feel it would look very much as an ASF endorsement of a standard that we may not have any influence on at all - maybe things will look different in a few months time, but right now I'm far from convinced. I understand that there are some specific circumstances in this case, but in general I believe this sort of criteria is why we get complaints that it's impossible to innovate at Apache any more. We require all the grunt work of innovation to occur outside of Apache. The issues of an open specification is one thing. But aren't proven an actual community and work the standard 'apache way' graduation requirements, not entry requirements? If we expect something coming into the incubator to already have a fully functioning, health Apache-style community, then the only point of the Incubator is for handling licensing issues. For what it's worth, I don't have any intrinsic problem with a group bringing some code to the ASF in an attempt to start a community around it, as long as that's what's actually happening. The general feeling I got from reading the mail around this proposal wasn't leaning in that direction, now that could just be a missunderstanding on my part, but it is part of what convinced me to vote -1. Of course everyone should make their own minds about this after a careful reading of the threads (and may see things differently), but I wouldn't have agreed to champion the proposal if I had the sense there was not a commitment to create an open/transparent/meritocratic community around the project; nor would I, as a mentor, ever allow any project to move through incubation without actively working to create such a community. Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
On 8/4/06, Cliff Schmidt [EMAIL PROTECTED] wrote: Of course everyone should make their own minds about this after a careful reading of the threads (and may see things differently), but I wouldn't have agreed to champion the proposal if I had the sense there was not a commitment to create an open/transparent/meritocratic community around the project; I'm certainly not going to argue with Cliff on this point, I'm sure he has seen that commitment and thus can say that's what the people bringing this proposal to us want to do, but personally, I don't have that sort of insight into the situation at hand, I haven't had the sort of interaction with the people involved that Cliff has, so all I can base my opinion on is what's happened on this mailing list. In any event, any questions I have about intentions regarding forming open, meritocratic communities are only being raised because of the relationship they have with the ability of new contributors to participate in driving this specification. The issues are interconnected. nor would I, as a mentor, ever allow any project to move through incubation without actively working to create such a community. I have no doubt that this is the case, and if I said anything that implies otherwise I'm sorry. I have a great deal of faith in Cliff as a mentor, and I trust him to do the right thing with regard to building communities at the ASF. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
I understand that there are some specific circumstances in this case, but in general I believe this sort of criteria is why we get complaints that it's impossible to innovate at Apache any more. We require all the grunt work of innovation to occur outside of Apache. The issues of an open specification is one thing. But aren't proven an actual community and work the standard 'apache way' graduation requirements, not entry requirements? If we expect something coming into the incubator to already have a fully functioning, health Apache-style community, then the only point of the Incubator is for handling licensing issues. This is quite interesting... Over at Wicket we have been operating 'the Apache way' from a very early stage in the project (about two years). We have mail archives, commit logs, releases, and history of letting new committers in to prove all that if people are willing to spend an hour looking for it. But we feel we have to prove ourselves all over again as the incubation process expects it's podlings to prove themselves within the confines of the incubation process. The incubation process might benefit from having a categorization of projects that want to enter. Such categorization basically answers: * How old are these projects, how many committers, how large is the community of developers and users? * Has the project been working apache style for a certain time (the time being a categorization in itself). If it has, there is no question about prove - it'll be there as that is one of the key factors of working the apache way (mailing lists, committers etc.)? This categorization would then be the starting point for answering two things that I think are currently missing in the whole incubation process (please do tell me if I am wrong/ missed something): * To what extend can information about the project's readiness be gathered based on the (outside) history of the project, and how much information needs to be gathered additionally during incubation? The availability of such history could get some load of the backs of the involved parties and might mean a shorter incubation time. * What would be the proposed time estimate for the whole incubation? Factor time currently seems to be non existent in the incubation process. But 'it takes how long it takes' imo does not cut it. I believe the incubation process would benefit from formalizing timelines and milestones so that both parties keep focussed on making progress. Having a schedule for incubation would also mean that involved parties could use that schedule for any other plans they might be making. For example, we (Wicket) would like to have our 2.0 version to be released at Apache, after (if) we're done with incubation. There is currently no way to even remotely predict when that might happen. This is inconvenient for our users, but also is a problem as we are writing a book on that version and our publisher *does* want to know when that book will be ready for publishing. Having a code base that is release-ready but that's just waiting for months for the incubation process to move on for some unknown time is unacceptable to us. The kind of schedule I am thinking of would be semi-binding. If we meet the requirements for the milestone in time, we go on to the next stage, unless there is absolute consensus we shouldn't based on something other that the milestone requirements. If we don't meet the requirements in time, incubation may be terminated for that reason alone. I couldn't find any previous discussions on these topics, but if I missed them, my apologies and please reply with an URL. Otherwise, I'd be very interested to hear what others think of this. Also, I am not specifically proposing anything concrete for Wicket's incubation at this time; I wouldn't want to get in the way of our mentors :) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
On 8/4/06, Garrett Rooney [EMAIL PROTECTED] wrote: On 8/4/06, Cliff Schmidt [EMAIL PROTECTED] wrote: nor would I, as a mentor, ever allow any project to move through incubation without actively working to create such a community. I have no doubt that this is the case, and if I said anything that implies otherwise I'm sorry. I have a great deal of faith in Cliff as a mentor, and I trust him to do the right thing with regard to building communities at the ASF. Oh I definitely didn't take any offense, but I appreciate your comment. My point was just to remind folks that these proposals come with mentors who are there to ensure the critical community-building aspect (which was the concern of yours I was responding to) of the project gets the needed attention...or the project will eventually get booted out. I would hate to ever be associated with a project that failed incubation, but I have no problem with voting to kick out a project that isn't trying to make things work. I think the difference in our opinions may come down to trust in the incubation process. We've firmly established over the years that we want to have a relatively low bar for entry into incubation (usually some sort of initial code, committers to go with it, and an understanding and willingness to adopt/apply our community principles). This approach is supposed to welcome all those who want to try to make this work with us. We've never required that the project is already operating like an Apache project; instead, we ensure they are doing so before graduation. And, if it's not working out, we retire the project before it ever gets the full ASF endorsement. I only agreed to mentor this project after talking to, literally, every single committer to make sure they understood how we do things, that they were willing to commit to the required community work, and that they understood that people like me will intervene if things aren't going well. I do this, because, otherwise, I'd just be setting myself up for a really frustrating 6-24 months. I completely respect your opinion, but I don't think that a proposal thread is a representative environment for determining the expected degree of transparency in future development work, nor do I think that the spec this project wants to implement is less open than several others being implemented at Apache today (including ones at official standards orgs)...but you'll have to read my very long post if you care to know more of my thoughts on that: http://mail-archives.apache.org/mod_mbox/incubator-general/200607.mbox/[EMAIL PROTECTED] Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
Cliff Schmidt wrote: I believe all open questions about the Glasgow proposal (originally submitted as Blaze) have now been addressed enough to call a vote for accepting the project for incubation. Cliff, so it is not lost (I switched subjects to a discussion forum that, oddly, you have not responded to) ... I'm sorry, but respectfully -1 this proposal as written. My specific objection is to the language below, I don't see anything otherwise objectionable in the proposal. [c.f. the Re: Accept Glasgow into Incubator - Spec Terms thread which only Carl has partly responded to.] which is my vote on your call for acceptance. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Project Naming (was Re: [VOTE] Accept Glasgow into Incubator)
IMO the reason this naming debate hasn't been settled is because of the way in which the change from Blaze to Glasgow was achieved: it was done privately and the result was announced here. I can imagine how frustrating this must be to folks who are new to Apache, but folks here don't like private stuff. If you come here you must be willing to open your kimono all the way, not just let us take a peek thru a small crack. An example was the Ajax proposal .. the name got rejected and we had a public debate here and created Kabuki (which of course proceeded to have a failure to launch but that's another movie). In any case, if there are naming issues we can certainly deal with them during incubation and simply make it a graduation criteria to come up with a better name. I can see why marketing types will get upset by that but again educating the marketing community to deal with the Apache Way is a requirement to survive here too :-). The PRC folks will take the sledge hammer on that one! We're *such* a whacky bunch. Sanjiva. On Sat, 2006-08-05 at 00:41 +0200, Martin van den Bemt wrote: Also if I recall correctly, naming issues can also be solved while in the incbuator... (like adffaces has) Mvgr, Martin Danny Angus wrote: Archit, I'm very happy to here you say so, I certainly don't want to affect your progress through the incubator, in many ways I've unfairly sigled you out as an example of a prectice I feel strongly about. Unfortunately I will be away, offline, for the next four days, but if it is still relevant I will be happy to take up your kind offer and put in time helping to find an acceptable, strike that, a good name. d. On 04/08/06, Archit Shah [EMAIL PROTECTED] wrote: The project formerly known as Blaze changed its name to Glasgow based on previous feedback and decided to follow Apache precedent (e.g. Tuscany). Apparently there are strong objections to this precendent. In our discussions, the group did come up with some ingenious names for the project, but most had legal concerns or conflicted with existing software. Glasgow was the winner mostly by process of elimination. Danny, I'm confident that none of the committers are particularly attached to the name and no one wants to see the proposal sidetracked over the name of the project. So, we welcome any help in selecting a name that does not have any software trademarks in the USPTO and isn't connected to other relevant software projects. -- Archit - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Accept Glasgow into Incubator
I believe all open questions about the Glasgow proposal (originally submitted as Blaze) have now been addressed enough to call a vote for accepting the project for incubation. Therefore, as the champion of this project, I am calling a vote. As usual, the binding votes will be those case by Incubator PMC members (since the project is requesting sponsorship from the Incubator PMC); however all participants on this list are encouraged to vote if they have a strong feeling one way or another. The traditional 72-hour voting period would end during a weekend for most timezones; so I propose extending that by an additional day, with the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see http://www.timeanddate.com/worldclock/fixedtime.html?month=8day=7year=2006hour=17min=0sec=0p1=0) Please vote on the Glasgow proposal, as described below, which can also be found at: http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1. Note the old wiki page (with the full history of changes since the original proposal) can be found here: http://wiki.apache.org/incubator/Blaze Cliff = Glasgow Proposal (renamed from Blaze) = == RATIONALE == Glasgow provides multiple language implementations of the Advanced Messaged Queuing Protocol (AMQP) specification and related technologies including PGM, transaction management, queuing, distribution, security, management and heterogeneous multi-platform support for messaging (links to these specifications are in the Initial Source section of this proposal.) Glasgow's overall goal is to create an open and interoperable implementation for messaging which implements the emerging AMQP specification, in keeping with the philosophy of the Foundation. This implementation will provide a messaging solution that will be language and platform agnostic by using a well defined wire specification. Providing both libraries for the framing and protocol in addition to brokers in both Java and C/C++ allows for integration with Apache and non-Apache projects in a manner that facilitates heterogeneous deployment with full interoperability for SOA distributed systems. The seed code for the project will consist of in-progress C/C++ and Java implementations of the AMQP specification that we intend to continue development on in conjunction with other Apache communities. More information on the scope of the seed code can be found in subsequent sections of this proposal. == CRITERIA == === Meritocracy: === The Glasgow committers recognize the desirability and necessity of running this project as a full meritocracy; indeed, the scope of the project's technical aspects are so varied that we find it hard to envision success any other way. One of the most important lessons that can be derived from the historic evolution of middleware is that specifications architected in isolation from real usable code that has been developed to solve tangible, real world problems or amongst a narrowly restricted list of contributors often do not see widespread adoption. Our goal in crafting this implementation and providing our learning to the specification team is to develop the best possible language agnostic advanced message queuing platform. We understand that in order to do so, we will need to engage all interested members of the community and operate to the standard of meritocracy that characterizes successful Apache projects. === Community: === The project's primary objective is to build a vibrant community of users and active contributors. Although Glasgow is not based on an existing open source community, many of the initial contributors have experience participating in and building other open source communities. Several of the contributors have previously participated in Apache communities. We understand that Apache's community governance protocols are a unique contributor to the success of Apache's project communities and we are eager to learn from our Incubator mentors so that we can evolve Glasgow into a healthy and sustainable community. === Core Developers: === Most of the initial committers are members of Red Hat, IONA, and JP Morgan Chase's (JPMC) development teams. Additional developers will be added through the Apache community process. === Alignment: === An initial implementation has been written in Java and C++, which will be refactored into this project to form the initial code base. We have had a few exploratory conversations about integration with individuals of other communties such as Apache Geronimo, Tuscany, ActiveMQ, Fedora and ObjectWeb's Celtix and hope to work towards future collaboration with these communities. Our current implementation makes extensive use of projects from the Apache Jakata Commons, Mina and other Apache infrastructure projects. A compatibility binding for JMS also exists. It is however important to note that this is NOT a JMS project and aims to solve a different problem space, providing language and platform independent and
Re: [VOTE] Accept Glasgow into Incubator
+1 from me. On 8/3/06, Cliff Schmidt [EMAIL PROTECTED] wrote: I believe all open questions about the Glasgow proposal (originally submitted as Blaze) have now been addressed enough to call a vote for accepting the project for incubation. Therefore, as the champion of this project, I am calling a vote. As usual, the binding votes will be those case by Incubator PMC members (since the project is requesting sponsorship from the Incubator PMC); however all participants on this list are encouraged to vote if they have a strong feeling one way or another. The traditional 72-hour voting period would end during a weekend for most timezones; so I propose extending that by an additional day, with the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see http://www.timeanddate.com/worldclock/fixedtime.html?month=8day=7year=2006hour=17min=0sec=0p1=0) Please vote on the Glasgow proposal, as described below, which can also be found at: http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1. Note the old wiki page (with the full history of changes since the original proposal) can be found here: http://wiki.apache.org/incubator/Blaze Cliff = Glasgow Proposal (renamed from Blaze) = == RATIONALE == Glasgow provides multiple language implementations of the Advanced Messaged Queuing Protocol (AMQP) specification and related technologies including PGM, transaction management, queuing, distribution, security, management and heterogeneous multi-platform support for messaging (links to these specifications are in the Initial Source section of this proposal.) Glasgow's overall goal is to create an open and interoperable implementation for messaging which implements the emerging AMQP specification, in keeping with the philosophy of the Foundation. This implementation will provide a messaging solution that will be language and platform agnostic by using a well defined wire specification. Providing both libraries for the framing and protocol in addition to brokers in both Java and C/C++ allows for integration with Apache and non-Apache projects in a manner that facilitates heterogeneous deployment with full interoperability for SOA distributed systems. The seed code for the project will consist of in-progress C/C++ and Java implementations of the AMQP specification that we intend to continue development on in conjunction with other Apache communities. More information on the scope of the seed code can be found in subsequent sections of this proposal. == CRITERIA == === Meritocracy: === The Glasgow committers recognize the desirability and necessity of running this project as a full meritocracy; indeed, the scope of the project's technical aspects are so varied that we find it hard to envision success any other way. One of the most important lessons that can be derived from the historic evolution of middleware is that specifications architected in isolation from real usable code that has been developed to solve tangible, real world problems or amongst a narrowly restricted list of contributors often do not see widespread adoption. Our goal in crafting this implementation and providing our learning to the specification team is to develop the best possible language agnostic advanced message queuing platform. We understand that in order to do so, we will need to engage all interested members of the community and operate to the standard of meritocracy that characterizes successful Apache projects. === Community: === The project's primary objective is to build a vibrant community of users and active contributors. Although Glasgow is not based on an existing open source community, many of the initial contributors have experience participating in and building other open source communities. Several of the contributors have previously participated in Apache communities. We understand that Apache's community governance protocols are a unique contributor to the success of Apache's project communities and we are eager to learn from our Incubator mentors so that we can evolve Glasgow into a healthy and sustainable community. === Core Developers: === Most of the initial committers are members of Red Hat, IONA, and JP Morgan Chase's (JPMC) development teams. Additional developers will be added through the Apache community process. === Alignment: === An initial implementation has been written in Java and C++, which will be refactored into this project to form the initial code base. We have had a few exploratory conversations about integration with individuals of other communties such as Apache Geronimo, Tuscany, ActiveMQ, Fedora and ObjectWeb's Celtix and hope to work towards future collaboration with these communities. Our current implementation makes extensive use of projects from the Apache Jakata Commons, Mina and other Apache infrastructure projects. A compatibility binding for JMS also exists. It is however important to note that this is NOT a JMS project and aims to solve a different problem
Re: [VOTE] Accept Glasgow into Incubator
+1 (non-binding) from me too On 8/3/06, Davanum Srinivas [EMAIL PROTECTED] wrote: +1 from me. On 8/3/06, Cliff Schmidt [EMAIL PROTECTED] wrote: I believe all open questions about the Glasgow proposal (originally submitted as Blaze) have now been addressed enough to call a vote for accepting the project for incubation. Therefore, as the champion of this project, I am calling a vote. As usual, the binding votes will be those case by Incubator PMC members (since the project is requesting sponsorship from the Incubator PMC); however all participants on this list are encouraged to vote if they have a strong feeling one way or another. The traditional 72-hour voting period would end during a weekend for most timezones; so I propose extending that by an additional day, with the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see http://www.timeanddate.com/worldclock/fixedtime.html?month=8day=7year=2006hour=17min=0sec=0p1=0) Please vote on the Glasgow proposal, as described below, which can also be found at: http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1. Note the old wiki page (with the full history of changes since the original proposal) can be found here: http://wiki.apache.org/incubator/Blaze Cliff = Glasgow Proposal (renamed from Blaze) = == RATIONALE == Glasgow provides multiple language implementations of the Advanced Messaged Queuing Protocol (AMQP) specification and related technologies including PGM, transaction management, queuing, distribution, security, management and heterogeneous multi-platform support for messaging (links to these specifications are in the Initial Source section of this proposal.) Glasgow's overall goal is to create an open and interoperable implementation for messaging which implements the emerging AMQP specification, in keeping with the philosophy of the Foundation. This implementation will provide a messaging solution that will be language and platform agnostic by using a well defined wire specification. Providing both libraries for the framing and protocol in addition to brokers in both Java and C/C++ allows for integration with Apache and non-Apache projects in a manner that facilitates heterogeneous deployment with full interoperability for SOA distributed systems. The seed code for the project will consist of in-progress C/C++ and Java implementations of the AMQP specification that we intend to continue development on in conjunction with other Apache communities. More information on the scope of the seed code can be found in subsequent sections of this proposal. == CRITERIA == === Meritocracy: === The Glasgow committers recognize the desirability and necessity of running this project as a full meritocracy; indeed, the scope of the project's technical aspects are so varied that we find it hard to envision success any other way. One of the most important lessons that can be derived from the historic evolution of middleware is that specifications architected in isolation from real usable code that has been developed to solve tangible, real world problems or amongst a narrowly restricted list of contributors often do not see widespread adoption. Our goal in crafting this implementation and providing our learning to the specification team is to develop the best possible language agnostic advanced message queuing platform. We understand that in order to do so, we will need to engage all interested members of the community and operate to the standard of meritocracy that characterizes successful Apache projects. === Community: === The project's primary objective is to build a vibrant community of users and active contributors. Although Glasgow is not based on an existing open source community, many of the initial contributors have experience participating in and building other open source communities. Several of the contributors have previously participated in Apache communities. We understand that Apache's community governance protocols are a unique contributor to the success of Apache's project communities and we are eager to learn from our Incubator mentors so that we can evolve Glasgow into a healthy and sustainable community. === Core Developers: === Most of the initial committers are members of Red Hat, IONA, and JP Morgan Chase's (JPMC) development teams. Additional developers will be added through the Apache community process. === Alignment: === An initial implementation has been written in Java and C++, which will be refactored into this project to form the initial code base. We have had a few exploratory conversations about integration with individuals of other communties such as Apache Geronimo, Tuscany, ActiveMQ, Fedora and ObjectWeb's Celtix and hope to work towards future collaboration with these communities. Our current implementation makes extensive use of projects from the Apache Jakata Commons, Mina and other Apache
Re: [VOTE] Accept Glasgow into Incubator
+1 (non-binding) from me. Craig On Aug 3, 2006, at 9:52 AM, Cliff Schmidt wrote: I believe all open questions about the Glasgow proposal (originally submitted as Blaze) have now been addressed enough to call a vote for accepting the project for incubation. Therefore, as the champion of this project, I am calling a vote. As usual, the binding votes will be those case by Incubator PMC members (since the project is requesting sponsorship from the Incubator PMC); however all participants on this list are encouraged to vote if they have a strong feeling one way or another. The traditional 72-hour voting period would end during a weekend for most timezones; so I propose extending that by an additional day, with the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see http://www.timeanddate.com/worldclock/fixedtime.html? month=8day=7year=2006hour=17min=0sec=0p1=0) Please vote on the Glasgow proposal, as described below, which can also be found at: http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1. Note the old wiki page (with the full history of changes since the original proposal) can be found here: http://wiki.apache.org/incubator/Blaze Cliff = Glasgow Proposal (renamed from Blaze) = == RATIONALE == Glasgow provides multiple language implementations of the Advanced Messaged Queuing Protocol (AMQP) specification and related technologies including PGM, transaction management, queuing, distribution, security, management and heterogeneous multi-platform support for messaging (links to these specifications are in the Initial Source section of this proposal.) Glasgow's overall goal is to create an open and interoperable implementation for messaging which implements the emerging AMQP specification, in keeping with the philosophy of the Foundation. This implementation will provide a messaging solution that will be language and platform agnostic by using a well defined wire specification. Providing both libraries for the framing and protocol in addition to brokers in both Java and C/C++ allows for integration with Apache and non-Apache projects in a manner that facilitates heterogeneous deployment with full interoperability for SOA distributed systems. The seed code for the project will consist of in-progress C/C++ and Java implementations of the AMQP specification that we intend to continue development on in conjunction with other Apache communities. More information on the scope of the seed code can be found in subsequent sections of this proposal. == CRITERIA == === Meritocracy: === The Glasgow committers recognize the desirability and necessity of running this project as a full meritocracy; indeed, the scope of the project's technical aspects are so varied that we find it hard to envision success any other way. One of the most important lessons that can be derived from the historic evolution of middleware is that specifications architected in isolation from real usable code that has been developed to solve tangible, real world problems or amongst a narrowly restricted list of contributors often do not see widespread adoption. Our goal in crafting this implementation and providing our learning to the specification team is to develop the best possible language agnostic advanced message queuing platform. We understand that in order to do so, we will need to engage all interested members of the community and operate to the standard of meritocracy that characterizes successful Apache projects. === Community: === The project's primary objective is to build a vibrant community of users and active contributors. Although Glasgow is not based on an existing open source community, many of the initial contributors have experience participating in and building other open source communities. Several of the contributors have previously participated in Apache communities. We understand that Apache's community governance protocols are a unique contributor to the success of Apache's project communities and we are eager to learn from our Incubator mentors so that we can evolve Glasgow into a healthy and sustainable community. === Core Developers: === Most of the initial committers are members of Red Hat, IONA, and JP Morgan Chase's (JPMC) development teams. Additional developers will be added through the Apache community process. === Alignment: === An initial implementation has been written in Java and C++, which will be refactored into this project to form the initial code base. We have had a few exploratory conversations about integration with individuals of other communties such as Apache Geronimo, Tuscany, ActiveMQ, Fedora and ObjectWeb's Celtix and hope to work towards future collaboration with these communities. Our current implementation makes extensive use of projects from the Apache Jakata Commons, Mina and other Apache infrastructure projects. A compatibility binding for JMS also exists. It is however important to note that this is NOT a JMS project and aims to
RE: [VOTE] Accept Glasgow into Incubator
+1 (non binding) from me. A question unrelated to voting: What is the possible (estimated) minimum implementation footprint (in term of kilobytes or megabytes) to support AMQP network wire-level protocol? I am asking this thinking of the possibility of using AMQP protocol in mobile applications such as J2ME. ---Coach Wei -Original Message- From: Cliff Schmidt [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 12:52 PM To: general@incubator.apache.org Subject: [VOTE] Accept Glasgow into Incubator I believe all open questions about the Glasgow proposal (originally submitted as Blaze) have now been addressed enough to call a vote for accepting the project for incubation. Therefore, as the champion of this project, I am calling a vote. As usual, the binding votes will be those case by Incubator PMC members (since the project is requesting sponsorship from the Incubator PMC); however all participants on this list are encouraged to vote if they have a strong feeling one way or another. The traditional 72-hour voting period would end during a weekend for most timezones; so I propose extending that by an additional day, with the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see http://www.timeanddate.com/worldclock/fixedtime.html?month=8day=7year= 20 06hour=17min=0sec=0p1=0) Please vote on the Glasgow proposal, as described below, which can also be found at: http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1. Note the old wiki page (with the full history of changes since the original proposal) can be found here: http://wiki.apache.org/incubator/Blaze Cliff = Glasgow Proposal (renamed from Blaze) = == RATIONALE == Glasgow provides multiple language implementations of the Advanced Messaged Queuing Protocol (AMQP) specification and related technologies including PGM, transaction management, queuing, distribution, security, management and heterogeneous multi-platform support for messaging (links to these specifications are in the Initial Source section of this proposal.) Glasgow's overall goal is to create an open and interoperable implementation for messaging which implements the emerging AMQP specification, in keeping with the philosophy of the Foundation. This implementation will provide a messaging solution that will be language and platform agnostic by using a well defined wire specification. Providing both libraries for the framing and protocol in addition to brokers in both Java and C/C++ allows for integration with Apache and non-Apache projects in a manner that facilitates heterogeneous deployment with full interoperability for SOA distributed systems. The seed code for the project will consist of in-progress C/C++ and Java implementations of the AMQP specification that we intend to continue development on in conjunction with other Apache communities. More information on the scope of the seed code can be found in subsequent sections of this proposal. == CRITERIA == === Meritocracy: === The Glasgow committers recognize the desirability and necessity of running this project as a full meritocracy; indeed, the scope of the project's technical aspects are so varied that we find it hard to envision success any other way. One of the most important lessons that can be derived from the historic evolution of middleware is that specifications architected in isolation from real usable code that has been developed to solve tangible, real world problems or amongst a narrowly restricted list of contributors often do not see widespread adoption. Our goal in crafting this implementation and providing our learning to the specification team is to develop the best possible language agnostic advanced message queuing platform. We understand that in order to do so, we will need to engage all interested members of the community and operate to the standard of meritocracy that characterizes successful Apache projects. === Community: === The project's primary objective is to build a vibrant community of users and active contributors. Although Glasgow is not based on an existing open source community, many of the initial contributors have experience participating in and building other open source communities. Several of the contributors have previously participated in Apache communities. We understand that Apache's community governance protocols are a unique contributor to the success of Apache's project communities and we are eager to learn from our Incubator mentors so that we can evolve Glasgow into a healthy and sustainable community. === Core Developers: === Most of the initial committers are members of Red Hat, IONA, and JP Morgan Chase's (JPMC) development teams. Additional developers will be added through the Apache community process. === Alignment: === An initial implementation has been written in Java and C++, which will be refactored into this project to form
Re: [VOTE] Accept Glasgow into Incubator
+1 On 3 Aug 06, at 12:52 PM 3 Aug 06, Cliff Schmidt wrote: I believe all open questions about the Glasgow proposal (originally submitted as Blaze) have now been addressed enough to call a vote for accepting the project for incubation. Therefore, as the champion of this project, I am calling a vote. As usual, the binding votes will be those case by Incubator PMC members (since the project is requesting sponsorship from the Incubator PMC); however all participants on this list are encouraged to vote if they have a strong feeling one way or another. The traditional 72-hour voting period would end during a weekend for most timezones; so I propose extending that by an additional day, with the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see http://www.timeanddate.com/worldclock/fixedtime.html? month=8day=7year=2006hour=17min=0sec=0p1=0) Please vote on the Glasgow proposal, as described below, which can also be found at: http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1. Note the old wiki page (with the full history of changes since the original proposal) can be found here: http://wiki.apache.org/incubator/Blaze Cliff = Glasgow Proposal (renamed from Blaze) = == RATIONALE == Glasgow provides multiple language implementations of the Advanced Messaged Queuing Protocol (AMQP) specification and related technologies including PGM, transaction management, queuing, distribution, security, management and heterogeneous multi-platform support for messaging (links to these specifications are in the Initial Source section of this proposal.) Glasgow's overall goal is to create an open and interoperable implementation for messaging which implements the emerging AMQP specification, in keeping with the philosophy of the Foundation. This implementation will provide a messaging solution that will be language and platform agnostic by using a well defined wire specification. Providing both libraries for the framing and protocol in addition to brokers in both Java and C/C++ allows for integration with Apache and non-Apache projects in a manner that facilitates heterogeneous deployment with full interoperability for SOA distributed systems. The seed code for the project will consist of in-progress C/C++ and Java implementations of the AMQP specification that we intend to continue development on in conjunction with other Apache communities. More information on the scope of the seed code can be found in subsequent sections of this proposal. == CRITERIA == === Meritocracy: === The Glasgow committers recognize the desirability and necessity of running this project as a full meritocracy; indeed, the scope of the project's technical aspects are so varied that we find it hard to envision success any other way. One of the most important lessons that can be derived from the historic evolution of middleware is that specifications architected in isolation from real usable code that has been developed to solve tangible, real world problems or amongst a narrowly restricted list of contributors often do not see widespread adoption. Our goal in crafting this implementation and providing our learning to the specification team is to develop the best possible language agnostic advanced message queuing platform. We understand that in order to do so, we will need to engage all interested members of the community and operate to the standard of meritocracy that characterizes successful Apache projects. === Community: === The project's primary objective is to build a vibrant community of users and active contributors. Although Glasgow is not based on an existing open source community, many of the initial contributors have experience participating in and building other open source communities. Several of the contributors have previously participated in Apache communities. We understand that Apache's community governance protocols are a unique contributor to the success of Apache's project communities and we are eager to learn from our Incubator mentors so that we can evolve Glasgow into a healthy and sustainable community. === Core Developers: === Most of the initial committers are members of Red Hat, IONA, and JP Morgan Chase's (JPMC) development teams. Additional developers will be added through the Apache community process. === Alignment: === An initial implementation has been written in Java and C++, which will be refactored into this project to form the initial code base. We have had a few exploratory conversations about integration with individuals of other communties such as Apache Geronimo, Tuscany, ActiveMQ, Fedora and ObjectWeb's Celtix and hope to work towards future collaboration with these communities. Our current implementation makes extensive use of projects from the Apache Jakata Commons, Mina and other Apache infrastructure projects. A compatibility binding for JMS also exists. It is however important to note that this is NOT a JMS project and aims to solve a different problem
Re: [VOTE] Accept Glasgow into Incubator
Coach, If you don't view your question as related to the vote, would you mind reposting it to a separate or an existing thread about Glasgow? Maybe it's just my personal preference, but I like to keep vote threads to just votes and critical questions that were missed in the prior discussion (which, I admit, often doesn't happen). Thanks, Cliff -Original Message- From: Coach Wei [EMAIL PROTECTED] Date: Thu, 3 Aug 2006 11:32:14 To:general@incubator.apache.org Subject: RE: [VOTE] Accept Glasgow into Incubator +1 (non binding) from me. A question unrelated to voting: What is the possible (estimated) minimum implementation footprint (in term of kilobytes or megabytes) to support AMQP network wire-level protocol? I am asking this thinking of the possibility of using AMQP protocol in mobile applications such as J2ME. ---Coach Wei -Original Message- From: Cliff Schmidt [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 12:52 PM To: general@incubator.apache.org Subject: [VOTE] Accept Glasgow into Incubator I believe all open questions about the Glasgow proposal (originally submitted as Blaze) have now been addressed enough to call a vote for accepting the project for incubation. Therefore, as the champion of this project, I am calling a vote. As usual, the binding votes will be those case by Incubator PMC members (since the project is requesting sponsorship from the Incubator PMC); however all participants on this list are encouraged to vote if they have a strong feeling one way or another. The traditional 72-hour voting period would end during a weekend for most timezones; so I propose extending that by an additional day, with the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see http://www.timeanddate.com/worldclock/fixedtime.html?month=8day=7year= 20 06hour=17min=0sec=0p1=0) Please vote on the Glasgow proposal, as described below, which can also be found at: http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1. Note the old wiki page (with the full history of changes since the original proposal) can be found here: http://wiki.apache.org/incubator/Blaze Cliff = Glasgow Proposal (renamed from Blaze) = == RATIONALE == Glasgow provides multiple language implementations of the Advanced Messaged Queuing Protocol (AMQP) specification and related technologies including PGM, transaction management, queuing, distribution, security, management and heterogeneous multi-platform support for messaging (links to these specifications are in the Initial Source section of this proposal.) Glasgow's overall goal is to create an open and interoperable implementation for messaging which implements the emerging AMQP specification, in keeping with the philosophy of the Foundation. This implementation will provide a messaging solution that will be language and platform agnostic by using a well defined wire specification. Providing both libraries for the framing and protocol in addition to brokers in both Java and C/C++ allows for integration with Apache and non-Apache projects in a manner that facilitates heterogeneous deployment with full interoperability for SOA distributed systems. The seed code for the project will consist of in-progress C/C++ and Java implementations of the AMQP specification that we intend to continue development on in conjunction with other Apache communities. More information on the scope of the seed code can be found in subsequent sections of this proposal. == CRITERIA == === Meritocracy: === The Glasgow committers recognize the desirability and necessity of running this project as a full meritocracy; indeed, the scope of the project's technical aspects are so varied that we find it hard to envision success any other way. One of the most important lessons that can be derived from the historic evolution of middleware is that specifications architected in isolation from real usable code that has been developed to solve tangible, real world problems or amongst a narrowly restricted list of contributors often do not see widespread adoption. Our goal in crafting this implementation and providing our learning to the specification team is to develop the best possible language agnostic advanced message queuing platform. We understand that in order to do so, we will need to engage all interested members of the community and operate to the standard of meritocracy that characterizes successful Apache projects. === Community: === The project's primary objective is to build a vibrant community of users and active contributors. Although Glasgow is not based on an existing open source community, many of the initial contributors have experience participating in and building other open source communities. Several of the contributors have previously participated in Apache communities. We understand that Apache's community governance protocols
Re: [VOTE] Accept Glasgow into Incubator
+1 On Aug 3, 2006, at 12:52 PM, Cliff Schmidt wrote: I believe all open questions about the Glasgow proposal (originally submitted as Blaze) have now been addressed enough to call a vote for accepting the project for incubation. Therefore, as the champion of this project, I am calling a vote. As usual, the binding votes will be those case by Incubator PMC members (since the project is requesting sponsorship from the Incubator PMC); however all participants on this list are encouraged to vote if they have a strong feeling one way or another. The traditional 72-hour voting period would end during a weekend for most timezones; so I propose extending that by an additional day, with the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see http://www.timeanddate.com/worldclock/fixedtime.html? month=8day=7year=2006hour=17min=0sec=0p1=0) Please vote on the Glasgow proposal, as described below, which can also be found at: http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1. Note the old wiki page (with the full history of changes since the original proposal) can be found here: http://wiki.apache.org/incubator/Blaze Cliff = Glasgow Proposal (renamed from Blaze) = == RATIONALE == Glasgow provides multiple language implementations of the Advanced Messaged Queuing Protocol (AMQP) specification and related technologies including PGM, transaction management, queuing, distribution, security, management and heterogeneous multi-platform support for messaging (links to these specifications are in the Initial Source section of this proposal.) Glasgow's overall goal is to create an open and interoperable implementation for messaging which implements the emerging AMQP specification, in keeping with the philosophy of the Foundation. This implementation will provide a messaging solution that will be language and platform agnostic by using a well defined wire specification. Providing both libraries for the framing and protocol in addition to brokers in both Java and C/C++ allows for integration with Apache and non-Apache projects in a manner that facilitates heterogeneous deployment with full interoperability for SOA distributed systems. The seed code for the project will consist of in-progress C/C++ and Java implementations of the AMQP specification that we intend to continue development on in conjunction with other Apache communities. More information on the scope of the seed code can be found in subsequent sections of this proposal. == CRITERIA == === Meritocracy: === The Glasgow committers recognize the desirability and necessity of running this project as a full meritocracy; indeed, the scope of the project's technical aspects are so varied that we find it hard to envision success any other way. One of the most important lessons that can be derived from the historic evolution of middleware is that specifications architected in isolation from real usable code that has been developed to solve tangible, real world problems or amongst a narrowly restricted list of contributors often do not see widespread adoption. Our goal in crafting this implementation and providing our learning to the specification team is to develop the best possible language agnostic advanced message queuing platform. We understand that in order to do so, we will need to engage all interested members of the community and operate to the standard of meritocracy that characterizes successful Apache projects. === Community: === The project's primary objective is to build a vibrant community of users and active contributors. Although Glasgow is not based on an existing open source community, many of the initial contributors have experience participating in and building other open source communities. Several of the contributors have previously participated in Apache communities. We understand that Apache's community governance protocols are a unique contributor to the success of Apache's project communities and we are eager to learn from our Incubator mentors so that we can evolve Glasgow into a healthy and sustainable community. === Core Developers: === Most of the initial committers are members of Red Hat, IONA, and JP Morgan Chase's (JPMC) development teams. Additional developers will be added through the Apache community process. === Alignment: === An initial implementation has been written in Java and C++, which will be refactored into this project to form the initial code base. We have had a few exploratory conversations about integration with individuals of other communties such as Apache Geronimo, Tuscany, ActiveMQ, Fedora and ObjectWeb's Celtix and hope to work towards future collaboration with these communities. Our current implementation makes extensive use of projects from the Apache Jakata Commons, Mina and other Apache infrastructure projects. A compatibility binding for JMS also exists. It is however important to note that this is NOT a JMS project and aims to solve a different problem space,
Re: [VOTE] Accept Glasgow into Incubator
+1 -- jaaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
+1
Re: [VOTE] Accept Glasgow into Incubator
Coach, If you don't view your question as related to the vote, would you mind reposting it to a separate or an existing thread about Glasgow? Maybe it's just my personal preference, but I like to keep vote threads to just votes and critical questions that were missed in the prior discussion (which, I admit, often doesn't happen). Thanks, Cliff -Original Message- From: Coach Wei [EMAIL PROTECTED] Date: Thu, 3 Aug 2006 11:32:14 To:general@incubator.apache.org Subject: RE: [VOTE] Accept Glasgow into Incubator +1 (non binding) from me. A question unrelated to voting: What is the possible (estimated) minimum implementation footprint (in term of kilobytes or megabytes) to support AMQP network wire-level protocol? I am asking this thinking of the possibility of using AMQP protocol in mobile applications such as J2ME. ---Coach Wei -Original Message- From: Cliff Schmidt [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 12:52 PM To: general@incubator.apache.org Subject: [VOTE] Accept Glasgow into Incubator I believe all open questions about the Glasgow proposal (originally submitted as Blaze) have now been addressed enough to call a vote for accepting the project for incubation. Therefore, as the champion of this project, I am calling a vote. As usual, the binding votes will be those case by Incubator PMC members (since the project is requesting sponsorship from the Incubator PMC); however all participants on this list are encouraged to vote if they have a strong feeling one way or another. The traditional 72-hour voting period would end during a weekend for most timezones; so I propose extending that by an additional day, with the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see http://www.timeanddate.com/worldclock/fixedtime.html?month=8day=7year= 20 06hour=17min=0sec=0p1=0) Please vote on the Glasgow proposal, as described below, which can also be found at: http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1. Note the old wiki page (with the full history of changes since the original proposal) can be found here: http://wiki.apache.org/incubator/Blaze Cliff = Glasgow Proposal (renamed from Blaze) = == RATIONALE == Glasgow provides multiple language implementations of the Advanced Messaged Queuing Protocol (AMQP) specification and related technologies including PGM, transaction management, queuing, distribution, security, management and heterogeneous multi-platform support for messaging (links to these specifications are in the Initial Source section of this proposal.) Glasgow's overall goal is to create an open and interoperable implementation for messaging which implements the emerging AMQP specification, in keeping with the philosophy of the Foundation. This implementation will provide a messaging solution that will be language and platform agnostic by using a well defined wire specification. Providing both libraries for the framing and protocol in addition to brokers in both Java and C/C++ allows for integration with Apache and non-Apache projects in a manner that facilitates heterogeneous deployment with full interoperability for SOA distributed systems. The seed code for the project will consist of in-progress C/C++ and Java implementations of the AMQP specification that we intend to continue development on in conjunction with other Apache communities. More information on the scope of the seed code can be found in subsequent sections of this proposal. == CRITERIA == === Meritocracy: === The Glasgow committers recognize the desirability and necessity of running this project as a full meritocracy; indeed, the scope of the project's technical aspects are so varied that we find it hard to envision success any other way. One of the most important lessons that can be derived from the historic evolution of middleware is that specifications architected in isolation from real usable code that has been developed to solve tangible, real world problems or amongst a narrowly restricted list of contributors often do not see widespread adoption. Our goal in crafting this implementation and providing our learning to the specification team is to develop the best possible language agnostic advanced message queuing platform. We understand that in order to do so, we will need to engage all interested members of the community and operate to the standard of meritocracy that characterizes successful Apache projects. === Community: === The project's primary objective is to build a vibrant community of users and active contributors. Although Glasgow is not based on an existing open source community, many of the initial contributors have experience participating in and building other open source communities. Several of the contributors have previously participated in Apache communities. We understand that Apache's community governance protocols
Re: [VOTE] Accept Glasgow into Incubator
I'm sorry, but I have to vote -1 (binding). I'm not in favor of the ASF endorsing a specification that seems to be completely under the control of a small number of companies with no way for new developers to participate in its development. The fact that we have done this in the past is unfortunate, but it doesn't change things in my opinion. AMQP seems to be moving in this direction, they've got some sort of agreement you can sign in order to provide them feedback, that's a step, but I don't see any mailing lists, I don't see any way for someone who doesn't work for one of the companies in question to join as an equal member, and in general I think it's premature for the ASF to get involved, and accepting an incubator project is getting involved. Additionally, since we've already decided that we need to do something about the open/closed specification question with regard to incubator projects, I think it's unfair to bring a new project into the incubator when it's possible that our decision could result in that project not being able to graduate. If we know we're going to have that debate eventually we should do so now, to wait until after the project is in incubation seems unfair to them. Finally, and I hate to say this because it may very well be just a cultural difference between projects the Glasgow developers have worked on and the way things work in ASF projects I'm familiar with, I think it's disturbing that all answers to questions concerning this proposal have been discussed in private and fed back to us through a single person. I don't see a community of individuals here, I see a collection of companies working to bring a new project to the ASF because they can benefit from the brand, and while that can certainly change with time its combination with the other problems means I can't vote in favor of the proposal. -garrett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
On Thu, Aug 03, 2006 at 05:54:14PM -0400, Garrett Rooney wrote: I'm sorry, but I have to vote -1 (binding). I very much agree with Garretts concerns - and would be much in favor of not bringing the project into incubation before they have proven an actual community and that they can work the standard the apache way. I feel it would look very much as an ASF endorsement of a standard that we may not have any influence on at all - maybe things will look different in a few months time, but right now I'm far from convinced. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Glasgow into Incubator
-1 I think that this project is premature until the spec is in an open, inclusive process or at an acceptable standards body with compatible licensing terms. I would embrace this project were it so. The project is supposed to be implementations of a standard protocol but the protocol in question is proprietary and is under the control of a group of companies whose employees make up the initial committer list. It is impossible for individuals to join the protocol specification body, and even then the means of decision making is not specified. While it is a proprietary, closed-group protocol it cannot be called a standard, and the project is, in fact, implementing a protocol under the control of a subset of the employers of the contributors to the project. If the protocol were being developed under an open, inclusive process which was compatible with how Apache works in general (which includes processes in standards bodies which conduct business in that way, or which have established sufficient reputation to allay these worries) I would be very much in favor of this proposal. -Brian On Aug 3, 2006, at 9:52 AM, Cliff Schmidt wrote: I believe all open questions about the Glasgow proposal (originally submitted as Blaze) have now been addressed enough to call a vote for accepting the project for incubation. Therefore, as the champion of this project, I am calling a vote. As usual, the binding votes will be those case by Incubator PMC members (since the project is requesting sponsorship from the Incubator PMC); however all participants on this list are encouraged to vote if they have a strong feeling one way or another. The traditional 72-hour voting period would end during a weekend for most timezones; so I propose extending that by an additional day, with the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see http://www.timeanddate.com/worldclock/fixedtime.html? month=8day=7year=2006hour=17min=0sec=0p1=0) Please vote on the Glasgow proposal, as described below, which can also be found at: http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1. Note the old wiki page (with the full history of changes since the original proposal) can be found here: http://wiki.apache.org/incubator/Blaze Cliff = Glasgow Proposal (renamed from Blaze) = == RATIONALE == Glasgow provides multiple language implementations of the Advanced Messaged Queuing Protocol (AMQP) specification and related technologies including PGM, transaction management, queuing, distribution, security, management and heterogeneous multi-platform support for messaging (links to these specifications are in the Initial Source section of this proposal.) Glasgow's overall goal is to create an open and interoperable implementation for messaging which implements the emerging AMQP specification, in keeping with the philosophy of the Foundation. This implementation will provide a messaging solution that will be language and platform agnostic by using a well defined wire specification. Providing both libraries for the framing and protocol in addition to brokers in both Java and C/C++ allows for integration with Apache and non-Apache projects in a manner that facilitates heterogeneous deployment with full interoperability for SOA distributed systems. The seed code for the project will consist of in-progress C/C++ and Java implementations of the AMQP specification that we intend to continue development on in conjunction with other Apache communities. More information on the scope of the seed code can be found in subsequent sections of this proposal. == CRITERIA == === Meritocracy: === The Glasgow committers recognize the desirability and necessity of running this project as a full meritocracy; indeed, the scope of the project's technical aspects are so varied that we find it hard to envision success any other way. One of the most important lessons that can be derived from the historic evolution of middleware is that specifications architected in isolation from real usable code that has been developed to solve tangible, real world problems or amongst a narrowly restricted list of contributors often do not see widespread adoption. Our goal in crafting this implementation and providing our learning to the specification team is to develop the best possible language agnostic advanced message queuing platform. We understand that in order to do so, we will need to engage all interested members of the community and operate to the standard of meritocracy that characterizes successful Apache projects. === Community: === The project's primary objective is to build a vibrant community of users and active contributors. Although Glasgow is not based on an existing open source community, many of the initial contributors have experience participating in and building other open source communities. Several of the contributors have previously participated in Apache communities. We understand that Apache's community governance
Re: [VOTE] Accept Glasgow into Incubator
+1 (non-binding) On Thu, 2006-08-03 at 09:52 -0700, Cliff Schmidt wrote: I believe all open questions about the Glasgow proposal (originally submitted as Blaze) have now been addressed enough to call a vote for accepting the project for incubation. Therefore, as the champion of this project, I am calling a vote. As usual, the binding votes will be those case by Incubator PMC members (since the project is requesting sponsorship from the Incubator PMC); however all participants on this list are encouraged to vote if they have a strong feeling one way or another. The traditional 72-hour voting period would end during a weekend for most timezones; so I propose extending that by an additional day, with the vote closing on Monday, August 7, 2006 17:00 UTC / 10:00 PDT (see http://www.timeanddate.com/worldclock/fixedtime.html?month=8day=7year=2006hour=17min=0sec=0p1=0) Please vote on the Glasgow proposal, as described below, which can also be found at: http://wiki.apache.org/incubator/GlasgowProposal?action=recallrev=1. Note the old wiki page (with the full history of changes since the original proposal) can be found here: http://wiki.apache.org/incubator/Blaze
