[VOTE] Accept OpenOffice.org for incubation
+1 (not binding) Trying to establish a layer of common infrastructure for Open Document Format processors looks a worthy attempt, even with all the warnings and caveats. I was Incubator PMC member till recently, and I could have re-joined to vote. It looks like cheating, though. Regards Santiago
Re: Reminder: NO WIKI MARKUP
I wonder if there would be a simple script or set of regexes that would flag likely markup or a similar automated check... I don't see an easy way, but then there are good scripters around here. Regards Santiago On Mon, Dec 13, 2010 at 9:36 PM, Noel J. Bergman n...@devtech.com wrote: Since a number of projects got back into the bad habit of using Wiki markup, let me remind you that there is to be no Wiki markup in the project reports. There is no benefit to it; since the Board requires me to remove all Wiki markup before submitting the monthly report, all that wiki markup does is make the report take a bit longer to prepare. --- Noel - 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
Please add me back to the incubator PMC
Following the standard procedure for members I ask to be added again to the Incubator PMC. As I'm mentoring the Wave proposal I will be around again for some time. Regards Santiago - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Accept Wave for incubation
On Mon, Nov 29, 2010 at 8:49 AM, Dan Peterson dpeter...@google.com wrote: (...) To keep things moving, I'd like to go ahead and put this proposal to a vote starting on Tuesday on the west coast of the US (roughly 24 hours from now). I want to get some information about an issue that, like the name/branding one, is not a blocker for incubator entry, but can change significantly the level of third party support. It is the governance model for the protocol suit. If I understood correctly, the project is scoped towards the software server component. It does not include development of the protocol libraries. Does it include test suites beyond the server being a big test harness itself? It would be great to be able to know the plans for those: - protocol specification and maintenance - reference libraries for the protocol - test suites and specifically test kits if any is planned I think that clarifying those scopes would be great. Regards Santiago Regards, -Dan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Accept Wave for incubation
On Mon, Nov 29, 2010 at 4:43 PM, Ian Roughley rough...@gmail.com wrote: I'd like to add to what Soren said: we've discussed whether we should include the protocol and the implementation of the protocol in the proposal. What we concluded, is that having everything together would be the simplest for the time being... although I don't think anyone in the discussion had *really* strong opinions in either direction. From my standpoint (as a Novell employee and part of the Novell Vibe project), I'm very interested in ensuring that the protocol and libraries are licensed in a way that they can be leveraged by commercial software to allow for interoperability. I'd also go as far as saying that it's in everyones best interest for this to be the case :-) A big +1. I think that a very detailed roadmap would be more suspicious at this stage than having this open mind. There are two long term issues around: who owns central names, such as Wave, and who controls long term protocol evolution. I just thought that this fact should be brought up before the vote. IMO the situation is allright for accepting the incubation. The issues will be sorted out at due time. Regards Santiago /Ian On 11/29/2010 07:15 AM, Soren Lassen wrote: On Mon, Nov 29, 2010 at 8:32 PM, Santiago Gala santiago.g...@gmail.com wrote: On Mon, Nov 29, 2010 at 8:49 AM, Dan Peterson dpeter...@google.com wrote: (...) To keep things moving, I'd like to go ahead and put this proposal to a vote starting on Tuesday on the west coast of the US (roughly 24 hours from now). I want to get some information about an issue that, like the name/branding one, is not a blocker for incubator entry, but can change significantly the level of third party support. It is the governance model for the protocol suit. If I understood correctly, the project is scoped towards the software server component. It does not include development of the protocol libraries. The project will include all the source code for the wave in a box server, including all the (library?) code for the data model, the federation protocol implementation, the client-server protocol implementation, and the robot and data APIs, as well as all the documentation/specifications for the data model, protocols, and APIs hosted at waveprotocol.org. Does it include test suites beyond the server being a big test harness itself? There are no test suites other than unittests for the abovementioned implementations. It would be great to be able to know the plans for those: - protocol specification and maintenance - reference libraries for the protocol - test suites and specifically test kits if any is planned I think that clarifying those scopes would be great. Presently, we regard the protocol specification as a specification of the wave-in-a-box implementation and, thus, the specification belongs together with the implementation in the proposed Apache project. Eventually, we would like to formally standardize the protocol, i.e., agree with external parties outside the project to use the protocol between different implementations. When we get to the point when we start negotiating such agreements, we envision that we will spin out the protocol from the proposed Apache project into a standardisation working group (probably under the wings of IETF or some other standards body) which will govern these negotiations. The working group will need to decide on things like reference libraries and test suites. We're not deciding now whether the code in the proposed Apache project will be used for these purposes. Soren Regards Santiago Regards, -Dan - 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Interest in Android-based projects?
If there is no existing codebase, I would recommend to start as a lab. Once a prototype would be around, going to incubator or looking for TLP status would not be so challenging... Do you have a specific focus area or code base? Regards Santiago On Mon, Feb 15, 2010 at 10:04 PM, Luciano Resende luckbr1...@gmail.com wrote: On Mon, Feb 15, 2010 at 12:56 PM, Noel J. Bergman n...@devtech.com wrote: Would there be interest in a project to develop Android-based apps? know that it sounds like an umbrella, and perhaps it would be until we developed some critical mass, but it would provide us with a place to collaborate. --- Noel Sounds interesting... do you have any more details ? Would this be just a place like a Android App Labs where people can come and suggest/start working on new apps ? or would this be something more specific with a smaller scope ? -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.com/ - 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: Switching incubator.apache.org to svnpubsub?
2010/2/5 Justin Erenkrantz jus...@erenkrantz.com: (Perhaps we should move this conversation to infra-dev?) -- justin Or maybe site-dev, not really sure Regards Santiago - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Copyright issue (ESME-47)
Robert and Gianugo, did you mean to veto this with your -1s, or just express your disagreement with the majority? I might be thick or gmail buggy, but where is Gianugo's -1 ? I can't find it... Regards Santiago - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Copyright issue (ESME-47)
Definitely a case of buggy gmail/our list software, it is not here... I'm loosing more and more emails messages without any warning, and I'd like to know if it is trouble in our infrastructure or in gmail. Anybody knows? Regards Santiago 2010/1/20 Richard Hirsch hirsch.d...@gmail.com: Check his email from Tue, Jan 19, 2010 at 5:06 PM On Wed, Jan 20, 2010 at 1:02 PM, Santiago Gala santiago.g...@gmail.com wrote: Robert and Gianugo, did you mean to veto this with your -1s, or just express your disagreement with the majority? I might be thick or gmail buggy, but where is Gianugo's -1 ? I can't find it... Regards Santiago - 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] Copyright issue (ESME-47)
Let me be clear too, I'm not trying to mess with the vote in any way, just wondering if my email account was going nuts, as I've seen a couple of gmail hiccups in the last days and was over-sensitive... :) 2010/1/20 Gianugo Rabellino gian...@gmail.com: On Wed, Jan 20, 2010 at 1:48 PM, Gianugo Rabellino gian...@gmail.com wrote: On Wed, Jan 20, 2010 at 1:02 PM, Santiago Gala santiago.g...@gmail.com wrote: Robert and Gianugo, did you mean to veto this with your -1s, or just express your disagreement with the majority? I might be thick or gmail buggy, but where is Gianugo's -1 ? I can't find it... I just replied to the wrong email which wasn't cc'd here, apologies. So let me restate here: it's a non-binding, non-vetoeing -1 based on [...] I should add: this is not an attempt to rehash a discussion that has been going on forever, merely a due justification for a -1 as my arguments have been expressed on esme-dev and not here. -- Gianugo - 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] Graduate Apache Shindig as an Apache Top Level Project
+1, with the proviso that my name was accidentally dropped from the PRC member list in the proposed resolution, as I have already noted in the relevant thread before this vote started. I asked to stay in the relevan thread in private@ on December 19th Regards Santiago 2010/1/14 Upayavira u...@odoko.co.uk: +1 Upayavira On Thu, 2010-01-14 at 06:41 -0500, Vincent Siveton wrote: Hi, Thanks for the positive feedback on the proposal to graduate Shindig as a TLP [1]. I would like to start an official vote to recommend the graduation of Apache Shindig as a Top Level Project to the Board. To that end I have prepared the resolution for the Board below to be presented for consideration at the upcoming Board meeting. Community graduation vote thread: http://shindig-dev.markmail.org/message/c47amdxjtntkjij5 Please cast your vote: [ ] +1 to recommend Shindig's graduation [ ] 0 don't care [ ] -1 no, don't recommend yet, because ... The vote will be open for 72 hours. Cheers, Vincent [1] http://apache.markmail.org/message/qvpyymihv6gyh5a7 --- Begin Proposed Board Resolution --- 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 the implementation of an OpenSocial container and OpenSocial API specifications, 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 Shindig PMC, is hereby established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Shindig Project be and hereby is responsible for the creation and maintenance of software related to the OpenSocial API specifications, based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Shindig be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of Apache Shindig, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Shindig PMC; 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 Shindig PMC: * Ian Boston (ieb at apache dot org) * Kevin Brown (etnu at apache dot org) * Chris Chabot(chabotc at apache dot org) * Chico Charlesworth (chico at apache dot org) * Cassie Doll (doll at apache dot org) * Evan Gilbert (evan at apache dot org) * John Hjelmstad (johnh at apache dot org) * Paul Lindner (lindner at apache dot org) * Daniel Peterson (dpeterson at apache dot org) * Louis Ryan (lryan at apache dot org) * Henning Schmiedehausen (henning at apache dot org) * Vincent Siveton (vsiveton at apache dot org) * Upayavira (upayavira at apache dot org) * Adam Winer (awiner at apache dot org) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Paul Lindner be appointed to the office of Vice President, Apache Shindig, 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 Apache Shindig be and hereby is tasked with the migration and rationalization of the Apache Incubator Shindig podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Shindig podling encumbered upon the Apache Incubator PMC are hereafter discharged. --- End Proposed Board Resolution --- - 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: [PROPOSAL][VOTE] Wookie - a W3C widget engine with Google Wave extension
El mar, 14-07-2009 a las 11:15 +0100, Ross Gardler escribió: I would like to formally present the incubator proposal for Apache Wookie, a W3C widget engine with Google Wave extension +1 (IPMC binding) Santiago The full proposal can be found at http://wiki.apache.org/incubator/WookieProposal Vote will close in a little over 72 hours at mid day (BST, UTC + 1) Friday 17th July. http://www.timeanddate.com/worldclock/fixedtime.html?month=7day=17year=2009hour=12min=0sec=0p1=136 Ross - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Wookie - a W3C widget engine with Google Wave extension
El mar, 14-07-2009 a las 12:34 +0200, Ate Douma escribió: +1 BTW: not sure if my vote is binding as I received no formal feedback yet concerning my IPMC membership (but saw it being ACK by board). If the vote was emitted less than 72 hours after the ACK, just repeat it after 72 hours from the ACK to have it formally binding. i.e. you are Incubator PMC member in effect 72 hours after the ACK. Regards Santiago Ate Ross Gardler wrote: I would like to formally present the incubator proposal for Apache Wookie, a W3C widget engine with Google Wave extension The full proposal can be found at http://wiki.apache.org/incubator/WookieProposal Vote will close in a little over 72 hours at mid day (BST, UTC + 1) Friday 17th July. http://www.timeanddate.com/worldclock/fixedtime.html?month=7day=17year=2009hour=12min=0sec=0p1=136 Ross - 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] Approve the release of Shindig Incubator 1.0
El sáb, 23-05-2009 a las 21:02 +0200, Leo Simons escribió: On May 21, 2009, at 1:03 PM, Upayavira wrote: I am a mentor for Shindig, but I am aware of a weaknesses of mine as a mentor is that I'm not that knowledgeable or experienced with the release process at Apache, and therefore have not followed this thread in detail, which I really should have. It seems that this release is stalled, but I am not entirely sure how, and want to understand this better. Sebb has raised some valid concerns; some were addressed, some are left; shindig has to address those concerns, but up new artifacts, and then ask for another vote. The thing that confuses me is that, as I understand it, Shindig is just using Maven to produce its artefacts (binary jars as a convenience to users). If that is the case, surely those artefacts are structured in the same way as other Maven based releases from other projects? The apache-hosted maven-based projects I've checked (including maven itself!) only officially release source archives. As Jason pointed out, this is now pretty easy to do in accordance with policy, thanks to some plugin work David did quite a while ago. To release binary archives that embed third-party dependencies is more work. The LICENSE and NOTICE file have to have details about dependencies, if those dependencies are in the binary distributions. With maven, automatic resolution of transitive dependencies is possible, which shindig relies on. However, there is not automatic resolution of licensing details, which makes crossing the legal t's and dotting the legal i's quite a chore. Is it that we have identified a new issue that actually affects _all_ Maven based releases, not just Shindig? No not necessarily. You can use maven to produce binary releases that have all the required legal details inside of them; it just isn't automatically taken care of. Not that I want to mud the waters even more, but how does the word binary vs source affects the code that is both binary and source? Substantial parts of shindig are ecmascript and php. In fact a release of shindig-php that does not contain *any* binary that is not source at the same time is a very realistic thought. Would this hypothetical release be considered source or binary? I ask because it is clear that there are different requirements to both. Or maybe I just diidn't understood anything at all... :) Regards Santiago If so, how can we both unblock the Shindig release Shindig can choose to either do the work to get the legal bits and pieces related to their dependencies sorted out and produce binary releases that follow the rules, or they can opt to do a source-only release. and also get this issue resolved in such a way as it covers all Maven based projects? To solve this issue in a way that covers all maven-based projects requires making sure that all required legal details and notices are put inside the maven repositories in a machine-processable manner, for all artifacts, and then modifying a maven plugin or two to aggregate those details automagically, and then to make use of that plugin everywhere. In other words, that's a few months of work at the least :-) cheers, - Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Approve the release of Shindig Incubator 1.0
El jue, 21-05-2009 a las 07:03 -0400, Upayavira escribió: I am a mentor for Shindig, but I am aware of a weaknesses of mine as a mentor is that I'm not that knowledgeable or experienced with the release process at Apache, and therefore have not followed this thread in detail, which I really should have. It seems that this release is stalled, but I am not entirely sure how, and want to understand this better. The thing that confuses me is that, as I understand it, Shindig is just using Maven to produce its artefacts (binary jars as a convenience to users). If that is the case, surely those artefacts are structured in the same way as other Maven based releases from other projects? Is it that we have identified a new issue that actually affects _all_ Maven based releases, not just Shindig? If so, how can we both unblock the Shindig release and also get this issue resolved in such a way as it covers all Maven based projects? +1 Regards Santiago, who has been biting his lips about not agreeing with the guy complaining in a blog entry about bureaucracy @apache, but it is more and more difficult as his lips are starting to bleed :P Upayavira On Tue, 2009-05-12 at 13:25 +0100, sebb wrote: On 12/05/2009, Vincent Siveton vincent.sive...@gmail.com wrote: 2009/5/12 sebb seb...@gmail.com: I was reliably informed that this was discussed on the Maven list in March 2008 (subject: legal-discuss) and for binary distributions that are created by the war packager that contained 3rd party libraries the DEPENDENCIES file was sufficient to comply with ASF rules. The Maven list is not the place for definitive advice. If there are any doubts, these should be raised on the legal-discuss list. Sure, it is why it was discussed on d...@maven AND legal-discuss@ http://legal-discuss.markmail.org/message/g2elchg5iwqnif6m Thanks for the pointer. The thread includes the statement: Given that I said that rolling up LICENSE and NOTICE files for artifacts that assemble and contain other artifacts such as wars and ears is out of scope for this proposal, so I'm not convinced that the thread applies here. But even if it does, Henry Yandell wrote: Let's say I include a few of the jars in my distribution, but not all. Then I'll need to add some of the LICENSE files and not other. Shindig uses the org.apache:apache-jar-resource-bundle:1.4 which is AFAIK compliant with the requirements discussed on legal-discuss. I'm not convinced. It may be that the 3rd party jars don't need to be mentioned in NOTICE, but I'm sure that their licences need to be included in the LICENSE file. Cheers, Vincent - 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: This problem of mine
El mié, 13-05-2009 a las 00:33 +0200, Emmanuel Lecharny escribió: Bernd Fondermann wrote: JSecurity was deemed as a potential naming conflict risk (much in the same way Ki is now), so we dropped it, and finally came to a vote to change the name to Ki. But this resolution took over 4 or 5 months to finally come to a favorable vote, so we didn't want to go through that painful process all over again, since it seemed like no one was willing to come to consensus on other names. It is very difficult to find an even remotely-correlated name in the security space that might not infringe on another site/company/product/trademark/patent. ok, I see. At least, for JSecurity, these conflicts never came up, did they? http://www.juniper.net/security/ That's why so many project go with names from biona or mythology. Given the difficulty and the enormous amount of time spent already, we just wanted to move on to focus exactly on the things you mention, and only worry about changing the name yet again if it was absolutely required by the Incubator to do so. That being said, if the Incubator says the Ki podling must change its name, then fine, we'll be happy to do so, but most of us didn't want to spend the effort worrying about it unless necessary. To me, it seems neccessary, but this is just my 2 eurocent. It took 4 months to move from JSecurity to Ki, just because, very like this thread, people are *discussing* for ever something which would be immediately solved if common sense was applied : avoid as much as possible any risk, and change the name if the risk is becoming a reality. This is the answer you will most likely get from legal. Lawyers know that their business is about managing risk, and risking a conflict with a new name is typically not worth it. It is different when the name has been in use before and has built up some brand power. The ASF is typically not about deciding for the projects/podlings, but about letting them decide. If something so small (though with biksheding potential) is dragging the community, I'd see it more as a symptom of another, hidden conflict, than as a real problem. That said, and if a vote on this issue would come to the PRC I would vote against having a *new* name that has a conflict, versus a well known one in the same situation. And I bet the lawyers would do the same. It will take another 4 months to decide to switch from Ki to something more appropriate if we follow the same pattern. That's a waste of time and energy. Don't follow the same pattern, then. I don't have much better ideas than this obvious one, though. Bernd, I'm totally on the same page with you. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Suggestion regarding improvement of iCLA submission process
El jue, 23-04-2009 a las 07:39 +0100, Robert Burrell Donkin escribió: On Thu, Apr 23, 2009 at 7:16 AM, Richard Hirsch hirsch.d...@gmail.com wrote: The current CLA submission process is described here: http://www.apache.org/dev/committers.html#cla-registration I'd like to make a suggestion that emails be sent to people to submitting iCLAs so that they have idea of the status of their submission. I'd suggest sending emails when an iCLA has been received, when it has been acknowledged and finally when it has been registered. It might be possible, for those received via email, that the script that commits the attachments (fairly recent addition to our processes) emails back some sort of acknowledgement. This would improve the process and avoid emails in the podling mailing lists asking about the status of individual iCLA submissions. I've just submitted an iCLA via email and I have no way to check its status besides looking at the Committers' page ( http://people.apache.org/~jim/committers.html) on a daily basis. Thanks. don't be so quick to thanks us ;-) the price of submitting ideas is being willing to actively help to make it happen :-) IMO asking the secretary to send more mails would just add more strain to our key volunteer infrastructure. so, the some means of automation would be needed. IMHO this means using JIRA to record and track these documents and the associated workflow. the easiest way to do this would be by finding a way to allow contributors to submit an iCLA via JIRA. AIUI the requirement for submission by fax, email or mail is a legal one, so the first step you need to take is to subscribe to legal-discuss and ask what steps apache needs to take to allow submission of iCLAs via JIRA. - robert - 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 Pivot 1.1 (second try)
El vie, 17-04-2009 a las 16:22 -0700, Upayavira escribió: On Fri, 2009-04-17 at 10:48 +0800, Niclas Hedhman wrote: On Thu, Apr 16, 2009 at 11:07 PM, sebb seb...@gmail.com wrote: As far as I know, putting a file in a publicly accessible SVN repository is considered as distribution too. No, I am very positive that this is not the case. Legal dilligence is done on the release artifacts separately from SVN issues. Unlike release artifacts, SVN are at times incomplete, incorrect and inaccurate. Tags have no legal meaning whatsoever, and should not even be part of the discussion. So, since we are looking at a Release, please spare the SVN discussion for later. Personally, I give a lot of weight to what Larry said on legal-discuss. I'd have him clarify, as an example, if correcting an error by deleting some resources in trunk/branches/tags would be enough, even if the offending items are accesible from specific revisions, or else surgery of the repository would be needed in those cases where we are doing unlawful distribution. But definitely in the legal* thread, not here :) Note also that unlawful distribution is not the same as Releasing against our policies. For instance, a LGPL artifact can be against our policies, but we are legally entitled to distribute it, so rewriting the past might not really be needed. Regards Santiago Both SVN and releases are distribution. So, we _must_ be sure that anything that goes into SVN we have the right to distribute. However, we choose to apply a policy on top of this to our releases - which is that everything we distribute within a release must be compatible with the Apache License. Thus, when employ X of Y Corporation checks out a project from SVN containing an LGPL library, we have not breached anyone's copyright, so we can do it, yet to package that project while including that LGPL library would go against our AL compatibility policy, therefore we won't allow it. Of course, there is always a risk that non AL compatible stuff in SVN could sneak into a release, so having it in SVN should be discouraged, but it should not be banned. This seems to me to make a lot of sense. Of course, IANAL. Upayavira - 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: Commons issues WAS RE: [PROPOSAL] Commons Incubator
El vie, 17-04-2009 a las 10:41 +0100, Robert Burrell Donkin escribió: On Thu, Apr 16, 2009 at 10:47 AM, Niclas Hedhman nic...@hedhman.org wrote: On Thu, Apr 16, 2009 at 12:07 AM, Matt Benson gudnabr...@yahoo.com wrote: * IPMC informally agrees that the opinion of any TLP prospectively admitting a graduating podling as a subproject is of great weight with regard to whether the aggregate community situation would meet volume + diversity requirements (apologies if this is hard to parse). i think that factoring in the total community would work when graduating as a sub-project of an existing TLP Ok, I think the IPMC already is considering this to be a good idea, on a case by case basis. i'm a little unhappy about the informality of this approach: 1. the incubator is now working ok for larger code bases which aim to graduate as TLPs so we need to take care over bending the rules 2. adopting this informally means that TLPs will still have the dilemma of the judgement call over small codebases with small communities I feel happy that TLPs have to exercise judgement calls. They decide if a small component is appropriate, the incubator handles IP clearance oversight and they adopt the one/two committers, handing community oversight. What is wrong? it is called empowerment, each TLP has a say in things related to their code 3. the current podling setup simulates a TLP rather than a sub-project IMHO it would be cleaner and more transparent just to tune the graduation process by introducing two separate tracks (one for potential TLPs and one potential sub-projects) we could do this in a lightweight way by asking podlings to post (when they feel ready to start pushing towadrds graduation) a [PROPOSAL] (to be approved by lazy consensus) for a target track (TLP or sub-project). the IPMC could then transparently treat podlings on each track differently, perhaps by adopting slight variations (for example, for sub-projects perhaps drafting in committers and PMCers from the target project would be useful.) opinions? - robert - 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: [PROPOSAL] Commons Incubator
El mar, 14-04-2009 a las 10:28 +0100, sebb escribió: On 14/04/2009, Niclas Hedhman nic...@hedhman.org wrote: On Tue, Apr 14, 2009 at 3:06 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: To clarify: do you mean Sanselan could graduate into Commons? Commons adopts the Sanselan codebase and active committers, upon a vote of the Incubator and in particular of the project's mentors. Sounds like a plan to me: accept smallish projects into the incubator, but give them the option to graduate to Commons instead of becoming a full-blown project, if their community does not grow enough. And projects too small for this should go directly to Commons, starting with grants/patches which help their authors become committers. +1. Sounds good to me. +1, provided that the project fits in with Commons goal(s). -1, if Commons is just used as a dumping ground for small projects. Fully agreed. In this whole discussion I have worked under the assumption that we were speaking about commons projects, i.e. tools, modules or libraries generic enough to warrant being in Commons. Regards Santiago Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Commons Incubator
El lun, 13-04-2009 a las 18:29 +0200, Torsten Curdt escribió: No harsh feelings but I give up. You do not hear what I am saying. I tend to agree with Niclas in this area, though the last exchanges you had with Noel led me closer to understand the points we seem to be missing. I guess we are using words in different ways, or else there is some context missing. The main thing I didn't took into account previously is the feeling that it is harder to earn committership when coming from inside than when donating some code. Regards Santiago On Mon, Apr 13, 2009 at 14:32, Niclas Hedhman nic...@hedhman.org wrote: On Mon, Apr 13, 2009 at 7:27 PM, Torsten Curdt tcu...@apache.org wrote: Too often had the discussion at Commons whether this library needs to go through incubation or not. That should be the case; 1. IF there is a community -- Incubation. 2. IF there is no community -- IP Clearance. With 2-4 *active* people, I think a judgment call is proper. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Commons Incubator
El sáb, 11-04-2009 a las 11:28 +0200, Torsten Curdt escribió: I think this is a self-imposed constraint. Indeed it is. Many other projects have no problem bringing in 'bulk' via IP Clearance and taking in one or two committers with it. Well, some do :) That's why now there is the proposal I guess ;) I think, like Niclas, I guess, that what is not functional is the Commons practice, and that having a kludge on the whole incubator won't really fix any problem, while adding complexity to what is already the most complex part of the ASF. Regards Santiago cheers -- Torsten - 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: Getting Apache [project] included in Linux distributions
El sáb, 11-04-2009 a las 20:35 +0100, Robert Burrell Donkin escribió: On Fri, Apr 10, 2009 at 10:46 PM, Aidan Skinner aidan.skin...@gmail.com wrote: On Fri, Apr 10, 2009 at 6:45 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On Fri, Apr 10, 2009 at 11:47 AM, Aidan Skinner aidan.skin...@gmail.com wrote: (Apache and RMS saw Java a little differently: an opportunity as opposed to a trap. Apache has always been confident in our ability to - if necessary - develop a new virtual machine, so saw no reason not to develop FOSS for the platform.) Oh, totally, and now that the whole stack is Free there's no fundamental reason for the split, but a decade+ of being in somewhat separate worlds has meant that expectations about how to build and deliver software are quite different. Most Java apps ship their deps, for instance. +1 one problem is that the Free Software echo chamber is quite a lot less nuanced that RMS It's a solvable problem though. Qpid moved back to plain ant to make shipping the Java components easier[1]. I've got patches to use Ivy, but I haven't finished the work (it's still looking for libs in something looks like a maven repo, not /usr/lib) AIUI repository arrangement should be pluggable. perhaps it might be possible to create a simple patch that could be used by the distros. That's my plan, I haven't quite gotten as far as that yet though. I suspect this hasn't happened already because it may be one of those lots of people would put a little effort into fixing it, but no one person is going to put in enough effort problems. +1 If we're serious about this, lets work with the JPackage people. The OpenSUSE build service might be helpful as well. cool anyone have any contacts over there? I don't know anyone at JPackage. I could probably dig out a few email addresses at OpenSUSE but I think JPackage is the place to start. ok anyone have contacts over at JPackage? Henri Gomez, who, IIRC, is the soul behind jpackage, is apache committer, and member, but I could be wrong about he being the boss of jpackage. Not sure how active currently, though. sg...@marlow ~/Apache/infrastructure.git (master)$ grep gomez subversion/authorization/asf-authorization | sed -e s...@=.*@@ committers-h jakarta jakarta-pmc members tomcat-pmc ws-all Regards Santiago Regards Santiago the advantage of being the upstream is that it's usually easier for us to get stuff developed than the distros so long as we understand what they need. Totally, and I don't think it'd take much. We're not a million miles from being able to do this already, it's just going to take a bit of leg work and making sure that everybody is getting what they need. cool - robert - 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: [PROPOSAL] Commons Incubator
El sáb, 11-04-2009 a las 19:56 +1000, Gavin escribió: -Original Message- From: tcu...@vafer.org [mailto:tcu...@vafer.org] On Behalf Of Torsten Curdt Sent: Saturday, 11 April 2009 7:26 PM To: general@incubator.apache.org Subject: Re: [PROPOSAL] Commons Incubator On Sat, Apr 11, 2009 at 10:22, Niclas Hedhman nic...@hedhman.org wrote: On Fri, Apr 10, 2009 at 6:32 PM, Torsten Curdt tcu...@apache.org wrote: Well, the point is: we are talking about small libraries. Imagine there is library X which was developed by only 2 developers. They want to bring this code to Commons. What to do? IP clearance is one thing. But what about the 2 developers? Just make them committers while they have no clue about Apache? Doesn't sound like a good idea. Just accepting their code and make them send patches until we feel they are ready? Feels not appropriate since they are the authors of the code. On the other hand going through the normal incubator is a bit over the top for a project that is so small that it is not targeting to become it's own project. Building a community is not really that applicable in this case. It's rather about integrating it into an existing community. Careful now, you are sinking your own proposal with your arguments. Not at all. You are mixing things up :) 1. The proposal says that there is no need to build a community, since the entire Commons community is there to make sure everything is Ok. Indeed that is the case. 2. You say that you can't just make them committers, insinuating that the Commons community will NOT be there to make sure everything is Ok. No - that is just you saying that :) There is a difference between having oversight and training people in the Apache way. This is not the same thing. If other projects get new committers through bulk contributions and train them later... Well, then that is suboptimal from my perspective. Any future committer has to learn the Apache way the hard way. Just throwing some code at us doesn't make them understand. And this is were this approach falls down for us. I personally have not experience with such contributions thanks for the code *magic wand* now you are also a committer. Either the new people have been around long enough so making them a committer soon after the code contribution was a non-problem or they sent patches until we felt they are ready. But hey - might have been differently for other projects ...not that I would be very happy about it. The incubator approach just doesn't work well for projects that have a very small scope and user base IMO. The current incubator is about establishing a project. We rather would to like to have something that helps integration into an existing project. I understand both points of view here. Unfortunately however different circumstances of the code 'donations' are getting differing treatment. My view, and I believe Torstens view is that to become a committer means to join the dev lists, send in patches, be part of the community, gain trust with the project members and then after a while be voted in as a committer. Now if someone has a nice great big chunk of code, or even a whole mini-subproject to donate, then they should so just that, donate the code and if they wish to continue working on that code then send in patches to the list or issue tracker. Eventually you'll get commit access, will have learnt the Apache Way and all is dandy. The 'other' view is I believe mainly Company orientated. Company X pays Non sequitur, and I think not the case under discussion. *My* other view is a person (definitely not a BigCo) that has developed a small code chunk (library, etc.) that would fit nicely in a given project. The code is taken and the person is granted commit rights. a) code changes can be undone in case of error, this is what scm is for b) there is -1 (veto) on technical decisions, that helps settling the community after the addition c) the person does not feel that her code is stolen, etc. Obviously I don't mean a policy cast in stone, but a judgement call on the given PMC. If they feel there can be any problems, there are several ways forward: - have the prospect committer donate the code and send patches for a while (as Gavin proposes) without being committer - have the prospect committer refactor the code in a sandbox, where s/he can be watched, as learning process - ... Regards Santiago person Y to work on code that they want to be 'donated' to Project Z (which just happens to have come from Company X in the first place.) The last thing they want is for person Y to go through the Apache Way initiation ceremony that could last months, they want him/her in there carrying on committing to it as usual. Hence we have the 'here's some code, here's a new committer or two to go with it'. The 'other' view imho is wrong
Re: [PROPOSAL] Commons Incubator
El dom, 12-04-2009 a las 12:35 +0800, Niclas Hedhman escribió: On Sun, Apr 12, 2009 at 5:55 AM, Niall Pemberton niall.pember...@gmail.com wrote: You're insinuating too much here. Simply put the commons PMC would want to see committers in action before making them full blown Commons committers. This is no different from any of the other incubations that then graduate into an existing TLP. There are no boundaries between components in Commons - all committers have svn access to all components. Ok, I just deleted a long elaboration over the Open Participation Software for Java (www.ops4j.org) community experiment, but I don't think it would be appreciated. Instead, I say this; Letting everyone have write access to all Commons sub-projects, is not an ASF requirement. You may distinguish between the sandbox and the And there are *social* barriers too. For instance, in portals.apache.org every committer, by design, has access to the whole portals repository, i.e., to pluto/jetspeed/common... repositories, but a, say, jetspeed committer arriving from nowhere to commit code in pluto would surely face -1. Even myself arriving from inactivity to patch something would get extra scrutiny and would have to justify carefully what I did unless I commit some really obvious small fix to a bug, and even so. Regards Santiago rest. And you may give people coming in with the code, commit rights to sandbox while observing and teaching them what Apache is all about. And you may have a unspoken rule of no releases from sandbox, as an incentive of people to sharpen up. Although I generally agree with Robert's sentiment, I don't think the Comcubator will lessen the burden on the Incubator PMC. Not necessarily by intent, but that there will be individuals who will want to help out, that are currently helping out on Incubator, thus thinning time for everything else. Cheers - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Getting Apache [project] included in Linux distributions
El vie, 10-04-2009 a las 18:45 +0100, Robert Burrell Donkin escribió: (...) the advantage of being the upstream is that it's usually easier for us to get stuff developed than the distros so long as we understand what they need. What they need is pretty obvious: - explicit runtime dependencies in the (==|=)package-version form, where package is recursively defined for the given distro, either already there or added at the same time - separately packaged optional dependencies - for source packages or source distributions, build time dependencies recursively covered - tested and working stuff with whatever packages are quoted as runtime dependencies, as most formats include some sort of make test in the process (gentoo ebuilds, .deb and .srpm have it) - keep it up to date Most packages start life as privately offered, and keep this way until they are accepted. The process helps debug them and keep them sane as dependencies evolve. Given (from Aidan's email)... the fact that maven goes to the network and doesn't look for libs in the standard places a distro puts them is a huge barrier to acceptance (...) and - Aidan (who is making a general plea for this not to turn into maven bashing, that's so 2008, 2007, 2006...) I'll limit to say that it might pay off to translate maven's dependency descriptions automatically into something that an automated .deb or .srpm or .ebuild template can use. Regards, Santiago (maven unconditional hater if you can find one, before someone suggest making a maven task to generate the given source package descriptions) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RES: Opinion about new framework
El mar, 07-04-2009 a las 08:19 -0300, Andre Dantas Rocha escribió: Hi Bertrand, Thanks for your reply. As you said, maybe the size of the project justifies his adoption by an existing one, like Apache Commons. In this case, is this the correct place (list) to ask if it can be done? You can try to get the module/library adopted there, but you could also develop on top of any commons component (if it makes sense, I don't have a precise technical idea) and offer them the result. While in this second case you would not be admitted into a concrete community, you can still use the commons products as building blocks to ease development and try to create the community by yourself. Not sure if it helps, Santiago Andre -Mensagem original- De: bdelacre...@gmail.com [mailto:bdelacre...@gmail.com] Em nome de Bertrand Delacretaz Enviada em: terça-feira, 7 de abril de 2009 04:49 Para: general@incubator.apache.org Assunto: Re: Opinion about new framework Hi Andre, On Mon, Apr 6, 2009 at 8:42 PM, Andre Dantas Rocha andre.dantas.ro...@uol.com.br wrote: ...I’d like to hear from incubator community if Jeha is valuable for a possible incubation I had a quick look at the Jeha quick start guide, and to me the scope looks too narrow to become an Apache project. That's just my personal opinion, other Incubator community members might differ. Apache Commons has a number of libraries that are similar in scope, you might want to have a look at http://commons.apache.org/ to see if they might be interested in adopting your project. -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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [MISSING REPORTS]: Bluesky, Cassandra, Kato,Log4php,Shindig,Stonehenge
El lun, 16-03-2009 a las 12:58 -0400, Noel J. Bergman escribió: Stonehenge and Kato reported, but the others are all absent. Cassandra, I note, discussed the need for a report, but failed to provide one. shindig discussed it too, and failed to report too Mentors should please review these projects, and comment on what actions they feel are appropriate. I'm too busy, and have considered stepping down as mentor for a while. Can't speak for the other mentors, of which we have a number. Regards Santiago --- Noel - 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: asf-authorization tidyup
El vie, 16-01-2009 a las 14:28 +, sebb escribió: There are some inconsistencies in the incubator sections of asf-authorization: 1) TLPs still listed as 'current incubator project': couchdb qpid These need to be moved further down the list, beyond the marker: # graduating incubator projects 2) TLPs with incubator subdirectories: cayenne ibatis roller tuscany The following sections should be removed, as the directories to which they relate are no longer in SVN: Aren't those directories still available in the history? Even if so, I am not sure of what is the semantics of w there... creating a new tag off an old version? branching the old tree? does not look likely or really useful. Just trying to understand the meaning Santiago [/incubator/cayenne] @cayenne = rw [/incubator/ibatis] @ibatis = rw [/incubator/roller] @roller = rw [/incubator/tuscany] @ws-tuscany = rw @ws-all = rw Thanks! - 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: Inconsistencies in authorization file
On Sun, Nov 16, 2008 at 7:38 PM, sebb [EMAIL PROTECTED] wrote: The committer dcoker is listed under the incubator shindig project, but is not in committers-d. Perhaps someone could add him? He got added in r609242 (by gstein) in the second batch of committers to shindig but not to commiters-X. I corrected those earlier, but I made a typo (added dcocker instead) in r647402. I just corrected the typo in r718083. Thanks for spotting it. Regards Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: aesthetic changes to the NOTICE file
On Mon, Aug 18, 2008 at 5:11 PM, Noah Slater [EMAIL PROTECTED] wrote: On Mon, Aug 18, 2008 at 03:59:43PM +0100, ant elder wrote: I'd be wary of doing that if i was you. Whether or not it means the same thing legally this is clearly specified in ASF policy at http://www.apache.org/legal/src-headers.html#notice and if you change from that you may find some other stickler delaying or blocking one of you release votes due to any differences. Gah, well I thought as much. IANAL but it looks okay to me. :) You might ask to the legal team, as I'm not sure of the rationale of the sentence that you missed in the NOTICE file and how much required it is. The part of src-headers we are referring to was committed by Cliff Schmith, then Legal VP, on Jul 17, 2006, r422600 and this part of it has never been changed since then. In my opinion, stating that the product includes software developed at the ASF is probably redundant, given the LICENSE file that governs the collective work. I guess it is there so that the remaining portions make sense together with a given whole. In any case, as it is current policy, it should be followed, and changes to it discussed in legal-discuss. Regards Santiago -- Noah Slater, http://people.apache.org/~nslater/ - 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: Installers for couchdb
El mié, 09-07-2008 a las 12:41 -0400, James Carman escribió: Doesn't requiring a library with an excluded license pretty much throw the apache license part out the window? Are these optional dependencies? Will couchdb run at all without them? The way I see it Erlang can be considered a platform dependency, much like java. i.e., no java Apache project runs without java, and java is not even Open Source. Trying to bundle it in unmodified form for an installer brings issues, but no more issues than installing a java runtime does, for instance. http://www.apache.org/legal/3party.html is the document listing current policies for dealing with third party licenses. The rest of the dependencies look safe (MIT or BSD'ish should fall into A), though I have not looked into the details. spidermonkey is the only component that has a more restrictive license, and the third party licensing policy document lists MPL in the B category. So I think we can choose MPL and distribute it in binary form, etc. If you forward this request to legal-discuss@ you can get a detailed review of the different licenses. Regards Santiagp On Wed, Jul 9, 2008 at 12:12 PM, Craig L Russell [EMAIL PROTECTED] wrote: On Jul 9, 2008, at 9:37 AM, Philippe Ombredanne wrote: Howdy: I am working on couchdb installers that I would like to contribute back to the project: A fully functional CouchDb install has a few external dependencies such as: - ICU (ICU License a BSD/MIT style license) - Mozilla SpiderMonkey (MPL, GPL or LGPL) - Erlang (ERLANG PUBLIC LICENSE) - Openssl (OpenSSL license, a BSD style license) My understanding is that it would not be acceptable IP-clearance wise to have all (though some may be) those bits shipped as part of all-inclusive installers. That's my understanding of the current consensus as well. My request: Would it be acceptable to create installers that would fetch at install time the required external bits from their original download locations? Those fetch operations would be clearly presented as external fetch operationsto the users. I think the current operative policy is from http://www.apache.org/legal/3party.html: • For add-ons under excluded licenses, the PMC may provide a link/reference on the product web site or within product documentation to some other web site that hosts such add-ons (e.g. a SF.net project or some third-party site dedicated to distributing add-ons for the Apache product) as long as it is made clear to users that the host site is not part of the Apache product nor endorsed by the ASF. • For add-ons under excluded licenses, the PMC may include a feature within the product that allows the user to obtain third-party add-ons if the feature also alerts the user of the associated license and makes clear to users that the host site is not part of the Apache product nor endorsed by the ASF. So as long as your installer makes it clear to the user that the external bits are not Apache-licensed, I read the policy as allowing the CouchDb installer to fetch and install them and thereby make them available to the CouchDb user. Craig Cordially -- Cheers Philippe philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com nexB - Open by Design (tm) - http://www.nexb.com http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf - http://eclipse.org/vep - http://labs.jboss.org/drools/ - http://developer.mozilla.org/en/docs/XULRunner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig L Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gummit crypto for UIMA-AS
FYI, according to git log --stat -p --color-words -M -C -- docs/licenses xdocs/licenses, the words UIMA or uima do not appear in the whole revision control log (including messages and diffs) of the docs/licenses and xdocs/licenses directories. I don't think the update of the document ever happened under version control. Regards Santiago On Mon, Jun 30, 2008 at 5:12 AM, Marshall Schor [EMAIL PROTECTED] wrote: sebb wrote: On 29/06/2008, Marshall Schor [EMAIL PROTECTED] wrote: Rodent of Unusual Size wrote: Sending to Noel as i.a.o chair to forward.. ---EMAIL HEADER--- To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: TSU NOTIFICATION - Encryption ---EMAIL BODY--- SUBMISSION TYPE: TSU SUBMITTED BY: Noel J. Bergman SUBMITTED FOR:The Apache Software Foundation POINT OF CONTACT: Secretary, The Apache Software Foundation FAX: +1-919-573-9199 MANUFACTURER(S): The Apache Software Foundation PRODUCT NAME/MODEL #: Apache UIMA-AS ECCN: 5D002 NOTIFICATION: http://www.apache.org/licenses/exports/ The entry for UIMA-AS (a component of UIMA which we would like to start the release vote on) which was at one point visible on http://www.apache.org/licenses/exports/ is no longer there. Can someone with access to the SVN for this, say what caused it's disappearance? When was the entry added to the exports page? I've looked at all the index.html files committed in 2008, and cannot find any entry for UIMA. I had a message from Ken Coar that he updated the index.xml page on June 4 2008 (3:25 PM EDT). Maybe the wrong page got updated? -Marshall -Marshall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: INCUBATOR-57 aka IPMC votes to ratify PPMC committers
El jue, 05-06-2008 a las 08:21 -0400, Jim Jagielski escribió: On Jun 3, 2008, at 4:29 PM, Justin Erenkrantz wrote: --- I'd like to make the suggestion that we alter this to: --- Vote on the podling's private (PPMC) list, with notice posted to the Incubator private list. The notice is a separate email forwarding the vote email with a cover statement that this vote is underway on the podling's private list. Many consider this approach to be best practice. After completing the vote on the PPMC list, the proposer *sends a note to* the Incubator PMC private list, summarizing the discussion and vote, with a reference to the archived discussion and vote threads by the PPMC. *Any member of the Incubator PMC can ACK the receipt of the vote. This starts a 72-hour window for lazy consensus. After 72 hours and no requests by any Incubator PMC member for a full vote by the Incubator PMC, the committer request is approved by the Incubator PMC and the PPMC can start the committer invitation process.* --- This intentionally follows the procedure for adding a PMC member wrt full ASF board. I like the concept of expanding this for committers as well for Incubation, so there. I don't like needless 'dual voting', but I do want the IPMC to have the chance to execute oversight. +1 +1 I guess it should be done for both cases, public or private vote. There is not a substancial difference between both cases that I can see. While in principle finding who voted when and how in a private list is slightly more cumbersome than on a public one, I don't think this merits a difference in process. Regards Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (INFRA-1585) Zone for Shindig
El mié, 23-04-2008 a las 14:20 -0700, Dan Peterson escribió: Hey folks, As additional background, at ApacheCon EU, Noel Bergman proposed the idea of Shindig getting a Zone (for running a sample instance, as well as for nightly builds). Noel was actually quite surprised that we didn't already have one. I think review board is a natural extension of what we'd use that Zone for, to improve the quality of code reviews. Count me on for setting up and maintaining review board. I have an instance running locally and got some experience making it work in the process. In addition it is written with django in python, and I'm using django, and loving it, in my day job currently. Regards Santiago -Dan On Wed, Apr 23, 2008 at 12:31 PM, Dan Bentley [EMAIL PROTECTED] wrote: Shindig wants to run an instance of review board, a nightly build, and a running reference server. Is this something shindig should do (using a Zone), or should we try something else first? Thanks, -Dan -- Forwarded message -- From: Joe Schaefer (JIRA) [EMAIL PROTECTED] Date: Wed, Apr 23, 2008 at 3:09 PM Subject: [jira] Commented: (INFRA-1585) Zone for Shindig To: [EMAIL PROTECTED] [ https://issues.apache.org/jira/browse/INFRA-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591742#action_12591742 ] Joe Schaefer commented on INFRA-1585: - I would appreciate it if you ran your request by [EMAIL PROTECTED] before we go any further. Infrastructure has not granted zones to incubating projects before, as the request for a zone typically comes from a PMC. If all you can get is lazy consensus on [EMAIL PROTECTED], I suppose that's good enough for us. Zone for Shindig Key: INFRA-1585 URL: https://issues.apache.org/jira/browse/INFRA-1585 Project: Infrastructure Issue Type: Wish Security Level: public(Regular issues) Components: Zones Reporter: Dan Bentley Assignee: Norman Maurer Shindig wants a Zone to run an instance of Review Board, a sample container, and a nightly build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Requesting proper karma for Tuscany Committers to access repo/private/committers
El mar, 15-04-2008 a las 16:24 -0700, Luciano Resende escribió: Could someone on the IPMC please help us get the proper karma to some Tuscany committers that does not have access to repo/private/committers. From a thread on [EMAIL PROTECTED] the following committers does not have proper access : agrove ajborley amita edwardsmj frankb fuhwei gwinn isilval jmarino jsdelfino kelvingoodson kwilliams slaws svkrish BTW, I'm asking this here, per infra@ request. done. jsdelfino was already added by joes at r648453 Regards Santiago Thanks -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Report reviews
El lun, 14-04-2008 a las 02:02 +0300, Jukka Zitting escribió: (...) * Shindig - Issues before graduation? Any template for the standard way to report those? I think we are still far from it, but it is good to add the template to our mindset, and fill it in with data. Regards -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion vs other source control systems
There is now a list to discuss this kind of things, infra-dev. I CC: it. Please drop the email to [EMAIL PROTECTED] if you answer. El mar, 08-04-2008 a las 08:17 +0100, Danny Angus escribió: On Thu, Feb 14, 2008 at 12:37 PM, Santiago Gala [EMAIL PROTECTED] wrote: If I remember correctly, the policy was not to impose subversion, but to mandate end of life for CVS. If I remember correctly, this was due to security concerns, CVS requiring user accounts in the machine where the repository is stored while subversion does not. Also functionality. Also that having a lengthy transition was stressing infrastructure. I have been looking into mail archives but have not found a pointer yet. That's also my recollection. ... I don't think centralization has ever been part of the Apache way. I think the cvs-svn experience, and the wiki experience, would suggest that we need to be mindful of the maintenance overhead of not centralising some practical things. I can't see any issue re: the cvs-svn experience and centralization: both environments are clearly centralized, and the migration was done by a small team, from a central repository to a central repository. The moinmoin farms as also very centralized, more aking to vhosts than to separate servers. I'm not really aware of the maintenance overhead of the wikis, but I'm betting that it is not bigger for moinmoin than for cwiki, (I think we have a number of hours donated for the maintenance of cwiki/JIRA) which in addition is proprietary. But thats not the same as centralisation as a principle. And as a final point, don't take this too seriously but... the ASF and the Apache Way has probably been shaped more than we would like to admit by the workflow imposed by CVS. SVN is very similar, but distributed source control has very different workflow which would either conflict with or change the way if adopted. The workflow you do wih most dSCM tools is literally up to you. I have prepared a refactoring for shindig ( http://github.com/sgala/apache-incubator-shindig/commits/synd-rename-2 about a 60k global patch, 38 small commits with git) using git, so that I can get familiar with advanced uses of git at the same time. I am (anybody is) free to test it in this branch that I published. What is more, everybody can look into the code with reasonable color diffs. The tool is able to rebase the patch as new commits come in, and it can merge changes inside the context of a file renamed in the first patch. What it is more, I can (anybody can) git diff --stat -p -M synd-rename synd-rename-2 and see what changed between versions of the patch, which already allowed me to detect a merge problem that I introduced when I reordered the commits to get the patch series cleaner to look into. github can't do that, but my local gitweb can An extra goodie is that the git repo with the whole history of the project is smaller (and way faster to access) than a single subversion working copy. And this is true of every project I have tried with git-svn. You might tell me that I could have started a subversion branch to do it, and I'd answer: why is it that nobody does it in the real world? This is really where the workflow of subversion is hurting^Wshaping us. Regards Santiago d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: License files - separate or one file [was Re: [VOTE] Approve the release of Apache Abdera 0.4.0-incubating (updated)]
El mié, 02-04-2008 a las 23:08 +0100, sebb escribió: On 02/04/2008, Robert Burrell Donkin [EMAIL PROTECTED] wrote: On Wed, Apr 2, 2008 at 8:59 PM, sebb [EMAIL PROTECTED] wrote: On 02/04/2008, Kevan Miller [EMAIL PROTECTED] wrote: On Apr 2, 2008, at 1:43 PM, Dan Diephouse wrote: snip I misspoke. Here's what I meant to ask: Do we need to 1) include all the licenses for all our dependencies in a single LICENSE file or can we 2) have our top LICENSE file which is ASL and then have individual LICENSE files for each library in the lib/ directory. I'm not aware of a requirement for having only 1 LICENSE file. In fact, the document says you don't have to append 3rd-party licenses to the LICENSE file. It does say you should put a pointer to the license files. So, IMO, 2) is fine. Other Apache projects do this also. 2) is fine so long as the main LICENSE jar tells users where to find the other license - i.e. it has pointers to the other licenses. AIUI this is not policy My understanding differs, so I think this needs to be resolved and formally documented. My understanding is as sebb's, and the rationale is that the LICENSE file is where the different licenses governing components of the product are documented, and the NOTICE file documents mandatory copyright notices and attributions from subcomponents, such as they would appear in an About... box. The part requiring that the top LICENSE file documents the whole licensing agreement was stated recently in legal-discuss because of a question asked there, and it is common sense, as the most natural place to look for a LICENSE is a top level LICENSE file, which is additionally a universal convention in the world of software from like 20 years ago. Regards Santiago - 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] -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source tar ball != svn tag (was: Re: [VOTE] Approve release CXF 2.0.5-incubator)
El dom, 30-03-2008 a las 10:19 -0700, Matthieu Riou escribió: So what makes you pretty sure public access to a SCM amounts to distribution in the definition of publication? AFAICT, there's still no purpose of distribution. We don't offer the download of a tarball from our repositories. That others offer doesn't change what our source repository is. From http://en.wikipedia.org/wiki/Repository , while there are a number of things that a repository is, I stress this one: a place where multiple databases or files are located for distribution over a network (multiple - several different tags, releases, modules, etc.) In fact a source repository is for archival, auditing, development *and* distribution. The fact that reading from it is 100% free (except certain anti-DoS provisions) doesn't help claims about it not being a distribution mechanism. Re: the purpose of further distribution, gentoo, just to give an example, offers sometimes -svn/-git/-cvs versioned packages, and those are built by accessing the SCM repository, checking out a HEAD copy, building the binaries and installing. I've seen this kind of packages (repackaged) in debian and rpm distributions too. and I've seen plenty of XXX-patched-cvs-200X.tgz/jar files in our own distributions. Which means that these pakages, if they're produced and published with an intent to be distributed could very well be a publication. Still doesn't mean that offering a repository is by itself a publication. The moment something is publicly out on a web site (and subversion implements a superset of HTTP), it can be safely assumed that there was an intent of publication of it. I think you'd had a difficult time trying to convince a judge that it is *not* a distribution mechanism. Regards -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source tar ball != svn tag (was: Re: [VOTE] Approve release CXF 2.0.5-incubator)
El jue, 27-03-2008 a las 21:42 -0700, Matthieu Riou escribió: (...snip...) From what I understand of copyright law, it's not (of course IANAL, etc...). Distribution (or publication in copyright lingo) is defined as: Publication is the distribution of copies or phonorecords of a work to the public by sale or other transfer of ownership, or by rental, lease, or lending. The offering to distribute copies or phonorecords to a group of persons for purposes of further distribution, public performance, or public display, constitutes publication. A public performance or display of a work does not of itself constitute publication. The way it is written I take performance/display in the sense of executing the score (for music), playing the play (for theater), showing the movie, reading the poetry, exhibiting (displaying, for paintings)... A source repository is in the category of public performance or display, there's no purpose of further distribution. It doesn't constitute publication. I'd say that performance of software is executing it (like in music or theater, software is a dynamic art). Now I'm not sure if the public word stretches the meaning too much. But I'm pretty much sure that giving public access to a SCM repository amounts to distribution. Just notice how trac, git, mercurial and other UIs for SCM offer the download of a tarball for arbitrary revisions, for instance. Re: the purpose of further distribution, gentoo, just to give an example, offers sometimes -svn/-git/-cvs versioned packages, and those are built by accessing the SCM repository, checking out a HEAD copy, building the binaries and installing. I've seen this kind of packages (repackaged) in debian and rpm distributions too. and I've seen plenty of XXX-patched-cvs-200X.tgz/jar files in our own distributions. Regards Santiago Cheers, Matthieu -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [docs] Initial Import Best Practice
El jue, 13-03-2008 a las 20:20 +, Robert Burrell Donkin escribió: i'm trying to pull together some best practice documentation for the initial code import. i'm going to throw some (quite possibly incoherent) opinions out there to start discussion but if anyone has opinions feel free to ignore the strawman... IMO the original sources covered by the appropriate agreement should be available as part of the public record of the project. JIRA most likely covers this. checking in the unconverted code most definitely covers this (where? into a stage/inport directory? into position?). I'm not sure about the current procedures but I'm doing some academic work related with historical analysis of code bases. As part of it I'm testing the use of git-format-patch/git-diff-tree (similar to cvsps) to convert a git history tree into a set of mail messages that can be later imported with git-am, preserving history (except for a Committer: header added). I'm quite sure that a similar export exists for most in not all scm products, and it means that we could preserve history very easily, even if the code is moved into/from a different repository or set of those. it is better to convert the originals outside and commit only cleaned up code to the repository? (this has the advantage that uncleaned code is not committed to the code stream). I'm not sure about current practices, but trying to preserve code history is important for a number of reasons, specially in those contributions that are coming from an Open Source project and a public repository still exists. I'd prefer to have the cleanup done as a commit or set of commits, be it in the original repository or in ours, rather than breaking the continuity of commits. The idea is that, both for audit purposes and for historic/research analysis, it is better if code that is already in a repository is kept in the form of a tree/graph of revisions. useful tools for relicensing (i know about those in committers)? I'm also interested in a script to detect, using a set of heuristics, different licenses inside our code. I'll probably start writing something myself if I can't find one. They could go together, in a sense, as detection of license content is a first step towards conversion... Regards Santiago - robert -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graduation resolution feedback - Qpid as TLP
El lun, 03-03-2008 a las 12:23 +, Upayavira escribió: On Mon, 2008-03-03 at 07:13 -0500, Yoav Shapira wrote: On Sun, Mar 2, 2008 at 11:12 PM, Niclas Hedhman [EMAIL PROTECTED] wrote: On Saturday 01 March 2008 22:18, sebb wrote: None of the mentors seem to be included. Perhaps this is normal for graduating podlings? Often Mentors have no direct involvement in the codebase being produced, and therefor no vested interested of committership/PMC. However, I, as a IPMC member, would expect the mentors to hang around the graduated PMC (for TLPs) a while after the graduation just to provide support if needed, and make sure everything is running smoothly. I don't mind hanging around. I think the Qpid PPMC is well-entrenched in the ASF ways, so I didn't think this was necessary, but if someone sees it as required, I'll hang around the QPID PMC and offer any help needed. What I see as important is that there is member representation on the PMC. If there is sufficient member representation without you, then no problem! Exactly. Lack of member representation will cause disconnects. Even if a non-member PMC chair has access to some private channels, there will be less awareness of their activity in both directions. The worse part of it is that the lack of awareness will probably reduce the probability of any of the PMC members to be nominated for ASF membership... perpetuating the disconnect. Regards Santiago Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Audit Report 2008-03-02
El dom, 02-03-2008 a las 20:52 +, [EMAIL PROTECTED] escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Audit Report: 2008-01-29 - 2008-03-02 == * 18 files were added * 2 files were modified * 0 files were deleted For details see http://incubator.apache.org/audit/changes-2008-03-02.html The file is not there, nor any file from February. I guess something is going wrong in the script. Regards Santiago -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHyxN2l6Otx30NTe0RAvvAAKCEDUlT8O6J0vDp8/YlPFEdBFWeagCfQ4kC VvZ/9e5te0LJsnOO5uHnens= =yP2l -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Lucene.Net Comitters
El vie, 22-02-2008 a las 09:34 +0100, Endre Stølsvik escribió: Bertrand Delacretaz wrote: Another option might be to take the code somewhere else for a while, work on it, gather a community and come back to the incubator when the project has gathered some momentum. Why would that be a good idea? The infrastructure is already set up and working at Apache, and Lucene (the actual one!) is an Apache project. If I remember correctly, Lucene.NET is supposed to graduate into Lucene. I guess the Lucene PMC would be a good place to ask for opinion or volunteers for keeping the .NET port alive. My 2cents Santiago Given that these folks have even submitten a single patch, and share the view of the Lucene.Net project description (a clean .Net-copy, API wise but most importantly, bitwise copy index wise), why not just grant them committership? It is in the incubator, and it does apparently still have some _slight_ traction. You could simply delay the killing-off somewhat - who knows, maybe it'll revive. .. Or else that project might just die, which probably would be a shame. Regards, Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Subversion vs other source control systems
El mar, 19-02-2008 a las 23:06 -0500, Noel J. Bergman escribió: Endre Stølsvik wrote: I find the decision to use one single SVN repo for the entire organization's source pretty strange. I'd believe that one repo for every TLP Been there, done that, have the scars. Possibly using several *centralized* repositories that can't merge. May we know more? If not, I call FUD ask the jury to ignore the statement. :) The only downside I see is a slight bit more configuration management Don't be so blithe about that. I actually think management would be way smaller. And, what is more important, distributable per repository. and that copying/moving a file from one repo to another would not keep history Unacceptable to lose it, IMO. Can be done without losing history. See separate email. And I have done the same test with hg (basically the same) and bazaar (which required some command line tweaking, but doable). And you'd be surprised how often things move around. If you take a look into the basic development model in the linux kernel, it means moving history between repositories continuously (say from am to net to linus,...) Every line of code is tracked while it moves, in fact when Linus merges from, say, the acpi tree, the commits remain identical. Regards Santiago (I add cc: and reply-to: community) --- Noel - 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: Subversion vs other source control systems
El mar, 19-02-2008 a las 22:29 +0100, Endre Stølsvik escribió: Upayavira wrote: Justin put it very well in a related thread elsewhere (permission sought): [ CHOP interesting adamant view from Justin ] (Where is elsewhere, btw?) the discussion spread to a private list outside here. We should move this kind of discussion to a different public list, I guess it is mostly out of scope in [EMAIL PROTECTED] (except in the what is the apache way, probably) I will try to post a followup in community, again. What I find strange in all this is the view that ALL projects at Apache would have to change to OtherSCM if one project would want that.. I also find it strange. I guess it spreads from the fact that subversion (or old cvs) can only preserve history easily when moving inside the same repository. I made an experiment, which I will publish in a blog entry, where I pulled from repo2 into repo1 for two git repos. This is easy and works, provided that there are no name collisions that are not supposed to be merged together. If I have a hypothetical podling1 repo and another hypothetical targetTLP1 repo, I could (say on graduation) do: cd podling1 git-branch to_target1 git-checkout to_target1 mkdir target-tree git mv * target-tree #* does not work but you get the idea... git-commit -a -m this is for targetTLP after graduation cd ../targetTLP1 git-branch merge_podling1 git-checkout merge_podling1 git-pull ../podling1 #it could be a remote repo too ... git commit -a -m merged podling1 in targettree gitk --all #to view the merged repos, it has a new tree in target-tree And proceed moving code around or merging as appropriate. (Not sure how would hg or bzr handle this use case). I don't know how this would work in practice, there is a need to experiment this kind of things to find corner cases and problems. But I think, as you comment in the following paragraph, that it buys us lots of extra flexibility and scalability. Indeed, I find the decision to use one single SVN repo for the entire organization's source pretty strange. I'd believe that one repo for every TLP, for example, would be great (AFAIK, TLP-promotion can be handled too with history preserved). This would help in every single aspect in regard to the volume of source and activity, could use multiple servers etc - and incidentally using another SCM for a particular project wouldn't be that big a deal anymore. The only downside I see is a slight bit more configuration management, and that copying/moving a file from one repo to another would not keep history that well. How often does this happen, though? Actually, if you try the above as I have done with a couple of small repos, it keeps the whole history, including moves, committer info, etc. Typically modern SCM (this includes subversion FWIK) don't version files, but rather store graphs of commits/changesets. This means that pulling a commit from a different repository will go pulling parent commits up to the first common commit or, lacking it, to the root of the history. Regards Santiago However, I'm no SVN expert, so I can easily have misunderstood everything. Endre. - 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: Subversion vs other source control systems
El dom, 17-02-2008 a las 19:02 -0500, Noel J. Bergman escribió: Santiago Gala wrote: I think git-svn abuses the server a lot, as the subversion server is not designed for copying of the whole history. AFAICS, that's an issue for the Infrastructure Team to address, not the Incubator. Dw wrote: I am a bit lost here as well -- what does GiT add to the processes/ workflows common in the ASF ? - faster commits, branch switching, pulls and pushs - merges, good and persistent merges - offline work, offline history diffs - rebasing is not such a feature, but it can be useful sometimes - publishing lots of repositories helps surfacing patches that are currently hidden until ready for sending/committing The last one is almost antithetical to how we want people to work. The first few are something that you could raise with the Subversion folks on [EMAIL PROTECTED] Can you elaborate on how is publishing what currently is hidden antithetical to how we want people to work? I think that getting a clear idea on this is important, as I always thought the ASF was about transparency and not keeping information hidden. And I think it is in scope, as the incubator is an important place for people to learn our ways. The inability of subversion to remember merged results makes working in a branch unpractical. Been there, done that, very tricky. Raise any technical issues with the Subversion folks. huh? why? Turning your key poing upside down: We should not try to impose our practices using a technological tool, specially when doing so impairs development. If there is a better SCM *for our way of working* raise that on infra@, too. people *against* changes in SCM is blaming a hypothetical introduction of git of breaking the ASF practices No. This is the wrong forum. What we've said here is that there won't be any deviation from the ASF infrastructure for source control; changing ASF infrastructure is out of scope for the Incubator. I already tried to move the discussion to [EMAIL PROTECTED], where I think it belongs, but people insists on answering here. Making requests to a closed team in a private list does not accord with *our way of working*, I think. And I don't think there is any need to use a private, unarchived list for discussions on infrastructure improvements. Regards Santiago --- Noel - 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: Subversion vs other source control systems
El dom, 17-02-2008 a las 17:24 -0800, Justin Erenkrantz escribió: On Feb 17, 2008 3:34 PM, Santiago Gala [EMAIL PROTECTED] wrote: Also: you keep a long term branch for doing some refactoring, and you fix small bugs both in HEAD and in a release branch, merging and backporting/forwardporting as you go. Again, something like git makes the work simpler and keeps the disk requirements under control. In an attempt to stop some of the outright FUD in this thread before it goes on to yet another mailing list... outright FUD? Sorry but I don't think there is Fear, Uncertainty or Doubt in this thread. There are several testimonies of good experiences with git, and the only downplay of subversion has been the problems with merging, which I think are real. I would only call FUD if there had been mentions, say, to subversion corrupting repositories or similar, and I think those times are far in the past. I've found that svnmerge.py (distributed with SVN) handles pretty much all of the branch/merge tracking capabilities that I personally care about. (The drawback is that it isn't as efficient as we'd like, but Not in my copies (I tested Gentoo linux amd64, subversion-1.4.6, and a different 1.4.3 Mandriva rpm). I guess they don't ship contrib stuff. Linus Torvalds discusses extensively work flow processes in http://git.or.cz/gitwiki/LinusTalk200705Transcript , and I think he is mostly right in the fact that distribution is the way to go, and not just because of disconnected operation. In one of the projects I track and patch, I don't commit myself, but I have contributed a number of components and patches and I keep ongoing patches. I would never be able to use svnmerge.py without the ability to create branches or commit. it's good enough. The 1.5 stuff is *way* faster.) From your statements, you probably haven't bothered to try svnmerge.py (usable with 1.4.x) or any of the new reintegrate merge stuff in 1.5. It makes it pretty brain-dead simple to handle most branch-oriented merging cases. There are a few pathological cases that don't work well, but that's 'reflective' merging which isn't the 95% use case - so it got punted to post-1.5. (svnmerge.py is probably the 80% use case, with 1.5 merge tracking being 90%, and reflective merging being that last gap...) FWIW, for svn.apache.org, I have a feeling we'll probably be a tad aggressive on rolling out 1.5. (Besides merge tracking, there are a number of excellent features in 1.5: changelist support, interactive conflict resolution, read/write transparent proxies, integrated 'diff -x -p' support, substantial svnsync speed improvements, partial svnsync ability, etc.) Note that nothing is stopping you from using svnmerge.py today. If folks are going to complain about switching to another SCM because of a lack of decent merging, then they owe it to themselves to check out what Subversion can actually do rather than what they think it can do... -- justin Well, I tried svk, git, mercurial and bzr. I am even using darcs because of some openID code I track. I prefer git, even when forced to use git-svn, to svk. Still, I will try to look into svnmerge.py, I found it here http://www.orcaware.com/svn/wiki/Svnmerge.py Regards Santiago - 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: Subversion vs other source control systems
El dom, 17-02-2008 a las 19:12 +0100, Leo Simons escribió: On Feb 17, 2008, at 4:51 PM, Noel J. Bergman wrote: Most of the use cases mentioned so far for git, including some where people are using it on top of SVN with ASF projects, run counter to ASF principles. Let me fix that: Use case: work on apache project while on plane --- * export list of jiras of your favorite ASF project into spreadsheet * sync project repo to your laptop * get on a plane for 14 hours * slave away at the bug list, fixing a bunch * create one patch per bug, with a good commit message, referring to the bug report, and commit locally * get off the plane * get online * sync project repo to your laptop * resolve any conflicts * for each bug report * submit and commit the fix * close the bug report This is easy to do with git. It's a small nightmare with SVN, especially if your project is a million lines of code. A big +1 on this use case. Have you tried this one? Also: you keep a long term branch for doing some refactoring, and you fix small bugs both in HEAD and in a release branch, merging and backporting/forwardporting as you go. Again, something like git makes the work simpler and keeps the disk requirements under control. (you could substitute while on plane with even if network craps out at hackathon or with at a customer site with big firewall) I am saying that (a) the ASF has a uniform source control infrastructure, which is currently based on SVN servers, and (b) our practices mean that development is done in public, not done in private and submitted en masse as a fait accompli. These statements are independent of the SCM technology used by the ASF. Exactly! Agreed too. cheers, - Leo - 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: Subversion vs other source control systems
El dom, 17-02-2008 a las 10:58 -0500, Noel J. Bergman escribió: Dirk-Willem van Gulik wrote: Ross Gardler wrote: I understand that GiT can be used locally as a layer on top of SVN. I believe this gives you most of the perceived benefits of GiT locally without the need for a project itself to switch to GiT. The issue isn't git as an SVN client. No one (as far as I know) cares what SVN client(s) you use, so long as they don't abuse our SVN server. I think git-svn abuses the server a lot, as the subversion server is not designed for copying of the whole history. I agree that exporting svn to git/bazaar/mercurial, etc is a way forward, but it will cause strain to the svn server, for sure. As seen elsewhere, Jason took this path, and I'm actually using this technique in a number of places, both with git-svn and bzr-svn. I will keep reporting. I am a bit lost here as well -- what does GiT add to the processes/ workflows common in the ASF ? I already answered to this one in the thread. - faster commits, branch switching, pulls and pushs - merges, good and persistent merges - offline work, offline history diffs - rebasing is not such a feature, but it can be useful sometimes - publishing lots of repositories helps surfacing patches that are currently hidden until ready for sending/committing I hope helping each and every developer/contributor counts as helping the ASF. One of the great things about GiT is that you can can have lots of parallel and non-linear merges (every developer their own branch; However in the ASF most groups work roughly along fairly linear lines; with 'one' or just a 'few' points at which a patch is accepted - and essentially few, or just one, merge point (or a single line of merge points when backported). Rarely do we merge multiple 'HEAD's. huh? every vendor keeping patches against apache repositories is merging often. I don't follow your reasoning, anybody keeping patches is merging repeatedly against a moving HEAD (for active projects). In my view, every developer that maintains patches is in effect having a *private, unpublished* branch. With git and a setup like the one in kernel.org, all those patches are suddenly public, visible. Think about it. And most importantly, we want our development to be visible to the Community, not done in private and committed when finished. Developers can always make more or less transient branches to work on code, still in public view, and merge back to shared locations. The key point here that I believe you, I, William and others are all making isn't about technology, it is about practice. The inability of subversion to remember merged results makes working in a branch unpractical. Been there, done that, very tricky. Personal repositories can be kept in public, you just can look into the different branches in http://git.kernel.org/?p=linux/kernel to see how a number of those are updated a lot. Turning your key poing upside down: We should not try to impose our practices using a technological tool, specially when doing so impairs development. Now, if there is an SCM that substantially improves the ASF's ability to perform *our* practices, that is a separate discussion item. I'm quite sure currently any one of git, bazaar, mercurial or even darcs would improve our practices. Just to make sure, my view of the discussion: people *against* changes in SCM is blaming a hypothetical introduction of git of breaking the ASF practices I don't think the discussion is, and never was presented as: evil revolutionaries wanting to break the practices by introduction of sneaky solipsistic tools. I don't think git will break ASF practices more than keeping quilt patches, or several repositories, to survive svn up without nasty conflicts. Regards Santiago --- Noel - 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: Subversion vs other source control systems
El mié, 13-02-2008 a las 18:28 -0500, Noel J. Bergman escribió: J Aaron Farr wrote: J Aaron Farr wrote: git could be an issue. Can you explain what the issue is with Git? Leo already gave a decent explanation. Basically, it comes down to two aspects: 1) infrastructure support 2) cultural bias Only the first one is marginally correct, IMO. Santiago wrote: 1. You have to use subversion. Why? Has been a vote done? where? I vote +1 for git if a vote is still open. No, there was no vote and is not vote, nor is there any choice. Subversion is one of the few things that the Board has mandated, imposed on all projects. Period. Pretty much end of discussion. No project was allowed to stay with CVS. No project will be allowed to use another source control system unless it is adopted at the ASF level. Source code is a critical, shared, public resource maintained by the Foundation, not something whose storage is managed on a project by project basis. The Infrastructure Team maintains and protects that shared resource on behalf of the Foundation. If I remember correctly, the policy was not to impose subversion, but to mandate end of life for CVS. If I remember correctly, this was due to security concerns, CVS requiring user accounts in the machine where the repository is stored while subversion does not. Also functionality. Also that having a lengthy transition was stressing infrastructure. I have been looking into mail archives but have not found a pointer yet. Funny enough, all people using distributed SCM quoted ease and simplification of administration as one of the core advantages, be it git, bazaar, mercurial or darcs. If I read correctly your last two sentences, I see that - you are no longer considering the Foundation as an umbrella for the projects, but as an entity with a life that, I see from your reaction, needs to protect itself from the (some?) projects - The infrastructure team is a Police body (to serve and protect) Information can be copied and still stays the same, trying to restrict it to a server is really futile and wasting. The only thing that actually would need a custody would be a PGP-signed text document with SHA1 of the release source and date. And I don't think it would be signed by the infrastructure team, but by the three +1 voters of the release in the PMC. And this custody can easily be achieved by publishing in a multiply archived email list. I don't think centralization has ever been part of the Apache way. Regards Santiago --- Noel - 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: Subversion vs other source control systems
El jue, 14-02-2008 a las 12:37 +0100, Dirk-Willem van Gulik escribió: On Feb 14, 2008, at 12:25 PM, Ross Gardler wrote: Noel J. Bergman wrote: J Aaron Farr wrote: J Aaron Farr wrote: git could be an issue. Can you explain what the issue is with Git? Leo already gave a decent explanation. Basically, it comes down to two aspects: 1) infrastructure support 2) cultural bias Only the first one is marginally correct, IMO. Santiago wrote: 1. You have to use subversion. Sorry, I've missed the thread that led to this, so sorry if I'm repeating others. I understand that GiT can be used locally as a layer on top of SVN. I believe this gives you most of the perceived benefits of GiT locally without the need for a project itself to switch to GiT. I am a bit lost here as well -- what does GiT add to the processes/ workflows common in the ASF ? It adds: - ability to have offline commits - much faster repository diff, status, etc. that works offline - (git-specific) ability to reorder and aggregate several private commits to deliver a consistent patch. This can only be simulated with other tools - ability to publish (push/pull) branches easily for tests without compromising the main line. Subversion branches, while easy to create, are awful to maintain and rarely used. - clean and remembered merges: patches with clear attribution that can be merged multiple times which, again, makes easy maintenance of several branches running in parallel.Backports, etc. One of the great things about GiT is that you can can have lots of parallel and non-linear merges (every developer their own branch; lots of people merging the same patch into different sequences) -- and as such I can see it being perfectly tuned for, say, Linux. Precisely the fact that patches are accepted in just 'one' or 'a few' points make invaluable having good maintenance of in-progress work. However in the ASF most groups work roughly along fairly linear lines; with 'one' or just a 'few' points at which a patch is accepted - and essentially few, or just one, merge point (or a single line of merge points when backported). Rarely do we merge multiple 'HEAD's. Not in my experience, it is common to have in-progress work in parallel with bugfixes, etc. subversion is awful for tracking multiple branches in parallel, to the point that I have been using quilt for patch management of top of subversion. This is clearly a kludge that reveals the deficiencies of the workflow. You see? rarely do we merge multiple HEADs is seen from the point of view of the repository. If you have 10 developers working on patches, you have 10 people merging continuously their branch with the official one. Rarely applies only to the subversion repo. And I'd almost argue that SVN is a useful framework which helps us stay on the paved roads - where a single head progresses with group consensus and generally agreed merit. I've seen plenty of times where having in-progress patches were consistently conflicted by commits, which multiplied the work implied in keeping them to the point of dropping them (personal). This is trivially easy to do with bazaar or git, and I'm quite sure that darcs or mercurial will offer the same comfort level. At least for my development style, distributed SCM offers one order of magnitude more comfortable environment than centralized SCM. As for your concrete sentence, I'd say that if you need a technical tool as a framework to impose a work flow, then the work flow is possibly broken. If the work flow is sound, having a tool that eases the work won't break it. Regards Santiago (who was working to deliver this and more info on technical merits in the [EMAIL PROTECTED] thread) Thanks, Dw - 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: Subversion vs other source control systems
El jue, 14-02-2008 a las 10:52 +, William A. Rowe, Jr. escribió: Janne Jalkanen wrote: No, there was no vote and is not vote, nor is there any choice. Subversion is one of the few things that the Board has mandated, imposed on all projects. Period. Pretty much end of discussion. I would assume though that if there is enough interest among the community, the subject of supporting something like Git could be opened up with the Board, yes? It's up to the infrastructure team to decide, the board is generally hands-off when it comes to their decisions for the foundation. So it needs to be brought up to them. I'd say that if a project wants to have a distributed scm and makes a reasonable case of the reasons, they would ask for it to infrastructure. If infrastructure denies it and the project does not accept the reasoning or how it is exposed, we have a conflict. If there is a conflict the Board *has* to consider the issue. I'm not sure on how it is worded in the bylines. While we typically value consensus a lot, we typically don't take bureaucratic answers as absolutes. Or at least that is how I remember the ASF used to be. :P Also, while all users have http://people.apache.org/~userid/ , a git/bazaar/mercurial/darcs repo is only one scp away. I have set up cvs, subversion, git and bazaar, and the last two were vastly easier to set up and maintain. As I said, specially if ssh/sftp is there. The typical workflow in distributed scm is that authoritative repositories pull (as requested and after review) from non-official ones, so typically security is easier: no longer lots of people with write access, but only a handful, taking changesets from the rest of the community. Regards Santiago - 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: Subversion vs other source control systems
El jue, 14-02-2008 a las 14:32 +0100, Erik Abele escribió: On 14.02.2008, at 14:14, Santiago Gala wrote: ... The typical workflow in distributed scm is that authoritative repositories pull (as requested and after review) from non-official ones, so typically security is easier: no longer lots of people with write access, but only a handful, taking changesets from the rest of the community. Aye, and this is also the reason why it potentially conflicts with the meritocratic model of the ASF; furthermore there are also legal hurdles to cross etc. I can't see where are the legal or meritocratic problems, really. Specially the legal ones. A changeset is a changeset, whereas it is stored in subversion, several git repos or a patch in jira. I can agree that some experimentation is needed to refine the work flows and see how it works with our models, but denial will not help getting work done in this area. In the end I think it's simply too early to discuss all this - let's wait until some project comes up with a well-prepared and clearly defined proposal to change their SCM. IMHO this is certainly not a task for the Incubator or a podling... Neither is a task for the incubator PMC to freeze the new teams, and cut off the fresh air from the ASF. Raising an expectation that you *can* defy the powers-that-be here was my main aim in this whole thread. :) Cheers, Erik - 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: Subversion vs other source control systems
El jue, 14-02-2008 a las 14:45 +0100, Jochen Wiedmann escribió: On Thu, Feb 14, 2008 at 2:32 PM, Erik Abele [EMAIL PROTECTED] wrote: Aye, and this is also the reason why it potentially conflicts with the meritocratic model of the ASF; furthermore there are also legal hurdles to cross etc. In the end I think it's simply too early to discuss all this - let's wait until some project comes up with a well-prepared and clearly defined proposal to change their SCM. IMHO this is certainly not a task for the Incubator or a podling... Agreed. It's better to wait. Also note, that: - For obvious reasons, git and other distributed VC systems are more suited for larger projects with a real lot of contributors. Even in the case of the top level projects, there aren't too many that qualify for that. I don't see the obvious reasons, of course excepting much better performance of git. I mostly use bazaar for small projects, for instance put /etc of a group of servers under version control, and have the ability to commit remote configuration changes and then push to/pull from the remote server. I think the smaller management overhead of bazaar or git makes it easier than having to set up and protect svn server and repositories. - Even now, it is possible to work with git, if you want to: See http://mail-archives.apache.org/mod_mbox/maven-dev/200709.mbox/[EMAIL PROTECTED] I do not know how far Jason van Zyl's attempts have grown or not, He is making basically the same points I tried to make, and with a lot of enthusiasm too... I hope this will help convincing people to try any of the tools. but the point is that his intentions have been to gather experience. Anyone else is free to do the same. Well, I answered to Noel's: No, there was no vote and is not vote, nor is there any choice. Subversion is one of the few things that the Board has mandated, imposed on all projects. Period. Pretty much end of discussion. because he was clearly implying that no, nobody is free to do the same. Now at least I see that I'm not alone here. And hopefully people in podlings will see that we are a bit less uniform and bureaucratic than they were fearing. :) Regards Santiago Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept CouchDB for incubation
) === Cryptography === Not applicable === Required Resources === * Mailing lists: * couchdb-pmc for private PMC discussions (with moderated subscriptions) * couchdb-dev * couchdb-commits * couchdb-user * Subversion Directory: * https://svn.apache.org/repos/asf/incubator/couchdb * Issue Tracking: * JIRA couchdb === Initial Committers === * William Beh * Damien Katz * Jan Lehnardt * Christopher Lenz * Sam Ruby * Dirk Schalge * Noah Slater == Sponsors == === Champion === Sam Ruby [EMAIL PROTECTED] === Nominated Mentors === * Jim Jagielski * Gianugo Rabellino * Ted Leung === Sponsoring Entity === The Apache Incubator - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] as to Thrift Proposal
+1 El jue, 07-02-2008 a las 19:27 -0500, Ted Husted escribió: Here's my binding +1 on the Thrift proposal. On Jan 23, 2008 9:07 PM, Mark Slee [EMAIL PROTECTED] wrote: Hi all, We've just posted the Apache Incubator proposal for Thrift onto the Wiki: http://wiki.apache.org/incubator/ThriftProposal - 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] NoNameYet - Pluto
On Feb 4, 2008 7:24 AM, Stefan Hepper [EMAIL PROTECTED] wrote: I don't group all IBM'ers, really - I actually believe IBM'ers do tons of good in many open source projects. Also I think IBM itself is a somewhat good open source citizen in several regards. But it is not individuals that propose this particular project, as I understand it: it is IBM and BEA. And it was IBM that, in my view, dumped the JSR 168 RI and then fled - not any individuals as such. I don't agree with this, after the JSR 168 was final in Oct 2003 IBMers continued to work on the RI to get to the 1.0.1 release. I did still write comments and emails in 2004 / 2005. After 1.0.1 was finished a discussion in the community started to re-factor that code and create 1.1. It is true that the release of 1.1 took quite some time, but the discussions on the mailing list started quite soon after 1.0.1 was out AFAIR. Another thing to consider is that in order to really create a new version with new portlet features you need to have a new JSR. In in that case it took 2 years until V2.0 was started at the JCP. This is, in my opinion, what is actually killing the processes is: the need to have a JSR leading the way. This, together with the complicated mindset that java coding seems to promote nowadays. While the JSR crawls slowly to get a version out, much faster evolution for the same concepts is going on out of the JCP (which is, IMO, completely dead). I found the whole thing very frustrating. I think the JCP is mostly dragging software development nowadays. For a clear example on this, see how active portlet aggregation development is completely out of JSR-168/JSR-286 for Facebook, etc. and the whole OpenSocial initiative, which is the only area where I'm seeing real activity as opposed to maintenance. Regards Santiago I don't think Apache necessarily is the right place to dump a JSR RI and TCK implementation (because, lets face that, it isn't *developed* here) - it goes against the entire grain of Apache, AFAIU. Technically only the version that is submitted to the JCP is the RI, so in case of the Pluto it was the 1.0 code base from Oct 03. If you compare that version to the current 1.1 driver I think the project made a lot of progress in is much better usable now. This would have not occurred if you would just host the code drop without development. Also these development effort is now integrated into the new version 2.0. At least, if it is put here, then just don't pretend that it more than that either: It's just the RI and TCK implementations, staying at Apache as Apache are good guardians of code on a general basis. Thus, if it happens, this particular project's name shouldn't be anything fancy, probably not include the name Apache, maybe just be JSR-235 with two subfolders: RI and TCK. On the other side, some server implementing JSR-235 could be called Apache What-Ever, would run its own incubation, have its own infrastructure, possibly use the RI as a code starting point - but nothing more. This would keep the distinction very clear. The goals seems too different to mix. Endre. Stefan - 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] NoNameYet - Pluto
On Feb 4, 2008 4:54 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Roland Weber wrote: I think that is a bit oversimplified. IBM has strict rules about open source participation. It is either on private time, such as my involvement at Apache. Then the person is acting as an individual. Or it is on company time. Then the person is doing what he or she is paid for. And if IBM is changing it's priorities, or the line item that required OSS participation is closed, plenty of other work will be dumped on that person, simply leaving no (work) time for OSS participation. Yes, Apache attaches all merits to the individual. But you cannot reasonably expect individuals that got paid for working on an Apache project to continue their involvement at a comparable level on private time, nor judge them for retiring. The ultimate cause of reduced activity here would be the employer's decision, not the individual's. You are absolutely right... Perhaps we should force all initial committers to divulge if they are strictly involved in the effort as a work assignment, or if they have a broader interest in the new podling? And certainly, we should judge contributing corporations on their prior projects successes and failures, and this should be one of the many factors that go into the +/-1 decision of accepting a project. Not the only factor, but one of many. The failure of corporations to 'play nice with each other' is also one of those factors, if they are capable of participating in an open, transparent and collaborative development methodology required at and by the ASF. That said, we never judge people per-say for choosing to move on to some other projects or interest in their lives. The code is here for the public, and if the public can't be bothered to contribute, then it's simply shelved. No different than any commercial technology when a company looses interest in it. +1 I think the relevant issue for incubation efforts is wether there is a reasonable expectation that the current (dropped) code base will attract enough people from outside the donating company to graduate. I say reasonable expectation and not certainty, as incubation is a bet, and it can succeed or not. Once incubation is going on everything can happen, from success to withdrawal before graduation, passing through stagnation before or after graduation. Regards Santiago Bill - 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] Thrift
On Feb 2, 2008 2:48 PM, Leo Simons [EMAIL PROTECTED] wrote: On Feb 2, 2008, at 1:20 AM, David Reiss wrote: J Aaron Farr wrote: git could be an issue. Can you explain what the issue is with Git? Probably not very well :-). Basically, we know how to do the apache- style open source process using centralized version control, we don't quite know how to do it using (significantly) different version control models. That can (will?) change, but it probably can't change very quickly. Let me say in closing, though, that I don't want this issue to hold up the vote on Thrift. I think it's a good idea to treat it as a seperate topic. I think that everyone involved with the project thinks that Apache is the best place for it, and if the PMC says we have to use Subversion, we will. Cool. 1. You have to use subversion. Why? Has been a vote done? where? I vote +1 for git if a vote is still open. 2. You are cordially invited to engage within apache to see what we can do about modifying rule #1. Can you elaborate on what engage within apache means in this context? I have been engaged within apache for almost 8 years now, including membership and being an officer for some time, and yet I don't understand what engage with apache means. I don't even hope new people will. For #2, I can immediately imagine some ways to use git-svn that are quite acceptable. I can also imagine some things that are probably not so easily acceptable. I can imagine a BoF session at the next ApacheCon about it :-) This effectively means: you can use whatever you want, provided that it is subversion. But what concerns me most is that the Foundation is effectively turning into a bureaucracy, where norms appear out of nowhere without any justification. I see no mention to community reasons here, and any resource based reasons have tiny justification, specially when those are not even stated. Infrastructure used to be a support for the projects, not the other way around. While I understand some of the practical reasons stated in this thread, I don't understand the legalist note on it, neither the normative answers (who makes those norms?). The ASF used to be a loose community of projects, at least technically and codewise, and I think what SCM is used is a very important technical decision for project and community. BTW, I'm copying [EMAIL PROTECTED], in an effort to keep a mostly dead list going. Regards, Santiago cheers, - Leo, fan (but not active user) of git - 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: [DISCUSS] CouchDB incubator project
A big +1, I like the approach a lot. I can serve as a mentor if needed, even if I expect a fast incubation process for the project. I have been following it via Sam, and I have run the subversion code and got impressed on how simple the API is yet how powerful the concepts are. Regards Santiago On Feb 1, 2008 3:19 PM, Jim Jagielski [EMAIL PROTECTED] wrote: On Jan 31, 2008, at 10:40 AM, Sam Ruby wrote: The original source for this proposal can be found at http://www.couchdbwiki.com/index.php?title=Apache_Incubator_Proposal and a current snapshot is attached below. Once we have established that there is interest, my plan is to move this content over to wiki.apache.org/incubator as a [PROPOSAL]. I've been watching CouchDB since September, and believe that it would fit well in the ASF. My preference is that it exits as a top level project, mainly due to my experience with umbrella PMCs, but I would otherwise not be adverse to it joining the DB project. We certainly do not need to decide this now. ++1. I throw my hat in to Mentor if you still need people. - 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: Synchronizing PMC Membership rosters
El mar, 22-01-2008 a las 11:51 +, sebb escribió: On 22/01/2008, J Aaron Farr [EMAIL PROTECTED] wrote: sebb [EMAIL PROTECTED] writes: Just wondering whether Labs would be a suitable place to collaborate on scripts for cross-checking/reformatting the meta data? Also to document the current meta data. Technically the incubator PMC should be free to create a new subdirectory under /incubator in svn. But if you don't want to do that, then, yeah, a lab is fine. I was thinking that the same problems of duplicated meta data apply to other PMCs as well - indeed to the ASF as a whole... My experience in the past is that what happens is that someone writes a small script in her/his favorite scripting language and then people asks for it, improves, etc. A small scripts that would take a PMC or podling name and read committee-info, asf-authorization and report on inconsistencies would be a win, for starters. Even if it only runs by hand and the reports is pasted in an email. After something like this is running it can be further automated. Regards Santiago -- J Aaron Farr jadetower.com[US] +1 724-964-4515 馮傑仁 cubiclemuses.com [HK] +852 8123-7905 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Synchronizing PMC Membership rosters
El dom, 20-01-2008 a las 16:22 -0500, Noel J. Bergman escribió: As we all know, I just love redundant meta-data ... :-\ We have at least three lists for PMC Membership: 1) committee-info.txt 2) asf-authorization#incubator-pmc I am in none of the first two, even if I asked for it Nov 23th and was acknowledged by you, first, and wrowe in board@ Adding myself in both places (I have enough karma for it) Regards Santiago 3) [EMAIL PROTECTED] mailing lists subscriptions #1 and #2 should be equal, keyed by svn id. #3 should be a proper subset, with all members subscribed by e-mail address, and others (e.g., ASF Members or Directors who want to subscribe) present. I won't even get into incubator-info.txt, which is increasingly out-of-date and neglected. :-\ Didn't someone have a script for comparing the committee-info.txt roster against the asf-authorization lists? If so, would whomever it is please save me some time and run it against the current files, and post the results so that I can get them in synch. If not, I'll get to it manually. Similarly, do we have a script for comparing the roster and the mailing list subscriptions? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Synchronizing PMC Membership rosters
El lun, 21-01-2008 a las 22:32 +0100, Santiago Gala escribió: El dom, 20-01-2008 a las 16:22 -0500, Noel J. Bergman escribió: As we all know, I just love redundant meta-data ... :-\ We have at least three lists for PMC Membership: 1) committee-info.txt 2) asf-authorization#incubator-pmc I am in none of the first two, even if I asked for it Nov 23th and was acknowledged by you, first, and wrowe in board@ oops, I was just missing from asf-authorization, I added myself and removed one dupe of jvanzyl Adding myself in both places (I have enough karma for it) Regards Santiago 3) [EMAIL PROTECTED] mailing lists subscriptions #1 and #2 should be equal, keyed by svn id. #3 should be a proper subset, with all members subscribed by e-mail address, and others (e.g., ASF Members or Directors who want to subscribe) present. I won't even get into incubator-info.txt, which is increasingly out-of-date and neglected. :-\ Didn't someone have a script for comparing the committee-info.txt roster against the asf-authorization lists? If so, would whomever it is please save me some time and run it against the current files, and post the results so that I can get them in synch. If not, I'll get to it manually. Similarly, do we have a script for comparing the roster and the mailing list subscriptions? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala http://memojo.com/~sgala/blog/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Accept Shindig for Incubation
(Ning) Brian Stoler(Google) Cassie Doll (Google) Dan Bentley (Google) Dan Farino (MySpace) David Glazer(Google) David Harkness (Google) David Sklar (Ning) Doug Coker (Google) Evan Gilbert(Google) Graham Spencer (Google) Jeffrey Regan (Google) John Hjelmstad (Google) John Panzer (Google) Jun Yang(Google) Jussi Myllymaki (Google) Kevin Brown (Google) Martin Traverso (Ning) Paul Lindner(Hi5) Ramkumar Ramani (Google) Thomas Baker(Ning) Thomas Dudziak (Ning) Tim Williamson (Ning) Zhen Wang (Google) = Sponsors = == Champion == Brian McCallister == Nominated Mentors == Thomas Dudziak Brian Fitzpatrick Santiago Gala Greg Stein Upayavira Sylvain Wallez == Sponsoring Entity == The Apache Incubator. - 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: Anyone up for a docathon at ApacheCon Austin?
I won't be in the AC, unfortunately. Yesterday I was discussing with some people about using CAT in OS projects, and tools like omegat, and specially formats like TMX came to mind. One of the problems with manuals is that translating them (as an ongoing, changing work) becomes a lot of effort. If we could embed together all the local versions in an exchange format, the effort of tracking changes in the original, etc. would be smaller. So, taking a look into tools, and specially formats, for CAT, could pay a lot in the mmedium to long term. I'll try to keep involved in this discussion, even though I won't be physically there. my 2¢ (Euro cents, for those i18n handicapped) Santiago On 10/3/06, Justin Erenkrantz [EMAIL PROTECTED] wrote: On 10/2/06, Jean T. Anderson [EMAIL PROTECTED] wrote: I've been holding onto posts with good fodder for the incubator site, but haven't had time to incorporate them yet. I'll be at the hackathon on Tuesday Oct 10. Is anyone else up for a docathon? (Or did I miss a post already suggesting one? *chagrin*) My Tuesday is a bit booked ATM, but I'm game to try to squeeze in help on docs as my schedule permits. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Mentor and Project Guide (WAS: RE: [OT] How to prevent...)
El mar, 19-10-2004 a las 19:28 -0700, Cliff Schmidt escribi: (...) Cliff Schmidt wrote on Tuesday, October 19, 2004 7:23 PM: I gave a 45-minute presentation on Apache and the Incubator at the O'Reilly Open Source Convention last July. If it's any use, you can download the slides at: http://conferences.oreillynet.com/cs/os2004/view/e_sess/5439 (.ppt format -- if there's any interest I can convert to html or .pdf). No problem, OpenOffice.org opens .ppt better and faster than Powerpoint for OO.o version 1.1.1 :-P I cc: press@ as we were preparing a set of Slide shows (with the recent Beehive press round), and this one is usable (and translatable if the translator assumes responsibility on any error there) because it is ASL 2.0 NTW, I promised to translate them to Spanish, have them half way, but never committed because I'm not sure of which Repo or format we're using. This material is again great for global presentations of ASF entry points and interfaces. Regards -- Santiago Gala [EMAIL PROTECTED] High Sierra Technology, SLU signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Percentage of projects using Subversion was Re: Donation of JAXP 1.3 Sources to Apache
El mar, 19-10-2004 a las 11:40 -0700, Justin Erenkrantz escribi: --On Tuesday, October 19, 2004 1:56 PM -0400 Neil Graham [EMAIL PROTECTED] wrote: I'd also be curious to know what proportion of Apache projects have migrated to SVN so far? There would be a significantly higher amount of churn caused to the community by an SVN migration than was caused by our earlier Jira migration; so I'd prefer to go down a well-trod path than be on the bleeding edge in this particular instance. http://svn.apache.org/repos/asf/ A fair number of projects have already converted and a few more (such as httpd) have already agreed to convert, but are waiting for the 'right' time to convert. (My hunch is a bunch more might migrate at upcoming AC'04.) portals is half way. Jetspeed-1 will be converted after the next release, and Jetspeed-2 too. Site and pluto are already using svn. The only nit I have it I was never able to make subclipse work under linux-ppc, which is what I'm currently using. Not that I use eclipse that much, though. Ah!, and getting updatedb ignore the .svn trees would be nice too. Regards For more info, please see: http://www.apache.org/dev/cvs2svn.html HTH. -- justin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Santiago Gala [EMAIL PROTECTED] High Sierra Technology, SLU signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: eager to join ASF(Remoting technology in JAVA as in .NET)
Hello To All I am a soft engineer in China, I have known your foundation and used your projects for some years, I am eager to take part in the ASF. I had learnt the .NET framework.I compared it with Java, I find the .NET remoting technology is very powerful, but I can not find any technology instead of it in java. So I once attempt to implement the technology in java. Now I had made some headway,I am very happy. So I want to contribute it and expect somebody to perfect it with me. I think it is a good idea to let it become your incubator projects. but as you know, my English is poor, it is not easy to communicate with you. I try to learn the rules how can I join the ASF via your web site, but until now, I have not ravel it, I am crazy by my poor English. So I have to write the mail, I want your helps! If you are interested in it, please contact with me The best thing is to read the contribution guides of the different projects. You can start by sending patches, translating documents or reporting bugs in the projects that you are interested into. Then, when you get more familiar with the ASF procedures, you can be nominated committer. This is mostly how it goes. Regards Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pluto Graduation
Can anybody point me to what's missing for Pluto graduation? According to: http://incubator.apache.org/projects/pluto.html it seems that most steps (if not all) are already fulfilled. The Apache Portals project has voted to accept the project, unanimously, pluto committers included, which means 6 should change from jakarta-pluto to portals-pluto. I don't think jakarta would oppose, but a note there would be obviously done. The TBD in the page I posted are not obvious, and so I thought it would be better to ask here. Regards, Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Making Cocoon using Pluto [was: RE: Volunteering as a committer]
El jueves, 16 octu, 2003, a las 20:42 Europe/Madrid, David Sean Taylor escribió: Sounds great to me. Again Im +1 on Carsten and getting the Cocoon team involved and using Pluto. How many votes does Carsten have now? I counted 5. So Carsten Ziegler ([EMAIL PROTECTED]) should be given karma in pluto-dev. He is member of the ASF. I cannot send a pointer to the vote in nagoya because pluto lists are not being archived. I asked at infrastructure about one week ago. No answer yet. the mail directory for the mboxes is empty. They should be in gmane, though. BTW, we should have used a [VOTE] for the subject. I cc: infrastructure, for the karma and the list archival issue, incubator-general just in case, and jakarta-general, because our cvs repo is there. (Any more needed lists? ) :-P Regards Santiago - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
