Re: [VOTE] Bloodhound to join the Incubator
On Jan 3, 2012 2:30 AM, Ralph Goers ralph.go...@dslextreme.com wrote: On Jan 2, 2012, at 11:15 PM, Greg Stein wrote: On Jan 2, 2012 10:51 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Greg, I do not care one bit how much commit activity happens at Trac. As long as there is some kind of active community it is improper to fork it without their permission. Eh? You ever read the rules for revolutionaries page? The basic concept is: don't try to force two communities into one; when separate visions for the project occur, then separate them. I don't see it as our place to *judge* communities. If it is a fork, or a corporate spin-out, or a move, or brand new... All Good. We provide a temporary home in the Incubator to see if it can become a good, proper, and healthy Apache community. We don't turn them away a-priori based on their history. Greg, this seems to be so much B.S as it apparently serves some particular interest you have. I have no financial interest, if that is what you're implying. I *do* have an interest in seeing Bloodhound be successful. I've always been very impressed with the approach the Trac people have taken. It is a great tool. It is a great project, but I think it can be better. Bugzilla is popuar, but crap. There is no other OSS issue tracker that is good and popular. Trac is te closest, and (IMO) best hope for filling this gap in the OSS toolset. A PMC I am on had this exact conversation with board members several months ago regarding a code base the project is dependent on that is housed outside the ASF which we were considering bringing in as a subproject. We were told that under no circumstances could we fork the code without the owner's blessing, regardless of what the license allowed us to do. To me, this answer is black and white. Not to me. :-) In my mind, the Trac core has slowed, and it needs revitalization and a new vision. Others may disagree, and do, and that's fine. But I don't think it is fine for us to make judgements of communities (or nascent ones!) who want to try something new. To pick up and go in a direction that others are not heading, or do not have the time to make. I have no idea what you are saying. You ARE making a judgement on a community by saying it isn't active enough and deserves to be forked. Again, some of your fellow board members have said the ASF isn't the place for that. As a person wanting to see Apache Bloodhound take off... yeah, I'm making a judgement call on whether that can better occur at the ASF instead of within the current Trac community. (fwiw, some of the ideas are non-starters for Trac, so the *only* solution is do it outside the core project). I'm saying that the *ASF* should avoid judging. We allow competition among projects. We accept projects with hard problems and low chances of success. We accept projects that some don't want us to. We should not judge. We should provide a home to communities that want to be here. Cheers, -g
Re: [VOTE] Bloodhound to join the Incubator
minimal activity is the phrase I used. :-) On Jan 3, 2012 2:49 AM, Mark Struberg strub...@yahoo.de wrote: actually 6 commits in a month is not huge, but by far not nothing! We have projects here which have less commits per month... I wouldn't consider the Trac community dead. LieGrue, strub - Original Message - From: Niclas Hedhman nic...@hedhman.org To: general@incubator.apache.org Cc: Sent: Tuesday, January 3, 2012 6:17 AM Subject: Re: [VOTE] Bloodhound to join the Incubator On Tue, Jan 3, 2012 at 8:26 AM, Greg Stein gst...@gmail.com wrote: I think it important to highlight that trac-dev was notified on Dec 2 of the Bloodhound proposal, but Ethan and others didn't even notice for three weeks. The activity level on trunk, and the active committers can be seen on Ohloh: http://www.ohloh.net/p/trac/contributors?sort=latest_commit Looking at the timeline on trac.edgewall.org, it seems many of the commits are release-related or possibly on dev branches. It is kind of hard to tell. Trunk is certainly minimal activity. The Ohloh account is set up against trunk/ [1] only, so it is fairly straight forward; 30-Day Commit Activity Dec 2 — Jan 1 3 committers made 6 commits 15 files modified 46 lines added 11 lines removed And a svn log http://svn.edgewall.com/repos/trac/trunk gives you all the commits (why is this hard to tell?); 217 commits during 2011. I am pretty sure that is higher than some ASF projects. I am not putting any value to these numbers, just pointing to them on Ohloh and their SVN repository. [1] http://www.ohloh.net/p/trac/enlistments Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/6a2pl4j I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
On Jan 3, 2012, at 12:02 AM, Greg Stein wrote: As a person wanting to see Apache Bloodhound take off... yeah, I'm making a judgement call on whether that can better occur at the ASF instead of within the current Trac community. (fwiw, some of the ideas are non-starters for Trac, so the *only* solution is do it outside the core project). I'm saying that the *ASF* should avoid judging. We allow competition among projects. We accept projects with hard problems and low chances of success. We accept projects that some don't want us to. We should not judge. We should provide a home to communities that want to be here. I have no problem with competition among projects and everything else you say in the paragraph above. The only issue I have is that we can't take some other project's code and use it as the basis for a project here if the original project objects. It still isn't clear to me what the consensus is at Trac, but it certainly isn't overwhelmingly in favor. My suggestion is to simply continue working with them to either allay any fears they may have and possibly find a way to easily share the core code. If that doesn't work then I think perhaps you need to have a discussion at the next board meeting about how to resolve it. If it ends up that the actual Trac developers are OK with this or simply don't care then that would seem to me to be equivalent to them giving their approval. I haven't checked who has commented against the list of developers. In the end, I would also like to see Bloodhound move forward. However, I believe we need to be careful what precedents we are setting when these kinds of issues arise. You seem to be of the opinion that getting any project that wants to come to the ASF going is what is of importance. Mine is that we need to do that while respecting the rest of the open source community. Ralph
Re: [VOTE] Bloodhound to join the Incubator
On Tue, Jan 3, 2012 at 9:27 AM, Ralph Goers ralph.go...@dslextreme.com wrote: On Jan 3, 2012, at 12:02 AM, Greg Stein wrote: ...I'm saying that the *ASF* should avoid judging. We allow competition among projects. We accept projects with hard problems and low chances of success. We accept projects that some don't want us to. We should not judge. We should provide a home to communities that want to be here. I have no problem with competition among projects and everything else you say in the paragraph above. The only issue I have is that we can't take some other project's code and use it as the basis for a project here if the original project objects. It still isn't clear to me what the consensus is at Trac, but it certainly isn't overwhelmingly in favor... I agree that we don't want to support an unfriendly fork of Trac in Bloodhound, but as you say there doesn't seem to be an official consensus from the Trac project about this. IMO the best way of coming to closure on this issue is for the Trac community (as a whole) to state whether they agree with Bloodhound forking whatever they are planning to fork or not. Getting that agreement would, again IMO, be a condition for Bloodhound to graduate. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Link to CLA page incorrect on Podling Website Guid page
Don't know if this is the right mailing list, but reading http://incubator.apache.org/guides/sites.html the section Using A Wiki To Create Documentation contains an invalid link to http://incubator.apache.org/guides/clas in the sentence ...to ensure that access to the wiki used to create documentation is restricted to only those with filed CLAs - Raju - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Link to CLA page incorrect on Podling Website Guid page
On Tue, Jan 3, 2012 at 10:22 AM, Raju Bitter rajubit...@googlemail.com wrote: Don't know if this is the right mailing list, but reading http://incubator.apache.org/guides/sites.html the section Using A Wiki To Create Documentation contains an invalid link to http://incubator.apache.org/guides/clas in the sentence ...to ensure that access to the wiki used to create documentation is restricted to only those with filed CLAs.. Thanks for reporting, fixed in revision 1226722, will be online once the live website syncs. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Welcome Anne Kathrine Petterøe and Dave Fisher as Incubator PMC members
Hi, I'm pleased to announce that Anne and Dave have been elected by the Incubator PMC to be members of that PMC. With this the Flex mentors roster is complete, thanks for volunteering! -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Welcome Anne Kathrine Petterøe and Dave Fisher as Incubator PMC members
Excellent news, welcome and thanks for volunteering as mentors Anne and Dave! - Peter On Tue, Jan 3, 2012 at 11:07 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, I'm pleased to announce that Anne and Dave have been elected by the Incubator PMC to be members of that PMC. With this the Flex mentors roster is complete, thanks for volunteering! -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT][VOTE] DeviceMap to join the Apache incubator
On Thu, Dec 29, 2011 at 5:05 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...Let's cast your votes to accept DeviceMap as an incubating project, proposal is at http://wiki.apache.org/incubator/DeviceMapProposal ... The votes passes with binding +1s from the following people, several non-binding +1s and no other votes: Stefan Seelmann Ralph Goers Chris Mattmann Kevan Miller Davanum Srinivas Marcel Offermans Jean-Baptiste Onofré Andrus Adamchik Olivier Lamy Bertrand Delacretaz Thanks everybody for your votes! I will now request creation of the project's initial infrastructure, and let people know on this list once the devicemap-dev mailing list is ready. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Welcome Anne Kathrine Petterøe and Dave Fisher as Incubator PMC members
Hi, What a great way to start the day and the new year. Thanks everyone who voted! Looking forward to mentoring Apache Flex! /Anne On 3 January 2012 11:07, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, I'm pleased to announce that Anne and Dave have been elected by the Incubator PMC to be members of that PMC. With this the Flex mentors roster is complete, thanks for volunteering! -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][VOTE] DeviceMap to join the Apache incubator
Hi, First of all Happy New yeasr, and sorry for my scholastic english. I'm Idel Fuschini the owner of Apache Mobile Filter ( http://www.apachemobilefilter.org or https://modules.apache.org/search.php?id=1787). AMF started in 2008, is a module written in Perl using mod_perl and the features are: Device Detection Switcher Image Rendering for more info: http://wiki.apachemobilefilter.org In this moment my project integrates several device repository such as WURFL, 51degrees.mobi and DetectRight. In this moment I'm working to ingrate also OpenDDR where I was included as contributor, and I have planned to delivery at the end of january. So if you need a help to your project I will be happy to contribute. Idel = Mobile: +39 349 442 2668 E-Mail: idel.fusch...@gmail.com Web Site: http://www.idelfuschini.it AMF project: http://www.apachemobilefilter.org AMF wiki: Apache Mobile Filter - http:/wiki.apachemobilefilter.org -- La presente comunicazione ed i suoi allegati e' destinata esclusivamente ai destinatari. Qualsiasi suo utilizzo, comunicazione o diffusione non autorizzata e' proibita. Se ha ricevuto questa comunicazione per errore, la preghiamo di darne immediata comunicazione al mittente e di cancellare tutte le informazioni erroneamente acquisite. (Rif. D.Lgs. 196/2003). Grazie This message and its attachments are intended only for use by the addressees. Any use, re-transmission or dissemination not authorized of it is prohibited. If you received this e-mail in error, please inform the sender immediately and delete all the material. (Rif. D.Lgs. 196/2003). Thank you. On 3 January 2012 11:39, Bertrand Delacretaz bdelacre...@apache.org wrote: On Thu, Dec 29, 2011 at 5:05 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: ...Let's cast your votes to accept DeviceMap as an incubating project, proposal is at http://wiki.apache.org/incubator/DeviceMapProposal ... The votes passes with binding +1s from the following people, several non-binding +1s and no other votes: Stefan Seelmann Ralph Goers Chris Mattmann Kevan Miller Davanum Srinivas Marcel Offermans Jean-Baptiste Onofré Andrus Adamchik Olivier Lamy Bertrand Delacretaz Thanks everybody for your votes! I will now request creation of the project's initial infrastructure, and let people know on this list once the devicemap-dev mailing list is ready. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
On Tue, Jan 3, 2012 at 4:18 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 3, 2012 at 9:27 AM, Ralph Goers ralph.go...@dslextreme.com wrote: On Jan 3, 2012, at 12:02 AM, Greg Stein wrote: ...I'm saying that the *ASF* should avoid judging. We allow competition among projects. We accept projects with hard problems and low chances of success. We accept projects that some don't want us to. We should not judge. We should provide a home to communities that want to be here. I have no problem with competition among projects and everything else you say in the paragraph above. The only issue I have is that we can't take some other project's code and use it as the basis for a project here if the original project objects. It still isn't clear to me what the consensus is at Trac, but it certainly isn't overwhelmingly in favor... I agree that we don't want to support an unfriendly fork of Trac in Bloodhound, but as you say there doesn't seem to be an official consensus from the Trac project about this. It might help to note that the policy is that ASF requires that contributions be voluntary on the part of the people granting the license to the ASF. That's not necessarily the same thing as 'makes the current community happy' and it's not necessarily different -- depending on the IP status. it looks to me as if the relevant item is Copyright (C) 2003-2010 Edgewall Software . So, if 'Edgewall Software is voluntarily making a grant, then the letter of the policy is satisfied -- even if there are individuals in the development community who are less than thrilled. If, on the other hand, the proposal is to just take the code on the basis of its public license, with no expression of volition from the owner, then I'd agree with others who see this as contrary to the stated policy. Nonetheless, I'm curious as to hear from Roy and Sam. Roy was certainly the clearest articulator of this policy the last time I recall it coming around. IMO the best way of coming to closure on this issue is for the Trac community (as a whole) to state whether they agree with Bloodhound forking whatever they are planning to fork or not. Getting that agreement would, again IMO, be a condition for Bloodhound to graduate. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Rave 0.6-incubating
On 28 December 2011 19:15, Franklin, Matthew B. mfrank...@mitre.org wrote: This is the fifth incubator release for Apache Rave, with the artifacts being versioned as 0.6-incubating. We are requesting at least one additional IPMC member vote, as we have received 2 binding IPMC +1 votes during the release voting on rave-dev - VOTE: http://s.apache.org/Czr RESULT: http://s.apache.org/yIQ IPMC member votes from the rave-dev list: Ate Douma: +1 Ross Gardler: +1 Release notes: http://svn.apache.org/repos/asf/incubator/rave/tags/0.6-incubating/CHANGELOG which says: Release Notes - Rave - Version 0.5-INCUBATING So what was changed for 0.6? SVN source tag (r1208867): https://svn.apache.org/repos/asf/incubator/rave/tags/0.6-incubating/ Maven staging repos: https://repository.apache.org/content/repositories/orgapacherave-278/ https://repository.apache.org/content/repositories/orgapacherave-279/ Source release: https://repository.apache.org/content/repositories/orgapacherave-278/org/apache/rave/rave-project/0.6-incubating/rave-project-0.6-incubating-source-release.zip Binary releases http://people.apache.org/builds/incubator/rave/0.6-incubating/apache-rave-0.6-incubating-bin.tar.gz http://people.apache.org/builds/incubator/rave/0.6-incubating/apache-rave-0.6-incubating-bin.zip PGP release keys: https://svn.apache.org/repos/asf/incubator/rave/KEYS Vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][VOTE] DeviceMap to join the Apache incubator
Hi Idel, On Tue, Jan 3, 2012 at 12:06 PM, Idel Fuschini idel.fusch...@gmail.com wrote: ...if you need a help to your project I will be happy to contribute Thanks! The best is to wait for the devicemap-dev list to be created, and we can then discuss any plans there. I'll announce here once that list is available. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Flex mailing lists have been created
Hi Flex podling community, Please subscribe at least to the dev list for anything related to that podling, see below. This info will soon be available at http://incubator.apache.org/flex/ -Bertrand Flex mailing lists info: You can now join the Flex developer's mailing list by sending an email to flex-dev-subscribe (at) incubator.apache.org - this is where everything related to this project is being discussed. Once subscribed, send messages to flex-dev (at) incubator.apache.org. In addition to the dev list, active developers should subscribe to the -commits list, and PPMC members (according to the list in the Flex proposal at http://wiki.apache.org/incubator/FlexProposal) should also subscribe to the -private list, using either their Apache address or an address that's listed in https://svn.apache.org/repos/private/committers/MailAlias.txt . - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
On Mon, Jan 2, 2012 at 7:26 PM, Greg Stein gst...@gmail.com wrote: The Trac community revolves mostly around the plugins rather than the core. I see Bloodhound as improving the core facilities (new features and hauling in certain plugins), resulting in a better default distribution (right now, you need to add a dozen plugins to get a useful Trac install). There is no technical reason why building a better default distribution for Bloodhound requires an imported copy of the Trac code. A Pip requirements file[1] plus a templated trac.ini configuration file[2] along the lines of Paste Script templates[3] would achieve this. On Tue, Jan 3, 2012 at 3:02 AM, Greg Stein gst...@gmail.com wrote: (fwiw, some of the ideas are non-starters for Trac, so the *only* solution is do it outside the core project). None of the public discussion about Bloodhound's intended roadmap describes ideas that are non-starters for Trac. As far as I have seen, the only specific feature that's been mentioned publicly[4] is one that is on the Trac roadmap[5]. In any case, no specific reasons have been given why building new features outside the core project must happen through a code fork. Trac is highly pluggable and hundreds of plugins already exist[6]. In a technical sense, it is very likely that the bulk of Bloodhound could be built as a set of new Apache-licensed plugins plus an Apache-licensed installation script and Apache-licensed configuration template or wizard. Some of Bloodhound's plugins might require new extension points in the Trac core. And multi-project support might require a lot of changes to the Trac core. Separating out these distinct aspects of the Bloodhound roadmap (a distribution; new features; core patches necessary for those new features) seems useful. Assuming the licensing and copyright issues can be worked out or worked around, core patches could be submitted upstream and locally maintained in a Mercurial patch queue[7] or a Git fork with a very branchy workflow[8] which is used as the underlying dependency for Bloodhound trunk development, while the rest of the project proceeds in an Apache Subversion repository. These may seem like excessively technical details to get into at this stage of the discussion, but the nature of the community relationships and information flow between the two projects, as well as the actual parameters of the licensing and copyright questions, are significantly impacted by the technical choices that Bloodhound's developers make at the start. -Ethan [1] http://www.pip-installer.org/en/latest/requirements.html [2] http://trac.edgewall.org/wiki/TracIni [3] http://pythonpaste.org/script/developer.html#templates [4] http://groups.google.com/group/trac-dev/msg/9596d8067d0a4c35 [5] http://trac.edgewall.org/wiki/TracDev/Proposals/MultipleProject [6] http://trac-hacks.org/wiki/plugin [7] http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html [8] https://github.com/nvie/gitflow
Re: Welcome Anne Kathrine Petterøe and Dave Fisher as Incubator PMC members
Welcome Anne and Dave! Cheers, Chris On Jan 3, 2012, at 2:07 AM, Bertrand Delacretaz wrote: Hi, I'm pleased to announce that Anne and Dave have been elected by the Incubator PMC to be members of that PMC. With this the Flex mentors roster is complete, thanks for volunteering! -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[DISCUSS] Apache Bean Validation as a TLP
Hi... It has been discussed, since a while, about the graduation of Apache Bean Validation, whether to graduate to a TLP or Subproject and whether it is time or not, [1], [2] and [3]. In the past few weeks there has been a [VOTE], [4], which formally discussed the graduation to a TLP project. Result announcement can be found here, [5]. The resolution charter content has been discussed and reviewed here [6]. The Apache Bean Validation community sees it is time to request an IPMC [VOTE] on recommending this resolution [7] to the ASF board. Accordingly, would you please cast your vote: [ ] +1 to recommend Bean Validation's graduation [ ] 0 don't care [ ] -1 no, don't recommend yet, (because...) The vote will be open for 72 hours. [1] - http://s.apache.org/oTC [2] - http://s.apache.org/I8C [3] - http://s.apache.org/EQE [4] - http://s.apache.org/rU [5] - http://s.apache.org/7Sw [6] - http://s.apache.org/S5F [7] - see below: ## Resolution to create a TLP from graduating Incubator podling X. Establish the Apache Bean Validation Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Bean Validation Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Bean Validation Project be and hereby is responsible for the creation and maintenance of software related to creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions; and be it further RESOLVED, that the office of Vice President, Apache Bean Validation be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Bean Validation Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Bean Validation Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Bean Validation Project: * Albert Lee allee8...@apache.org * Carlos Vara Callau carlosv...@apache.org * David Jencks djen...@apache.org * Donald Woods dwo...@apache.org * Gerhard Petracek gpetra...@apache.org * Jeremy Bauer jrba...@apache.org * Kevan Lee Miller ke...@apache.org * Luciano Resende lrese...@apache.org * Matthias Wessendorf mat...@apache.org * Matthew Jason Benson mben...@apache.org * Mohammad Nour El-Din mn...@apache.org * Niall Pemberton nia...@apache.org * Roman Stumm romanst...@apache.org * Simone Tripodi simonetrip...@apache.org * Mark Struberg strub...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson be appointed to the office of Vice President, Apache Bean Validation, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Bean Validation PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Bean Validation Project; and be it further RESOLVED, that the Apache Bean Validation Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Bean Validation podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Bean Validation podling encumbered upon the Apache Incubator Project are hereafter discharged. Looking forward to your feedback and reply :) -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: [DISCUSS] Apache Bean Validation as a TLP
On Tue, Jan 3, 2012 at 4:17 PM, Mohammad Nour El-Din mn...@apache.org wrote: ... The Apache Bean Validation community sees it is time to request an IPMC [VOTE] on recommending this resolution [7] to the ASF board. Accordingly, would you please cast your vote: [X ] +1 to recommend Bean Validation's graduation -Bertrand (who was even able to read the geek code in the vote results, *, +, @, # ;-) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache Bean Validation as a TLP
+1 Matt On Tue, Jan 3, 2012 at 9:17 AM, Mohammad Nour El-Din mn...@apache.org wrote: Hi... It has been discussed, since a while, about the graduation of Apache Bean Validation, whether to graduate to a TLP or Subproject and whether it is time or not, [1], [2] and [3]. In the past few weeks there has been a [VOTE], [4], which formally discussed the graduation to a TLP project. Result announcement can be found here, [5]. The resolution charter content has been discussed and reviewed here [6]. The Apache Bean Validation community sees it is time to request an IPMC [VOTE] on recommending this resolution [7] to the ASF board. Accordingly, would you please cast your vote: [ ] +1 to recommend Bean Validation's graduation [ ] 0 don't care [ ] -1 no, don't recommend yet, (because...) The vote will be open for 72 hours. [1] - http://s.apache.org/oTC [2] - http://s.apache.org/I8C [3] - http://s.apache.org/EQE [4] - http://s.apache.org/rU [5] - http://s.apache.org/7Sw [6] - http://s.apache.org/S5F [7] - see below: ## Resolution to create a TLP from graduating Incubator podling X. Establish the Apache Bean Validation Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Bean Validation Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Bean Validation Project be and hereby is responsible for the creation and maintenance of software related to creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions; and be it further RESOLVED, that the office of Vice President, Apache Bean Validation be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Bean Validation Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Bean Validation Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Bean Validation Project: * Albert Lee allee8...@apache.org * Carlos Vara Callau carlosv...@apache.org * David Jencks djen...@apache.org * Donald Woods dwo...@apache.org * Gerhard Petracek gpetra...@apache.org * Jeremy Bauer jrba...@apache.org * Kevan Lee Miller ke...@apache.org * Luciano Resende lrese...@apache.org * Matthias Wessendorf mat...@apache.org * Matthew Jason Benson mben...@apache.org * Mohammad Nour El-Din mn...@apache.org * Niall Pemberton nia...@apache.org * Roman Stumm romanst...@apache.org * Simone Tripodi simonetrip...@apache.org * Mark Struberg strub...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson be appointed to the office of Vice President, Apache Bean Validation, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Bean Validation PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Bean Validation Project; and be it further RESOLVED, that the Apache Bean Validation Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Bean Validation podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Bean Validation podling encumbered upon the Apache Incubator Project are hereafter discharged. Looking forward to your feedback and reply :) -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Gora Incubator Graduation Resolution
Okey dok, I added it in r32707 now that Doug created the agenda. Thanks! Cheers, Chris On Dec 28, 2011, at 8:23 AM, Mattmann, Chris A (388J) wrote: Hey Board@, The Incubator PMC has VOTEd to recommend graduating Apache Gora. Here's the resolution: X. Establish the Apache Gora Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software for mapping objects to NoSQL databases for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Gora Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Gora Project be and hereby is responsible for the creation and maintenance of software related to open-source software for mapping objects to NoSQL databases; and be it further RESOLVED, that the office of Vice President, Apache Gora be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Gora Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Gora Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Gora Project: * Sertan Alkan sertan@... * Andrzej Bialecki ab@... * Ioannis Canellos iocanel@... * Dogacan Guney dogacan@... * Andrew Hart ahart@... * Chris Mattmann mattmann@... * Lewis John McGibbney lewismc@... * Julien Nioche jnioche@... * Henry Saputra hsaputra@... * Enis Soztutar enis@... * David Woollard woollard@... RESOLVED, that the Apache Gora Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Gora sub-project; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Gora sub-project encumbered upon the Apache Incubator Project are hereafter discharged. NOW, THEREFORE, BE IT FURTHER RESOLVED, that Lewis John McGibbney be appointed to the office of Vice President, Apache Gora, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed. Please add it to the January 2012 meeting agenda (or I'll do it myself if no one beats me to it after it's created). Thanks! Cheers Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
On 1/3/2012 2:02 AM, Greg Stein wrote: On Jan 3, 2012 2:30 AM, Ralph Goers ralph.go...@dslextreme.com wrote: On Jan 2, 2012, at 11:15 PM, Greg Stein wrote: On Jan 2, 2012 10:51 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Greg, I do not care one bit how much commit activity happens at Trac. As long as there is some kind of active community it is improper to fork it without their permission. Eh? You ever read the rules for revolutionaries page? The basic concept is: don't try to force two communities into one; when separate visions for the project occur, then separate them. I don't see it as our place to *judge* communities. If it is a fork, or a corporate spin-out, or a move, or brand new... All Good. We provide a temporary home in the Incubator to see if it can become a good, proper, and healthy Apache community. We don't turn them away a-priori based on their history. Greg, this seems to be so much B.S as it apparently serves some particular interest you have. I *do* have an interest in seeing Bloodhound be successful. I've always been very impressed with the approach the Trac people have taken. It is a great tool. It is a great project, but I think it can be better. Bugzilla is popuar, but crap. There is no other OSS issue tracker that is good and popular. Trac is te closest, and (IMO) best hope for filling this gap in the OSS toolset. A PMC I am on had this exact conversation with board members several months ago regarding a code base the project is dependent on that is housed outside the ASF which we were considering bringing in as a subproject. We were told that under no circumstances could we fork the code without the owner's blessing, regardless of what the license allowed us to do. To me, this answer is black and white. Not to me. :-) Which is the problem, isn't it? Note; hat switch, you are now speaking with the authority of a Director. In my mind, the Trac core has slowed, and it needs revitalization and a new vision. Others may disagree, and do, and that's fine. But I don't think it is fine for us to make judgements of communities (or nascent ones!) who want to try something new. To pick up and go in a direction that others are not heading, or do not have the time to make. I have no idea what you are saying. You ARE making a judgement on a community by saying it isn't active enough and deserves to be forked. Again, some of your fellow board members have said the ASF isn't the place for that. As a person wanting to see Apache Bloodhound take off... yeah, I'm making a judgement call on whether that can better occur at the ASF instead of within the current Trac community. (fwiw, some of the ideas are non-starters for Trac, so the *only* solution is do it outside the core project). I'm saying that the *ASF* should avoid judging. We allow competition among projects. We accept projects with hard problems and low chances of success. We accept projects that some don't want us to. We should not judge. We should provide a home to communities that want to be here. You realize, the paragraphs above are riddled with judgement calls? Mr. Director, are causing undue confusion here by putting on your Director hat to contradict the board. That isn't healthy public forum conduct. Either Ralph is grossly misinformed, or your are wildly out on a limb, or (most likely) the whole subject matter is a whole lot more nuanced than either of your posts are willing to concede. I'd challenge this we should not judge assertion. The incubator is charged by the directors with the acceptance and oversight of new products submitted or proposed to become part of the Foundation ... go back to 6. D. R2. http://www.apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt That involves a judgement. When you get your fellow directors to accept an amendment to state the acceptance and oversight of new products contributed to the Foundation as the responsibility - then I can buy your reasoning that we don't cast judgements (on any number of measures). ... Folks, can we please find a better forum for religious This is the ASF debates to occur? And keep discussions non-toxic here on general@incubator? Please remember that we point newcomers here to general@incubator and suggest they follow that list to get a better understanding of what the ASF is. These threads do not help to convey any clarity, and they only serve to confuse our prospective contributors and potential, future members. Particularly when argued between directors. Not suggesting that public debate is bad... but if these can occur elsewhere, and -conclusions- then posted here to general@, it would go a long ways to help newcomers orient to the philosophy and expectations of the ASF as a whole. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail:
Re: [VOTE] Bloodhound to join the Incubator
On Tue, Jan 3, 2012 at 5:48 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: ... Folks, can we please find a better forum for religious This is the ASF debates to occur? And keep discussions non-toxic here on general@incubator?... I don't perceive this thread as religious or toxic - I see a rather healthy debate on a difficult and important (for Bloodhound and Trac) question. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Welcome Anne Kathrine Petterøe and Dave Fisher as Incubator PMC members
On Jan 3, 2012, at 2:07 AM, Bertrand Delacretaz wrote: Hi, I'm pleased to announce that Anne and Dave have been elected by the Incubator PMC to be members of that PMC. Thanks! With this the Flex mentors roster is complete, thanks for volunteering! You're welcome! Regards, Dave -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache Bean Validation as a TLP
+1 imo we can easily just start calling the VOTE. BVAL and the resolution has been on spot several times. So I'd say we just move the last resolution text to our Wiki and do an internal review for fixing the last itches and scratches. Then we can formally call the VOTE and are done. LieGrue, strub - Original Message - From: Mohammad Nour El-Din mn...@apache.org To: general@incubator.apache.org Cc: bval-...@incubator.apache.org Sent: Tuesday, January 3, 2012 4:17 PM Subject: [DISCUSS] Apache Bean Validation as a TLP Hi... It has been discussed, since a while, about the graduation of Apache Bean Validation, whether to graduate to a TLP or Subproject and whether it is time or not, [1], [2] and [3]. In the past few weeks there has been a [VOTE], [4], which formally discussed the graduation to a TLP project. Result announcement can be found here, [5]. The resolution charter content has been discussed and reviewed here [6]. The Apache Bean Validation community sees it is time to request an IPMC [VOTE] on recommending this resolution [7] to the ASF board. Accordingly, would you please cast your vote: [ ] +1 to recommend Bean Validation's graduation [ ] 0 don't care [ ] -1 no, don't recommend yet, (because...) The vote will be open for 72 hours. [1] - http://s.apache.org/oTC [2] - http://s.apache.org/I8C [3] - http://s.apache.org/EQE [4] - http://s.apache.org/rU [5] - http://s.apache.org/7Sw [6] - http://s.apache.org/S5F [7] - see below: ## Resolution to create a TLP from graduating Incubator podling X. Establish the Apache Bean Validation Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Bean Validation Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Bean Validation Project be and hereby is responsible for the creation and maintenance of software related to creating an implementation compliant with JSR-303 and a library of pre-developed validators and extensions; and be it further RESOLVED, that the office of Vice President, Apache Bean Validation be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Bean Validation Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Bean Validation Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Bean Validation Project: * Albert Lee allee8...@apache.org * Carlos Vara Callau carlosv...@apache.org * David Jencks djen...@apache.org * Donald Woods dwo...@apache.org * Gerhard Petracek gpetra...@apache.org * Jeremy Bauer jrba...@apache.org * Kevan Lee Miller ke...@apache.org * Luciano Resende lrese...@apache.org * Matthias Wessendorf mat...@apache.org * Matthew Jason Benson mben...@apache.org * Mohammad Nour El-Din mn...@apache.org * Niall Pemberton nia...@apache.org * Roman Stumm romanst...@apache.org * Simone Tripodi simonetrip...@apache.org * Mark Struberg strub...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matthew Jason Benson be appointed to the office of Vice President, Apache Bean Validation, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Bean Validation PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Bean Validation Project; and be it further RESOLVED, that the Apache Bean Validation Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Bean Validation podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Bean Validation podling
Re: [VOTE] Bloodhound to join the Incubator
On Jan 3, 2012 11:48 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: ... A PMC I am on had this exact conversation with board members several months ago regarding a code base the project is dependent on that is housed outside the ASF which we were considering bringing in as a subproject. We were told that under no circumstances could we fork the code without the owner's blessing, regardless of what the license allowed us to do. To me, this answer is black and white. Not to me. :-) Which is the problem, isn't it? Note; hat switch, you are now speaking with the authority of a Director. Euh, nope. Offering my personal opinions. A Director hat would (and does) mean nothing since I could not speak for the Board. -g
RE: [VOTE] Release Apache Rave 0.6-incubating
-Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Tuesday, January 03, 2012 7:06 AM To: general@incubator.apache.org Subject: Re: [VOTE] Release Apache Rave 0.6-incubating On 28 December 2011 19:15, Franklin, Matthew B. mfrank...@mitre.org wrote: This is the fifth incubator release for Apache Rave, with the artifacts being versioned as 0.6-incubating. We are requesting at least one additional IPMC member vote, as we have received 2 binding IPMC +1 votes during the release voting on rave-dev - VOTE: http://s.apache.org/Czr RESULT: http://s.apache.org/yIQ IPMC member votes from the rave-dev list: Ate Douma: +1 Ross Gardler: +1 Release notes: http://svn.apache.org/repos/asf/incubator/rave/tags/0.6- incubating/CHANGELOG Apparently, I didn't commit back the CHANGELOG for 0.6 . Here is the issue list from JIRA https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311290version=12317563 which says: Release Notes - Rave - Version 0.5-INCUBATING So what was changed for 0.6? SVN source tag (r1208867): https://svn.apache.org/repos/asf/incubator/rave/tags/0.6-incubating/ Maven staging repos: https://repository.apache.org/content/repositories/orgapacherave-278/ https://repository.apache.org/content/repositories/orgapacherave-279/ Source release: https://repository.apache.org/content/repositories/orgapacherave- 278/org/apache/rave/rave-project/0.6-incubating/rave-project-0.6- incubating-source-release.zip Binary releases http://people.apache.org/builds/incubator/rave/0.6-incubating/apache- rave-0.6-incubating-bin.tar.gz http://people.apache.org/builds/incubator/rave/0.6-incubating/apache- rave-0.6-incubating-bin.zip PGP release keys: https://svn.apache.org/repos/asf/incubator/rave/KEYS Vote open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
On 1/3/2012 10:55 AM, Bertrand Delacretaz wrote: On Tue, Jan 3, 2012 at 5:48 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: ... Folks, can we please find a better forum for religious This is the ASF debates to occur? And keep discussions non-toxic here on general@incubator?... I don't perceive this thread as religious or toxic - I see a rather healthy debate on a difficult and important (for Bloodhound and Trac) question. That much... is good ++1! Is Trac a willing donor/partner/component-to-be- consumed? What is the effect of two dev communities? All healthy good questions to raise. As easily as it creates rifts, it can also heal some. The ASF will support a fork absolutely yes/maybe/never - that is where I'd perceived the whole thread sliding off the rails. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Q. Forks without concensus?; A. anytime / depends / never without agreement
On 1/3/2012 11:14 AM, Greg Stein wrote: On Jan 3, 2012 11:48 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: ... A PMC I am on had this exact conversation with board members several months ago regarding a code base the project is dependent on that is housed outside the ASF which we were considering bringing in as a subproject. We were told that under no circumstances could we fork the code without the owner's blessing, regardless of what the license allowed us to do. To me, this answer is black and white. Not to me. :-) Which is the problem, isn't it? Note; hat switch, you are now speaking with the authority of a Director. Euh, nope. Offering my personal opinions. A Director hat would (and does) mean nothing since I could not speak for the Board. So this is a question that should be put to bed once and for all, you have both been swinging pretty wildly at diametrically opposed answers to this question. If we read that the Board has charged this committee with acceptance criteria for submitted or proposed products... then the question above should be resolved. Essentially, we have several choices... [ ] Forks are accepted without judgement [Greg] [1] [ ] [something more nuanced here] [ ] Hostile forks are never acceptable [Roy] [2] If the answer lies somewhere in the middle, it would help potential contributors/forkers to know approximately where that middle sits. [1] I don't see it as our place to *judge* communities. If it is a fork, or a corporate spin-out, or a move, or brand new... All Good. [2] At Apache, all contributions are voluntary. We do not accept code from copyright owners who don't want us to have it, even if we have the legal right to adopt it for other reasons. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
[ ] Forks are accepted without judgement [Greg] [1] [ ] [something more nuanced here] [X ] Hostile forks are never acceptable [Roy] [2] I don't understand the purpose of a vote here. Roy has stated rather firmly that [2] is settled foundation policy. So, if someone wants to reopen that question, don't we need to go to the board for a vote? It's not an incubator issue, it's a contribution issue. Someone is proposing to check into svn code that fails the 'voluntary' test. Would some please clarify is this is *truly* a hostile fork? Is the copyright holder willing to grant, or not? That is, I claimed, a different question from 'there is a lack of consensus in the development community for a fork at Apache.' - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On 1/3/2012 11:43 AM, Benson Margulies wrote: I don't understand the purpose of a vote here. Roy has stated rather firmly that [2] is settled foundation policy. Pointer to where that policy was established, or it didn't happen. It might have been a consensus relative to some specific incident or issue that arose, but only resolutions carry weight, as Greg rightly points out. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On 1/3/2012 11:43 AM, Benson Margulies wrote: Would some please clarify is this is *truly* a hostile fork? Wrong thread, see Subject: above. Thx. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Forks without concensus?
Hey hey, (Pff. I like replying in-line but this is a hard e-mail to reply to in-line so I will top post.) If I understand your policy question: will apache allow an incubating community to show up and start a project when they are forking another project? I'd say, in general, yes, probably, if all the other criteria we have are satisfied. But, well, what if that other project is open source already, and some people don't want the fork to exist at apache? Well, then probably something is wrong in the first place, and it needs to be investigated. Why, otherwise would a group of people show up that want to fork at all? I think it quickly becomes a judgement call. On the one hand, should apache try and avoid getting tangled up into a complex mess just because it is complex and messy? No, I don't think so. If anything, apache is supposed to be good at helping people sort out their complex messes. If we have mentors willing and able to help, let's try and help. On the other hand, should apache make sure that it's considerable weight is not mistakenly thrown behind an initiative that somehow goes against our core values (an open, collaborative, consensus-based process)? Absolutely. Etc. So the generic policy is there is no generic policy, and instead there is appropriate application of judgement to specific cases. cheerio, Leo On Tue, Jan 3, 2012 at 6:35 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/3/2012 11:14 AM, Greg Stein wrote: On Jan 3, 2012 11:48 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: ... A PMC I am on had this exact conversation with board members several months ago regarding a code base the project is dependent on that is housed outside the ASF which we were considering bringing in as a subproject. We were told that under no circumstances could we fork the code without the owner's blessing, regardless of what the license allowed us to do. To me, this answer is black and white. Not to me. :-) Which is the problem, isn't it? Note; hat switch, you are now speaking with the authority of a Director. Euh, nope. Offering my personal opinions. A Director hat would (and does) mean nothing since I could not speak for the Board. So this is a question that should be put to bed once and for all, you have both been swinging pretty wildly at diametrically opposed answers to this question. If we read that the Board has charged this committee with acceptance criteria for submitted or proposed products... then the question above should be resolved. Essentially, we have several choices... [ ] Forks are accepted without judgement [Greg] [1] [ ] [something more nuanced here] [ ] Hostile forks are never acceptable [Roy] [2] If the answer lies somewhere in the middle, it would help potential contributors/forkers to know approximately where that middle sits. [1] I don't see it as our place to *judge* communities. If it is a fork, or a corporate spin-out, or a move, or brand new... All Good. [2] At Apache, all contributions are voluntary. We do not accept code from copyright owners who don't want us to have it, even if we have the legal right to adopt it for other reasons. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
It occurs to me that the ASF, in enforcing open-source licensing, becomes a source of free legal advice to the open-source community, whether it intends to or not... 1. Contribute a body of code to ASF. 2. Is it legal for us to accept this? Better run it past legal@. 3. Use acceptance of the contribution as certification that it can be used by the contributor. Just sayin'. Not sure if this is a good thing or a bad thing. Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
Any time a body of code is contributed from another source, it should go through the standard Apache procedures, including a license grant (if it's not open-source already). But this is very different from spinning off chunks of an existing incubator project. For example, ManifoldCF is currently attempting to spin off three subprojects. Each of the subprojects is more tightly related in some way to other projects than it is to ManifoldCF itself, and in an ideal world these other projects would incorporate the subproject code themselves. Unfortunately, in two of the cases (plugins for two versions of Lucene/Solr) the project has refused to include the code, and in another case (a SharePoint plugin) the main project is not open-sourced in the first place. I would hope that there would be enough flexibility in the incubator model to permit this kind of thing. Just my two cents, nonbinding... Karl On Tue, Jan 3, 2012 at 1:16 PM, Donald Whytock dwhyt...@gmail.com wrote: It occurs to me that the ASF, in enforcing open-source licensing, becomes a source of free legal advice to the open-source community, whether it intends to or not... 1. Contribute a body of code to ASF. 2. Is it legal for us to accept this? Better run it past legal@. 3. Use acceptance of the contribution as certification that it can be used by the contributor. Just sayin'. Not sure if this is a good thing or a bad thing. Don - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 3, 2012 1:28 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: On Tue, Jan 3, 2012 at 9:57 AM, Leo Simons m...@leosimons.com wrote: So the generic policy is there is no generic policy, and instead there is appropriate application of judgement to specific cases. Generic policy doesn't mean you couldn't use judgement or make exceptions. In principle, if the ASF's mission is to build communities around source code, we should not accept forks of open source projects if that's not the (consensus) will of the original community. And what happens when the arriving community has a different vision than the original community? Do you tell them to go pound sand? Tell them the two communities are not allowed to diverge or separate? Cheers, -g
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Tue, Jan 3, 2012 at 1:28 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: On Tue, Jan 3, 2012 at 9:57 AM, Leo Simons m...@leosimons.com wrote: So the generic policy is there is no generic policy, and instead there is appropriate application of judgement to specific cases. Generic policy doesn't mean you couldn't use judgement or make exceptions. In principle, if the ASF's mission is to build communities around source code, we should not accept forks of open source projects if that's not the (consensus) will of the original community. I agree with the first statement in the above paragraph, and believe that it potentially leads to a different conclusion than the final sentence in that same paragraph. We have had unfriendly forks within the ASF. We have had instances where the original community has disappeared later to return and attempt to reclaim ultimate direction for a project. We've even had destructive forks where both the fork and the original community ended up failing. We can, and should, make a decision based on the specifics of the community in question, and informed by our past experiences -- both successes and failures. Kalle - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Hey folks, I felt I had to take a look at this. Like Ralph I was very concerned when I saw Ethan's e-mail. Thanks a lot for writing it Ethan, and thanks for writing it with so much detail. I just read all the e-mail about bloodhound I could find (that I had pretty much ignored when I saw other people I trust were looking at it) and then I read the last year of trac e-mail traffic (fwiw, the relevant/interesting e-mail concerning the bloodhound proposal is all in the last 2 months, older relevant e-mail is not on publicly archived lists). I have to say I'm a lot less concerned now. First impression: the trac community is full of really nice people and it's mailing lists are full of gentle and carefully considered communication. Very nice to see :-). I wish all open source communities were like that! I really recommend anyone else trying to form an opinion goes and looks at trac-dev. In particular you may want to read the overview one of the core devs from trac wrote for our benefit: https://groups.google.com/d/msg/trac-dev/kMVFq9pkfus/eYMCVfqyUwkJ The bloodhound proposal and communication around it probably could've been handled better over the last 9 months or so, but it also could've been handled much worse. It's a typical example of the difficulty that exists where a company wants to engage an open source community and there isn't a strong legal/commercial story yet. All the parties seem to be trying hard to come up with the best approach for everyone, and the apache approach seems like it should be able to help produce a healthy kind of collaboration. The bloodhound proposers look like they're doing pretty well now in communicating intent and approach clearly on the trac mailing list, and the trac folks in turn seem pretty clear on what is and isn't going on. Bloodhound at apache will probably be better for all, than bloodhound not at apache. If things continue on their current path, apache rules and processes should help minimize negative impact on trac so that the effect on trac will be a definitive net positive. I remember a bit about trac internals from years ago and ISTR it's pretty cleanly split into lots of little bits...so I imagine bloodhound can (and should) take a careful licensing path contributing patches to core upstream as BSD while making new/rewritten plugins available upstream as ALv2. That seems to be the intent, too. Proof will be in the pudding :-D I do think it would be nice and appropriate if someone updates the proposal page along the lines that Ethan mentioned, probably by simply removing the somewhat unfair depictions of the trac community. (perhaps edit the current page, but keep a link there to the version that was voted on, for clarity). All in all I think bloodhound should continue on, and the incubator PMC should trust the mentors to keep things on their current track (hehe) of collaboration-where-possible, rather than turn this into an overheated debate. cheers, Leo On Fri, Dec 30, 2011 at 9:30 PM, Ethan Jucovy ethan.juc...@gmail.com wrote: -1 The Bloodhound proposal is to build an issue tracker by first importing the Trac core code into the Apache Subversion repository. As currently planned, this project has potential to be detrimental to the existing Trac brand and community, and it seems that the Bloodhound project's goals could equally be achieved without taking the heavy-handed first step of forking the Trac codebase. I hope that the Bloodhound team will consider building Bloodhound as a set of plugins and configurations and an installer that distributes them with an upstream Trac version, rather than forking Trac as a first resort. My concerns fall into three categories: a) The Bloodhound proposal contains substantial allegations about the health of the Trac community and the competence of its maintainers, as motivating factors for the fork and rebuild community approach proposed. No documented evidence has been provided to support these claims, and many of the claims are directly contradicted by the publicly available records in the Trac community's issue tracker, mailing list archives and commit logs. b) Neither the Bloodhound proposal nor the ensuing discussions have demonstrated any compelling legal, procedural, technical or strategic reason why Bloodhound should be based on a fork of Trac rather than an upstream distribution of Trac. c) Although the people involved have been friendly and expressed a desire to keep the two projects in cooperation, the actions taken so far and the intentions announced are characteristic of a hostile fork. -- (a) The Bloodhound proposal contains substantial allegations, without evidence, about the health of the Trac community and the competence of its maintainers. These allegations are largely contradicted by publicly available records of the Trac community. * The Bloodhound proposal claims, Private efforts to engage the existing developers in implementing features have
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On 01/03/2012 07:35 AM, William A. Rowe Jr. wrote: [1] I don't see it as our place to *judge* communities. If it is a fork, or a corporate spin-out, or a move, or brand new... All Good. [2] At Apache, all contributions are voluntary. We do not accept code from copyright owners who don't want us to have it, even if we have the legal right to adopt it for other reasons. These aren't necessarily contradictory. At least part of what Roy's saying is that if someone doesn't intend to distribute their software under the Apache license then we should not take it. But I think if someone's clearly established their intent to publish a body of software under the Apache license and a new community forms around that software that's distinct from its original authors, then we can consider housing that community. Doug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
On Tue, Jan 3, 2012 at 8:09 PM, Leo Simons m...@leosimons.com wrote: ... All in all I think bloodhound should continue on, and the incubator PMC should trust the mentors to keep things on their current track (hehe) of collaboration-where-possible, rather than turn this into an overheated debate... +1, I think this fork or not issue can be solved during incubation. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Tue, Jan 3, 2012 at 11:46 AM, Doug Cutting cutt...@apache.org wrote: On 01/03/2012 07:35 AM, William A. Rowe Jr. wrote: [1] I don't see it as our place to *judge* communities. If it is a fork, or a corporate spin-out, or a move, or brand new... All Good. [2] At Apache, all contributions are voluntary. We do not accept code from copyright owners who don't want us to have it, even if we have the legal right to adopt it for other reasons. These aren't necessarily contradictory. At least part of what Roy's saying is that if someone doesn't intend to distribute their software under the Apache license then we should not take it. But I think if someone's clearly established their intent to publish a body of software under the Apache license and a new community forms around that software that's distinct from its original authors, then we can consider housing that community. In the case Roy made the comment I quoted on, the code had been distributed under the Apache License. The license was being changed to Eclipse. We asked whether the Apache Licensed version could be brought into the ASF. The answer was effectively, not without the owner's permission. I don't have a problem with that answer. I also don't have a problem with your answer above. I do have a problem giving a different answer based on who the involved parties are. Ralph
Re: [VOTE] Bloodhound to join the Incubator
On Tue, Jan 3, 2012 at 11:53 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Tue, Jan 3, 2012 at 8:09 PM, Leo Simons m...@leosimons.com wrote: ... All in all I think bloodhound should continue on, and the incubator PMC should trust the mentors to keep things on their current track (hehe) of collaboration-where-possible, rather than turn this into an overheated debate... +1, I think this fork or not issue can be solved during incubation. I too think this is the best approach in this case. I would just like to see the mentors make sure that communication with the Trac community takes place. Ralph
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Tue, Jan 3, 2012 at 15:13, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: On Tue, Jan 3, 2012 at 11:46 AM, Doug Cutting cutt...@apache.org wrote: On 01/03/2012 07:35 AM, William A. Rowe Jr. wrote: [1] I don't see it as our place to *judge* communities. If it is a fork, or a corporate spin-out, or a move, or brand new... All Good. [2] At Apache, all contributions are voluntary. We do not accept code from copyright owners who don't want us to have it, even if we have the legal right to adopt it for other reasons. These aren't necessarily contradictory. At least part of what Roy's saying is that if someone doesn't intend to distribute their software under the Apache license then we should not take it. But I think if someone's clearly established their intent to publish a body of software under the Apache license and a new community forms around that software that's distinct from its original authors, then we can consider housing that community. In the case Roy made the comment I quoted on, the code had been distributed under the Apache License. The license was being changed to Eclipse. We asked whether the Apache Licensed version could be brought into the ASF. The answer was effectively, not without the owner's permission. I don't have a problem with that answer. I also don't have a problem with your answer above. I do have a problem giving a different answer based on who the involved parties are. I doubt that it depends on where/what the software is coming from. You're just getting different answers from different people :-P (for the record: I'd have no problem if an Apache community grabbed a copy of software before it changed its license; of course, also assuming the community was willing to take on the development, maintenance, etc of that software) Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Tue, Jan 3, 2012 at 10:33 AM, Greg Stein gst...@gmail.com wrote: On Jan 3, 2012 1:28 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: On Tue, Jan 3, 2012 at 9:57 AM, Leo Simons m...@leosimons.com wrote: So the generic policy is there is no generic policy, and instead there is appropriate application of judgement to specific cases. Generic policy doesn't mean you couldn't use judgement or make exceptions. In principle, if the ASF's mission is to build communities around source code, we should not accept forks of open source projects if that's not the (consensus) will of the original community. And what happens when the arriving community has a different vision than the original community? Do you tell them to go pound sand? Tell them the two communities are not allowed to diverge or separate? You tell the arriving community that you need to work with the original community and that forking an existing open source project with an existing community is your last option, not your first one. I think it's just plain common sense that you have to be respectful of others, just like in the real world. Specifically regarding Bloodhound, much of the issues would likely have been avoided if the proposal hadn't dismissed the original community and hadn't stated as its primary intention to fork the existing Trac project (see quotes below). If the stated goal had been to provide a packager and installers and work closely with the existing community, I bet the tone of all stakeholders would have been very different. Kalle --- From the proposal: By it's own recognition, however, the development community surrounding Trac has largely dissipated. As discussed earlier, the current Trac development community is small and reluctant to accept outside contributions. Given the Foundation’s reputation for building and maintaining communities, we feel a new project, based on Trac but incubated under the Apache umbrella, would help re-build the developer community, jump started by developer time donated by WANdisco. The initial goals for Bloodhound primarily revolve around migrating the existing code base and integrating external features to make the project easy to deploy. Some of the initial goals include: * Migrate the existing BSD-licensed Trac code base to the ASF. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On 1/3/2012 12:51 PM, Sam Ruby wrote: On Tue, Jan 3, 2012 at 1:28 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: On Tue, Jan 3, 2012 at 9:57 AM, Leo Simons m...@leosimons.com wrote: So the generic policy is there is no generic policy, and instead there is appropriate application of judgement to specific cases. Generic policy doesn't mean you couldn't use judgement or make exceptions. In principle, if the ASF's mission is to build communities around source code, we should not accept forks of open source projects if that's not the (consensus) will of the original community. I agree with the first statement in the above paragraph, and believe that it potentially leads to a different conclusion than the final sentence in that same paragraph. +1. I would suggest we would avoid encouraging forks of open source projects if that isn't the last remaining alternative to allow both groups of contributors to move forward. A fork is a social artifact more than a code assembly artifact. We have had unfriendly forks within the ASF. We have had instances where the original community has disappeared later to return and attempt to reclaim ultimate direction for a project. We've even had destructive forks where both the fork and the original community ended up failing. Good points. We can, and should, make a decision based on the specifics of the community in question, and informed by our past experiences -- both successes and failures. Or to quote the cited logic behind we accept voluntary contributions only, let's look at a genesis of that statement circa 1999; * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Group and was originally based * on public domain software written at the National Center for * Supercomputing Applications, University of Illinois, Urbana-Champaign. Which devolves to; 1. many individuals made voluntary contributions *on behalf of Apache* 2. this does not deny some contributions made externally (not on behalf of Apache) were not also incorporated (I'd speculate that some were likely adopted, say patches in BSD or similar) 3. this work is originally written somewhere else and not a voluntary contribution on behalf of the Apache Group whatsoever, but published as-is into the commons. The genesis of Apache is a fork. Not a hostile fork, but a fork of an effectively abandoned work. It's possible to read the statement above that all contributions are directly offered to Apache, but that really isn't what it said. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
