Re: [VOTE] Accept Composer in the Incubator
On Oct 23, 2007, at 1:46 PM, Kevan Miller wrote: I took a peek at plexus and picocontainer mailing lists. One thing of note is that there seems to have been little discussion on the picocontainer lists about a move to Apache. Perhaps discussions were offline, but it's not clear to me how their community, beyond Paul Hammant, feels about the move... I don't see a big issue with this (at least not anything that won't be sorted out by incubation), just passing along what I learned... well, that's kinda par-for-the-course with the pico community.. its pretty darn silent :) fwiw, there were offline discussions, and the entirety of the active committership was involved. -pete -- (peter.royal|osi)@pobox.com - http://fotap.org/~osi smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Accept Composer in the Incubator
On Oct 22, 2007, at 12:13 AM, Jason van Zyl wrote: As mentioned previously, both containers are heavily used, both have always lived as open source projects. Plexus has 17 Apache committers, Pico has 4 so most of the participants are already familiar with projects here. [ ] +1 Accept Composer project for incubation +1 -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi smime.p7s Description: S/MIME cryptographic signature
Re: [PROPOSAL] Buildr
On 10/24/07, Matthieu Riou <[EMAIL PROTECTED]> wrote: > ...= Initial Committers = > > * Assaf Arkin > * Alex Boisvert > * Matthieu Riou... Considering the recent discussions about diversity, would it be ok for you to include these people's company affiliations in the proposal? -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] approve stdcxx 4.2.0 release
The stdcxx community has just successfully closed a vote to release stdcxx 4.2.0. In accordance with the Releases section of the Incubation Policy we request the permission of the Incubator PMC to publish the tarball containing the release on the stdcxx Download page. This vote will close in the usual 72 hours, on Friday, October 26 at 8PM MDT. See http://tinyurl.com/3cnwoj for the countdown. Thanks Martin Vote result (contains links to the tarball and README containing the required incubation artifacts): http://www.nabble.com/-VOTE-RESULT--release-stdcxx-4.2.0-%28candidate-7%29-p13377405.html Stdcxx Download page: http://incubator.apache.org/stdcxx/download.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Apache RAT
I'll volunteer...having done lot's of releases for Geronimo I have an affinity for the little beast. On Oct 23, 2007, at 4:52 PM, Robert Burrell Donkin wrote: On 10/23/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: Mentors -- * Yoav Shapira * Ross Gardler I would prefer mentors who have not been involved with RAT. This will allow a more objective perspective. I doubt that supervision will be too great a burden. RAT would benefit from another mentor if there's anyone willing to volunteer - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduate Tuscany as a top level project
Jim, Thanks for this feedback. I think you raise a good point that one of the goals of community building is discovering a community's true synergies and strengths and that sometimes the right outcome is not a single community. Where goals are mis-aligned then a respectful change of direction is sometimes the best path. I trust your work is going well over at Codehaus and that y'all are fairing well and building a community is going also flourishing. Although I don't follow the Fabric 3 work I can say that Tuscany has settled into a pace and cadence that suits them. I trust you are on a similar path. On Oct 23, 2007, at 12:14 PM, Jim Marino wrote: It does seem both it and our community (Fabric3) have a lot less friction and are growing nicely. Sometimes communities just diverge based on differences of opinion, technical or otherwise, and trying to villainize one group is the wrong approach since it is not constructive.
Re: [PROPOSAL] Buildr
> Here is a proposal for Buildr incubation. Buildr is a simple and intuitive > build system for Java projects written in Ruby (and based on Rake). The > complete proposal is at [1] and also reproduced at the end of this e-mail. > > Feedback and questions are very welcome! Mentors volunteering too :) Sweet! I think Buildr would make an excellent addition to the Apache family, and I definitively think you should aim to be a top level project. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Buildr
Hi, Here is a proposal for Buildr incubation. Buildr is a simple and intuitive build system for Java projects written in Ruby (and based on Rake). The complete proposal is at [1] and also reproduced at the end of this e-mail. Feedback and questions are very welcome! Mentors volunteering too :) Thanks! Matthieu [1] http://wiki.apache.org/incubator/BuildrProposal -- = Abstract = Buildr is a simple and intuitive build system for Java projects. = Proposal = Buildr is a build system for Java applications. We wanted something that's simple and intuitive to use, so we only need to tell it what to do, and it takes care of the rest. But also something we can easily extend for those one-off tasks, with a language that's a joy to use. And of course, we wanted it to be fast, reliable and have outstanding dependency management. Here's what we got: * A simple way to specify projects, and build large projects out of smaller sub-projects. * Pre-canned tasks that require the least amount of configuration, keeping the build script DRY and simple. * Compiling, copying and filtering resources, JUnit/TestNG test cases, APT source code generation, Javadoc and more. * A dependency mechanism that only build that which changed since the last release. * Buildr uses the same file layout, artifact specifications, local and remote repositories as Maven 2. * All your Ant tasks belong to us! Anything you can do with Ant, you can do with Buildr. * Buildr is Ruby all the way down. No one-off task is too demanding when you write code using variables, functions and objects. * Simple way to upgrade to new versions. * Did we mention fast? = Background = Buildr is developed using the Ruby language and is layered on top of Rake, a popular build program for Ruby that provides all the task and task dependency infrastructure. It also relies on AntWrap to allow the reuse of all existing Ant tasks. = Rationale = Buildr's initial focus was to be layered on top of a powerful scripting language. It's an internal DSL and therefore enjoys a lot of ease of use and extensibility. It's also declarative, which gives scripts expressiveness (they're easy to read). And there's no XML! We believe bringing Buildr at Apache is a good way to expand even more the build tool space, attract more committers and users to Buildr and have people start playing with the Ruby language, both within and outside the foundation. = Current Status = == Meritocracy == Buildr has been mostly developed by Assaf Arkin but others have contributed either directly or through patches. In addition to contributed patches, work on Scala and JRuby is done by community members, and we're working to cultivate that and add more committers. == Community == A community of standard users but also power users is building around Buildr and several people are using it in all sort of different projects. Currently the discussion group has 86 members, more statistics available at http://groups.google.com/group/buildr-talk?lnk=srg == Core Developers == Core developers are mostly from a single organization but more and more power users are contributing patches and trying to extend Buildr. Also current core developers are very experienced in open source and already follow the Apache ways. == Alignment == Buildr is in line with the existing strong culture of build tools at Apache (Ant, Maven, Ivy, ...). It already relies on Maven2 repositories and follows most of its project structure conventions. It allows reuse of Ant tasks. Not to mention that other Apache projects could use it for their build (as ODE already does). = Known Risks = == Orphaned Projects == Buildr core development is still very much dependent on Assaf but more and more people are getting familiar with the way Buildr works and its intricacies. So we're aware of the problem but also confident that we're on the right track as more and more people get involved. == Inexperience with Open Source == Many committers have experience working on open source projects. Three of them are Apache committers. == Reliance on Salaried Developers == Buildr is part of the committers job but is far from being the main company focus. So it's part working time and part personal time. == Relationships with Other Apache Products == As there aren't many Ruby projects in the ASF yet, there's less relationship possible for the time being. But Apache ODE is already using Buildr as its build tool. = Documentation & Intial Sources = The current Buildr website is at: http://buildr.rubyforge.org The Buildr sources are available at: http://www.intalio.org/buildr == External Dependencies == External dependencies are one of the main concerns that will need to be addressed. Buildr relies on several packages that are licensed under the Ruby License, which hasn't been categorized yet as okay or not. We've already men
Re: [PROPOSAL] Apache RAT
On 10/23/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > Mentors > -- > > * Yoav Shapira > * Ross Gardler > > I would prefer mentors who have not been involved with RAT. This will > allow a more objective perspective. I doubt that supervision will be > too great a burden. RAT would benefit from another mentor if there's anyone willing to volunteer - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Composer in the Incubator
+1 I took a peek at plexus and picocontainer mailing lists. One thing of note is that there seems to have been little discussion on the picocontainer lists about a move to Apache. Perhaps discussions were offline, but it's not clear to me how their community, beyond Paul Hammant, feels about the move... I don't see a big issue with this (at least not anything that won't be sorted out by incubation), just passing along what I learned... --kevan On Oct 22, 2007, at 3:13 AM, Jason van Zyl wrote: Hi, The proposal for Composer has been drafted here: http://wiki.apache.org/incubator/ComposerProposal As mentioned previously, both containers are heavily used, both have always lived as open source projects. Plexus has 17 Apache committers, Pico has 4 so most of the participants are already familiar with projects here. [ ] +1 Accept Composer project for incubation [ ] 0 Don't care [ ] -1 Reject for the following reason : Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Apache RAT
On 10/23/07, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > http://wiki.apache.org/incubator/RatProposal has been stable for a > while now so i'd like to throw it open to final scrutiny before i call > for a VOTE. (please don't vote yet ;-) Looks like a solid proposal to me! As far as the name is concerned, I still like RAT the most. You could opt for 'ratifier'. A google search didn't come up with commercial products or open source projects. Martijn -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0-beta4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Composer dependency on "BSH"
He meant BSF, though Plexus can optionally use BSH as a component factory. On 23 Oct 07, at 11:48 AM 23 Oct 07, sebb wrote: The Wiki proposal mentions that Composer has an optional dependency on the Apache project "BSH". I could not find an Apache project called BSH. Is is then BeanShell (which is not an Apache project) or should it be "BSF" (which is Apache)? Or perhaps something else entirely? S On 22/10/2007, Jason van Zyl <[EMAIL PROTECTED]> wrote: Hi, The proposal for Composer has been drafted here: http://wiki.apache.org/incubator/ComposerProposal As mentioned previously, both containers are heavily used, both have always lived as open source projects. Plexus has 17 Apache committers, Pico has 4 so most of the participants are already familiar with projects here. [ ] +1 Accept Composer project for incubation [ ] 0 Don't care [ ] -1 Reject for the following reason : Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Apache RAT
http://wiki.apache.org/incubator/RatProposal has been stable for a while now so i'd like to throw it open to final scrutiny before i call for a VOTE. (please don't vote yet ;-) the name "RAT" has been discussed previously - see http://mail-archives.apache.org/mod_mbox/incubator-general/200710.mbox/[EMAIL PROTECTED] RAT is a good name and popular but i'm still a little concerned that there are existing open source projects named RAT as well as commercial software containing RAT in their name. Apache aRAT has the advantage of being unused but the disadvantage of being a common name in some other languages. if anyone strongly disagrees with the consensus that RAT is ok and prefers aRAT please jump in now. - robert Rat Proposal == Abstract -- RAT is comprehension and auditing for distributions and source code. Proposal --- RAT will provide a focus for components, applications and integration tools for the comprehension and audit of distributions and source code. It will collect data and meta-data as required. It will create suitable schemas for this data and meta-data as required. Background -- RAT began as an attempt to automate the technical part of reviewing releases in the incubator. Following requests for access from release managers, RAT was developed as an open source project under the Apache License 2.0. Rationale --- Reviewing releases for compliance with Apache technical criteria and policies is time consuming. The Incubator requires that all releases are reviewed. Though small mistakes are common, this process typically adds only a little value. It is common for candidates to be presented with small but significant defects which then must be fixed and the candidate represented. Significant energy and good will is wasted by this process. This is unnecessary. Given effort, these technical criteria are capable of automation. Automated continuous checking of the source would allow the Incubator PMC to be alerted promptly to potential issues. Integration with build tools (such as Apache Ant and Apache Maven) would allow releases to be checked automatically and continuously. Initial Goals - * Read standard license meta-data for documents without license headers * Improved RAT reporting * RAT source reporting for major build tools * Continuous RAT * RAT analytics: using meta-data to verify rules o Apache third party documents policy analysis o license compatibility analysis * Discordia integration to allow distributed binaries to be recognised * RAT analytic integration for major build tools * Improved recursive RAT scripts for better analysis of release with many distributables Current Status Meritocracy -- I'm very happy to move from a solo development model towards a collective one as more active developers are recruited. Community - The RAT community needs to be developed. Having RAT here at Apache will hopefully encourage release managers to take a more active role in developing RAT. Core Developers It has been developed principally by myself but with significant contributions of small amounts of code from other Apache members and committers. Alignment RAT has found itself becoming a standard part of the Apache release infrastructure. The Incubator needs fully featured release tools. It makes sense to bring the project here. Known Risks == Orphaned Projects -- This is a project with a set of definite goals aimed at serving the wider Apache community. There may well come a time when the coding is actually finished. It has a small set of developers who all have many other calls on their time. The target user audience is relatively small. So, this risk is real. I think that it's clear that something similar to RAT is required. So, unless another better product is developed, time will be found to push RAT forward. Even if one day, RAT is orphaned then it will have done it's job. Inexperience With Open Source - The contributors are Apache members or experienced Apache committers. Reliance On Salaried Developers --- I know of no one who's paid to work on RAT. Relationships with Other Apache Products -- RAT contains an Ant reporting plugin. Codehaus hosts a Maven reporting plugin. Analytic plugins for Ant and Maven will be developed. There are overlaps with Tika and there has been some talk of collaboration. The discordia lab will likely be used for license and artifact meta-data. RAT may integrate with Gump for continuous code scanning. Initial Source --- * [WWW] http://code.google.com/p/arat/source * [WWW] http://mojo.codehaus.org/rat-maven-plugin External Dependencies Compliant with current Apache policy. Cryptography
Re: Assigning issues in JIRA?
On 10/22/07, Craig L Russell <[EMAIL PROTECTED]> wrote: > Hi Janne, > > I'm copying the incubator general list for feedback from others with > more experience in ICLA vs. Software Grant... > > On Oct 22, 2007, at 10:47 AM, Janne Jalkanen wrote: > > >> Perhaps you can recap the status of the code. Was most of the code > >> written by a small number of people? Were there a large number of > >> substantial contributors at some point? Either a Software Grant or > >> an ICLA would be appropriate once we understand the nature of the > >> contributions. > > > > This reflects the current situation pretty accurately. I've > > contacted everyone, so I know how to find them. > > > > http://www.jspwiki.org/wiki/ApacheRelicensing > > > > If they don't want to sign an ICLA, a software grant is still > > sufficient? > > Yes. An ICLA covers current and future contributions, but if all they > want is to grant rights and not contribute further, a Software Grant > is fine. If they want to contribute in future, they can always submit > an ICLA later. this sounds right to me - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Composer dependency on "BSH"
The Wiki proposal mentions that Composer has an optional dependency on the Apache project "BSH". I could not find an Apache project called BSH. Is is then BeanShell (which is not an Apache project) or should it be "BSF" (which is Apache)? Or perhaps something else entirely? S On 22/10/2007, Jason van Zyl <[EMAIL PROTECTED]> wrote: > Hi, > > The proposal for Composer has been drafted here: > > http://wiki.apache.org/incubator/ComposerProposal > > As mentioned previously, both containers are heavily used, both have > always lived as open source projects. Plexus has 17 Apache > committers, Pico has 4 so most of the participants are already > familiar with projects here. > > [ ] +1 Accept Composer project for incubation > [ ] 0 Don't care > [ ] -1 Reject for the following reason : > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > jason at sonatype dot com > -- > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Composer in the Incubator
On Oct 23, 2007, at 2:30 PM, Jason van Zyl wrote: On 23 Oct 07, at 5:46 AM 23 Oct 07, Jim Jagielski wrote: On Oct 22, 2007, at 4:55 PM, Jason van Zyl wrote: On 22 Oct 07, at 10:36 AM 22 Oct 07, Jim Jagielski wrote: On Oct 22, 2007, at 12:13 AM, Jason van Zyl wrote: Plexus has 17 Apache committers, Pico has 4 so most of the participants are already familiar with projects here. But not all favorably it appears... Was there a particular response you were trying to illicit with that quote? Yes. It's called knowledge and background. What do you want to know? And I can provide any background you feel people should know about. You can't honestly expect to gather a whole lot from a cheeky remark uttered 4 years ago. It's really not all that; I'm not sure what you're getting at. The proposal makes note of the fact that several people are Apache committers. Sometimes, people involved in Incubator podlings need to make tough choices and decisions (like whether to tank it or not should that ever happen), and so any background which is appropriate to that discussion should be brought up and out at the start, rather than it being a potential issue latter on. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Composer in the Incubator
On 23 Oct 07, at 5:46 AM 23 Oct 07, Jim Jagielski wrote: On Oct 22, 2007, at 4:55 PM, Jason van Zyl wrote: On 22 Oct 07, at 10:36 AM 22 Oct 07, Jim Jagielski wrote: On Oct 22, 2007, at 12:13 AM, Jason van Zyl wrote: Plexus has 17 Apache committers, Pico has 4 so most of the participants are already familiar with projects here. But not all favorably it appears... Was there a particular response you were trying to illicit with that quote? Yes. It's called knowledge and background. What do you want to know? And I can provide any background you feel people should know about. You can't honestly expect to gather a whole lot from a cheeky remark uttered 4 years ago. Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduate Tuscany as a top level project
On Oct 23, 2007, at 6:43 AM, Davanum Srinivas wrote: Noel, I was there when it happened. It was actually the other way around..Short story, the "independents" had trouble letting anyone else work or suggest ideas which went against their own mental model of how things should be. When i argued for a middle path vociferously, they left. -- dims Dims, I was simply trying to clear up a point of ambiguity with respect to my (and by extension my employer's) involvement in Tuscany. I was hoping to avoid digging up the past, which doesn't serve good purposes. Were the independents completely intransigent or were the others inflexible? Sometimes people just have different goals and reconciliation doesn't work because things are too far apart. I and the others working on the SCA Java implementation left the project because there was constant friction and differences of opinion, and we felt it best for the two camps to go their separate ways. I previously explained my motivations here: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/% [EMAIL PROTECTED] Unfortunately, I don't have much time to follow Tuscany closely although I do check the lists occasionally. It does seem both it and our community (Fabric3) have a lot less friction and are growing nicely. Sometimes communities just diverge based on differences of opinion, technical or otherwise, and trying to villainize one group is the wrong approach since it is not constructive. I wish Tuscany luck as I work closely with some of those involved in the project on the SCA specifications and have a lot of technical and personal respect for them. Jim On 10/23/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: Matthieu Riou wrote: they did welcome enough independent committers while being in the incubator Attracting a large quantity of independent developers while being in the incubator is pretty hard Yes, but it seems to be emerging that there *were* more independents, and they have left to work actively elsewhere (as indicated by Jim Marino for BEA). Is this an indicator that the community wasn't able to embrace the interests of more than one vendor? Since SCA is a standard, why was there a need to fork the implementation? --- Noel P.S. I've removed [VOTE], since Ant indicates that the vote is being tabled for now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduate Tuscany as a top level project
Just one example of the community bending over back wards to accomodate Jim and Jeremy http://www.mail-archive.com/[EMAIL PROTECTED]/msg05118.html Please search for "chianti" in the archives to get the background. Basically the trunk was abandoned and the revolutionary "fork" was accepted *JUST* for community reasons. thanks, dims On 10/23/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > Noel, > > FYI, I could plainly see who was working hard to co-exist and who > wasnt'. IMHO, the people who left clearly did not want to > play/participate. It was sacrilege to do anything that was against > their mental model of things had to work. > > My 2 cents. > > -- dims > > On 10/23/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > Jim Marino wrote: > > > > > About seven months ago, BEA decided to pursue an alternative > > > direction with the other active independents working on SCA > > > at the time when our goals diverged from others in the community. > > > Speaking for BEA, we made it clear on multiple occasions that > > > while we wished Tuscany success, given the divergent interests, > > > we were satisfied with our decision to participate elsewhere. > > > It is unlikely we will revisit this decision in the future. > > > > This should be a cautionary tale to communities if a project cannot serve > > the interests of all its members. > > > > --- Noel > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Davanum Srinivas :: http://davanum.wordpress.com > -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduate Tuscany as a top level project
Noel, FYI, I could plainly see who was working hard to co-exist and who wasnt'. IMHO, the people who left clearly did not want to play/participate. It was sacrilege to do anything that was against their mental model of things had to work. My 2 cents. -- dims On 10/23/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Jim Marino wrote: > > > About seven months ago, BEA decided to pursue an alternative > > direction with the other active independents working on SCA > > at the time when our goals diverged from others in the community. > > Speaking for BEA, we made it clear on multiple occasions that > > while we wished Tuscany success, given the divergent interests, > > we were satisfied with our decision to participate elsewhere. > > It is unlikely we will revisit this decision in the future. > > This should be a cautionary tale to communities if a project cannot serve > the interests of all its members. > > --- Noel > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduate Tuscany as a top level project
Noel, I was there when it happened. It was actually the other way around..Short story, the "independents" had trouble letting anyone else work or suggest ideas which went against their own mental model of how things should be. When i argued for a middle path vociferously, they left. -- dims On 10/23/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > Matthieu Riou wrote: > > > they did welcome enough independent committers while being in the > > incubator > > > Attracting a large quantity of independent developers while being > > in the incubator is pretty hard > > Yes, but it seems to be emerging that there *were* more independents, and > they have left to work actively elsewhere (as indicated by Jim Marino for > BEA). Is this an indicator that the community wasn't able to embrace the > interests of more than one vendor? Since SCA is a standard, why was there a > need to fork the implementation? > > --- Noel > > P.S. I've removed [VOTE], since Ant indicates that the vote is being tabled > for now. > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas :: http://davanum.wordpress.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Graduate Tuscany as a top level project
Paul Fremantle wrote: > I think the PPMC needs this sort of concrete feedback. And perhaps needs to consider that diversity means supporting a broader community of interests. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Graduate Tuscany as a top level project
Jim Marino wrote: > About seven months ago, BEA decided to pursue an alternative > direction with the other active independents working on SCA > at the time when our goals diverged from others in the community. > Speaking for BEA, we made it clear on multiple occasions that > while we wished Tuscany success, given the divergent interests, > we were satisfied with our decision to participate elsewhere. > It is unlikely we will revisit this decision in the future. This should be a cautionary tale to communities if a project cannot serve the interests of all its members. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Graduate Tuscany as a top level project
Matthieu Riou wrote: > they did welcome enough independent committers while being in the > incubator > Attracting a large quantity of independent developers while being > in the incubator is pretty hard Yes, but it seems to be emerging that there *were* more independents, and they have left to work actively elsewhere (as indicated by Jim Marino for BEA). Is this an indicator that the community wasn't able to embrace the interests of more than one vendor? Since SCA is a standard, why was there a need to fork the implementation? --- Noel P.S. I've removed [VOTE], since Ant indicates that the vote is being tabled for now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept Composer in the Incubator
On Oct 22, 2007, at 4:55 PM, Jason van Zyl wrote: On 22 Oct 07, at 10:36 AM 22 Oct 07, Jim Jagielski wrote: On Oct 22, 2007, at 12:13 AM, Jason van Zyl wrote: Plexus has 17 Apache committers, Pico has 4 so most of the participants are already familiar with projects here. But not all favorably it appears... Was there a particular response you were trying to illicit with that quote? Yes. It's called knowledge and background. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
