Re: [Proposal] NoNameYet - Pluto
here my response to Endre's mail (http://mail-archives.apache.org/mod_mbox/incubator-general/200801.mbox/[EMAIL PROTECTED]): about Pluto V 1.x: Due to the JCP process guidelines at that time you could not have early public drafts and thus you are correct that the RI got to Apache very late. However, we discussed this with people from Apache and we also went through the incubation process. It would have always been an option to not accept the project. It is not true that after the JSR was final everything stopped. In fact once we had finished 1.0 there was still work done to get to a more stable 1.0.1 release. After that the pluto community re-structed the code which led to the pluto 1.1 stream, so you can see that it was an active community not only some code drop. Also in my view pluto was a success, take a look at all the projects using the pluto container: http://portals.apache.org/pluto/powered.html. about JSR 286/Pluto 2.0: Besides myself there are 4 people from Apache projects sitting in the JSR 286 EG and now that the JCP supports early public drafts we published early drafts more than a year ago and started the development of 2.0 directly at Apache. It is also based on the new 1.1 codestream that the Apache community created. I think you should also consider the view points of companies donating work and code to Apache. In my opinion it would have been much cheaper for IBM to just put the RI out there on some server instead of going to Apache. We went to Apache because we wanted the portlet standard to be widespread and easy to adopt by everyone. Regards, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] CouchDB incubator project
On Jan 31, 2008 3:44 PM, Martijn Dashorst [EMAIL PROTECTED] wrote: +1. How does the license of erlang (Erlang Public License, which is a Mozilla PL derivative) affect this project? If we don't bundle Erlang itself (and I presume that we will not), then not at all. After all, we have plenty of Java projects at the ASF which depend on a proprietary (at the time, and as of this writing, not yet released in an open source license) runtime. The fact that the Erlang Public License is a MPL derivative may, in fact, give us additional options, should we want to bundle it. Again, I don't presume that we will want to do that, but given the proper NOTICEs, inclusion of Erlang binaries may be a possibility. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] NoNameYet - Pluto
Stefan Thank you for you insights and response. Maybe the interesting question is whether you think - based on your experience - if is is really appropriate to try to create a JCP RI as an Apache incubator project? Paul On Feb 1, 2008 11:11 AM, Stefan Hepper [EMAIL PROTECTED] wrote: here my response to Endre's mail (http://mail-archives.apache.org/mod_mbox/incubator-general/200801.mbox/[EMAIL PROTECTED]): about Pluto V 1.x: Due to the JCP process guidelines at that time you could not have early public drafts and thus you are correct that the RI got to Apache very late. However, we discussed this with people from Apache and we also went through the incubation process. It would have always been an option to not accept the project. It is not true that after the JSR was final everything stopped. In fact once we had finished 1.0 there was still work done to get to a more stable 1.0.1 release. After that the pluto community re-structed the code which led to the pluto 1.1 stream, so you can see that it was an active community not only some code drop. Also in my view pluto was a success, take a look at all the projects using the pluto container: http://portals.apache.org/pluto/powered.html. about JSR 286/Pluto 2.0: Besides myself there are 4 people from Apache projects sitting in the JSR 286 EG and now that the JCP supports early public drafts we published early drafts more than a year ago and started the development of 2.0 directly at Apache. It is also based on the new 1.1 codestream that the Apache community created. I think you should also consider the view points of companies donating work and code to Apache. In my opinion it would have been much cheaper for IBM to just put the RI out there on some server instead of going to Apache. We went to Apache because we wanted the portlet standard to be widespread and easy to adopt by everyone. Regards, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] CouchDB incubator project
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]
Re: [VOTE] Accept PDFBox for incubation
Jukka Zitting wrote: Incubator PMC, Please vote on accepting the PDFBox project for incubation. The full PDFBox proposal is available at the end of this message and as a wiki page at http://wiki.apache.org/incubator/PDFBoxProposal. We ask the Incubator PMC to sponsor the PDFBox podling, with myself, Jeremias Maerki, and Niall Pemberton as the mentors. The vote is open for the next 72 hours and only votes from the Incubator PMC are binding. [X] +1 Accept PDFBox as a new podling [ ] -1 Do not accept the new podling (provide reason, please) +1 (non-binding). This is a great addition to the growing Apache text/unstructured stack. --Thilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept PDFBox for incubation
+1 On Feb 1, 2008 3:48 PM, Jeremias Maerki [EMAIL PROTECTED] wrote: +1 from me, obviously. On 01.02.2008 15:18:51 Jukka Zitting wrote: Incubator PMC, Please vote on accepting the PDFBox project for incubation. The full PDFBox proposal is available at the end of this message and as a wiki page at http://wiki.apache.org/incubator/PDFBoxProposal. We ask the Incubator PMC to sponsor the PDFBox podling, with myself, Jeremias Maerki, and Niall Pemberton as the mentors. The vote is open for the next 72 hours and only votes from the Incubator PMC are binding. [X] +1 Accept PDFBox as a new podling [ ] -1 Do not accept the new podling (provide reason, please) Here's my +1 BR, Jukka Zitting snip/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept PDFBox for incubation
+1 from me, obviously. On 01.02.2008 15:18:51 Jukka Zitting wrote: Incubator PMC, Please vote on accepting the PDFBox project for incubation. The full PDFBox proposal is available at the end of this message and as a wiki page at http://wiki.apache.org/incubator/PDFBoxProposal. We ask the Incubator PMC to sponsor the PDFBox podling, with myself, Jeremias Maerki, and Niall Pemberton as the mentors. The vote is open for the next 72 hours and only votes from the Incubator PMC are binding. [X] +1 Accept PDFBox as a new podling [ ] -1 Do not accept the new podling (provide reason, please) Here's my +1 BR, Jukka Zitting snip/ Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept PDFBox for incubation
Jukka Seems like a clear proposal with all the right thinking behind it. +1. Paul On Feb 1, 2008 2:18 PM, Jukka Zitting [EMAIL PROTECTED] wrote: Incubator PMC, Please vote on accepting the PDFBox project for incubation. The full PDFBox proposal is available at the end of this message and as a wiki page at http://wiki.apache.org/incubator/PDFBoxProposal. We ask the Incubator PMC to sponsor the PDFBox podling, with myself, Jeremias Maerki, and Niall Pemberton as the mentors. The vote is open for the next 72 hours and only votes from the Incubator PMC are binding. [ ] +1 Accept PDFBox as a new podling [ ] -1 Do not accept the new podling (provide reason, please) Here's my +1 BR, Jukka Zitting = PDFBox = === Abstract === PDFBox is an open source Java PDF library for working with PDF documents. === Proposal === The PDFBox library allows creation of new PDF documents, manipulation of existing documents and the ability to extract content from documents. PDFBox also includes several command line utilities. Future development plans include extending PDFBox with advanced data extraction and high level PDF creation functionality. In addition to PDFBox, this proposal also covers the !FontBox and !JempBox companion libraries. !FontBox is a Java font library used to obtain low level information from font files. !JempBox is a Java library that implements Adobe's XMP specification. All these components would be incubated as a single Apache PDFBox podling project. === Background === The PDFBox project started in 2002 and was originally written by Ben Litchfield in 2002 and currently lives on SourceForge. The initial purpose of PDFBox was to extract text content to be indexed by the Lucene search engine. In addition to text extraction the library also supports a low level API for PDF creation and manipulation. In the past, several developers have helped develop specific features in PDFBox but none have continued once their specific needs where met. In 2006 discussions began with the FOP team to collaborate on a single PDF library within the Apache organization. New projects have expressed interest in advancing the functionality of PDFBox. Recently, Tika also expressed interest in advancing the content extraction capabilities of PDFBox. The !FontBox and !JempBox libraries have no dependencies to PDFBox, but their primary purpose is to support PDFBox and the development community is largely overlapping. It makes sense to include all three libraries in a single project. === Rationale === The PDF document format is a common format found on internet and across industries as a way of sharing documents. Several Apache projects utilize PDF technologies but there is not a single independent PDF library within the Apache organization. The Apache XML Graphics project (FOP/Batik) has a write-only PDF library and is in need of PDF parsing functionality. Many features overlap those of PDFBox. This is currently a duplication of effort, bringing PDFBox into Apache and combining our efforts will result in a more robust PDF library that will be able to support many more use cases for working with PDF technologies. !FontBox, FOP and Batik all contain font loading/handling code that could likely be merged into a single common library either within the PDFBox podling or outside it. === Initial Goals === The initial goals are: * Advanced text extraction techniques * Increase community involvement * Cooperation with existing Apache projects such as XML Graphics * Increasing support for PDF document features * Adding a high level API for document creation * Adding a streaming API for document creation * PDF/A creation and validation functionality * Review licensing of both bundled and external dependencies * Manage export control notices for cryptographic features * Figure out how to handle font handling code across !FontBox, FOP, and Batik * Replace !JempBox with Adobe's XMP library == Current Status == === Meritocracy === Not all initial committers are familiar with the meritocracy principles of Apache. It is expected that the committers that are not will learn the meritocracy rules and they will be followed through the life of the project. === Community === PDFBox has existed for several years on SourceForge and has an active community and continues to grow each day. There are hundreds of existing projects that utilize the current version of PDFBox. === Core Developers === Ben Litchfield is the main developer on this project although it is expected that developers from a variety of existing Apache projects will become part of the team. === Alignment === The ability to search PDF documents is a basic requirement for any enterprise search solution. PDFBox provides the basic content that is needed for content indexing. This functionality aligns with the those of Lucene,
Re: Automated Release Audit Reports [Re: Release Audit Report 2008-01-29]
On Jan 31, 2008 12:15 AM, Erik Abele [EMAIL PROTECTED] wrote: On 30.01.2008, at 21:29, Robert Burrell Donkin wrote: snip An overview page linking to all the previous reports (ok, autoindex works too but isn't as nice)...? the scripts that generate the sitemap for the infrastructure site will probably do the job. (i've been meaning to port them over here so that a sitemap can be generated anyway.) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept PDFBox for incubation
On Feb 1, 2008 3:18 PM, Jukka Zitting [EMAIL PROTECTED] wrote: Please vote on accepting the PDFBox project for incubation +1, I'm glad to see this coming here! -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept PDFBox for incubation
+1 Niall On Feb 1, 2008 2:18 PM, Jukka Zitting [EMAIL PROTECTED] wrote: Incubator PMC, Please vote on accepting the PDFBox project for incubation. The full PDFBox proposal is available at the end of this message and as a wiki page at http://wiki.apache.org/incubator/PDFBoxProposal. We ask the Incubator PMC to sponsor the PDFBox podling, with myself, Jeremias Maerki, and Niall Pemberton as the mentors. The vote is open for the next 72 hours and only votes from the Incubator PMC are binding. [ ] +1 Accept PDFBox as a new podling [ ] -1 Do not accept the new podling (provide reason, please) Here's my +1 BR, Jukka Zitting = PDFBox = === Abstract === PDFBox is an open source Java PDF library for working with PDF documents. === Proposal === The PDFBox library allows creation of new PDF documents, manipulation of existing documents and the ability to extract content from documents. PDFBox also includes several command line utilities. Future development plans include extending PDFBox with advanced data extraction and high level PDF creation functionality. In addition to PDFBox, this proposal also covers the !FontBox and !JempBox companion libraries. !FontBox is a Java font library used to obtain low level information from font files. !JempBox is a Java library that implements Adobe's XMP specification. All these components would be incubated as a single Apache PDFBox podling project. === Background === The PDFBox project started in 2002 and was originally written by Ben Litchfield in 2002 and currently lives on SourceForge. The initial purpose of PDFBox was to extract text content to be indexed by the Lucene search engine. In addition to text extraction the library also supports a low level API for PDF creation and manipulation. In the past, several developers have helped develop specific features in PDFBox but none have continued once their specific needs where met. In 2006 discussions began with the FOP team to collaborate on a single PDF library within the Apache organization. New projects have expressed interest in advancing the functionality of PDFBox. Recently, Tika also expressed interest in advancing the content extraction capabilities of PDFBox. The !FontBox and !JempBox libraries have no dependencies to PDFBox, but their primary purpose is to support PDFBox and the development community is largely overlapping. It makes sense to include all three libraries in a single project. === Rationale === The PDF document format is a common format found on internet and across industries as a way of sharing documents. Several Apache projects utilize PDF technologies but there is not a single independent PDF library within the Apache organization. The Apache XML Graphics project (FOP/Batik) has a write-only PDF library and is in need of PDF parsing functionality. Many features overlap those of PDFBox. This is currently a duplication of effort, bringing PDFBox into Apache and combining our efforts will result in a more robust PDF library that will be able to support many more use cases for working with PDF technologies. !FontBox, FOP and Batik all contain font loading/handling code that could likely be merged into a single common library either within the PDFBox podling or outside it. === Initial Goals === The initial goals are: * Advanced text extraction techniques * Increase community involvement * Cooperation with existing Apache projects such as XML Graphics * Increasing support for PDF document features * Adding a high level API for document creation * Adding a streaming API for document creation * PDF/A creation and validation functionality * Review licensing of both bundled and external dependencies * Manage export control notices for cryptographic features * Figure out how to handle font handling code across !FontBox, FOP, and Batik * Replace !JempBox with Adobe's XMP library == Current Status == === Meritocracy === Not all initial committers are familiar with the meritocracy principles of Apache. It is expected that the committers that are not will learn the meritocracy rules and they will be followed through the life of the project. === Community === PDFBox has existed for several years on SourceForge and has an active community and continues to grow each day. There are hundreds of existing projects that utilize the current version of PDFBox. === Core Developers === Ben Litchfield is the main developer on this project although it is expected that developers from a variety of existing Apache projects will become part of the team. === Alignment === The ability to search PDF documents is a basic requirement for any enterprise search solution. PDFBox provides the basic content that is needed for content indexing. This functionality aligns with the those of Lucene, Nutch, Tika and UIMA and all users of these projects will benefit from
Re: Automated Release Audit Reports [Re: Release Audit Report 2008-01-29]
On Jan 31, 2008 12:15 AM, Erik Abele [EMAIL PROTECTED] wrote: On 30.01.2008, at 21:29, Robert Burrell Donkin wrote: you probably have noticed a number of emailed audit reports (see below). i've been doing some testing (apologies for the SPAM) but think that everything's working ok now. 1. frequency: weekly? biweekly? monthly? Maximum one per week I'd say; bi-weekly is also fine but monthly is probably too rare. snip i'll try to run the scripts once a week but will alter the scripts so that they only mail if there have been changes Maybe make also sure to not send anything if there's nothing to report... (I know it's useful to see that it's still there and still working but we don't need to spam the whole list then.) bit worried that without any feedback when the script thinks that there are no changes, no one will notice if the scripts misses changes or isn't run for a while. probably good enough to limit a 'no changes' mail to once a month. in this case, the summary should indicate that there are no changes. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Accept PDFBox for incubation
Incubator PMC, Please vote on accepting the PDFBox project for incubation. The full PDFBox proposal is available at the end of this message and as a wiki page at http://wiki.apache.org/incubator/PDFBoxProposal. We ask the Incubator PMC to sponsor the PDFBox podling, with myself, Jeremias Maerki, and Niall Pemberton as the mentors. The vote is open for the next 72 hours and only votes from the Incubator PMC are binding. [ ] +1 Accept PDFBox as a new podling [ ] -1 Do not accept the new podling (provide reason, please) Here's my +1 BR, Jukka Zitting = PDFBox = === Abstract === PDFBox is an open source Java PDF library for working with PDF documents. === Proposal === The PDFBox library allows creation of new PDF documents, manipulation of existing documents and the ability to extract content from documents. PDFBox also includes several command line utilities. Future development plans include extending PDFBox with advanced data extraction and high level PDF creation functionality. In addition to PDFBox, this proposal also covers the !FontBox and !JempBox companion libraries. !FontBox is a Java font library used to obtain low level information from font files. !JempBox is a Java library that implements Adobe's XMP specification. All these components would be incubated as a single Apache PDFBox podling project. === Background === The PDFBox project started in 2002 and was originally written by Ben Litchfield in 2002 and currently lives on SourceForge. The initial purpose of PDFBox was to extract text content to be indexed by the Lucene search engine. In addition to text extraction the library also supports a low level API for PDF creation and manipulation. In the past, several developers have helped develop specific features in PDFBox but none have continued once their specific needs where met. In 2006 discussions began with the FOP team to collaborate on a single PDF library within the Apache organization. New projects have expressed interest in advancing the functionality of PDFBox. Recently, Tika also expressed interest in advancing the content extraction capabilities of PDFBox. The !FontBox and !JempBox libraries have no dependencies to PDFBox, but their primary purpose is to support PDFBox and the development community is largely overlapping. It makes sense to include all three libraries in a single project. === Rationale === The PDF document format is a common format found on internet and across industries as a way of sharing documents. Several Apache projects utilize PDF technologies but there is not a single independent PDF library within the Apache organization. The Apache XML Graphics project (FOP/Batik) has a write-only PDF library and is in need of PDF parsing functionality. Many features overlap those of PDFBox. This is currently a duplication of effort, bringing PDFBox into Apache and combining our efforts will result in a more robust PDF library that will be able to support many more use cases for working with PDF technologies. !FontBox, FOP and Batik all contain font loading/handling code that could likely be merged into a single common library either within the PDFBox podling or outside it. === Initial Goals === The initial goals are: * Advanced text extraction techniques * Increase community involvement * Cooperation with existing Apache projects such as XML Graphics * Increasing support for PDF document features * Adding a high level API for document creation * Adding a streaming API for document creation * PDF/A creation and validation functionality * Review licensing of both bundled and external dependencies * Manage export control notices for cryptographic features * Figure out how to handle font handling code across !FontBox, FOP, and Batik * Replace !JempBox with Adobe's XMP library == Current Status == === Meritocracy === Not all initial committers are familiar with the meritocracy principles of Apache. It is expected that the committers that are not will learn the meritocracy rules and they will be followed through the life of the project. === Community === PDFBox has existed for several years on SourceForge and has an active community and continues to grow each day. There are hundreds of existing projects that utilize the current version of PDFBox. === Core Developers === Ben Litchfield is the main developer on this project although it is expected that developers from a variety of existing Apache projects will become part of the team. === Alignment === The ability to search PDF documents is a basic requirement for any enterprise search solution. PDFBox provides the basic content that is needed for content indexing. This functionality aligns with the those of Lucene, Nutch, Tika and UIMA and all users of these projects will benefit from continued development of PDFBox. PDFBox shares similar font loading and handling needs as FOP and Batik, and the code in the !FontBox companion library could well be merged
Re: Automated Release Audit Reports [Re: Release Audit Report 2008-01-29]
On Jan 30, 2008 10:37 PM, Jukka Zitting [EMAIL PROTECTED] wrote: snip 3. web page: too concise? too verbose? Please include checksums or signatures of the release packages. That way we'll have easier time tracking things if the release artifacts change for one reason or another. the raw data is already stored and signed in subversion but the format is custom xml. if i switch to using xhtml+microformat then the raw data will be more easily accessible (and yes, i have been reading restful web services recently). i should be able to add links to the various sums the audit computes. Also, as a general after-the-fact audit, it would be great if the tool could do some basic release checks and include the results in the report. For example verify that all the checksums and signatures included in the dist directory are correct. henk's scanner already checks signatures and sums but he only posts to the podling list. he also has some good proposals for hierarchical signature protection. but unless someone volunteers, this will have to wait until RAT is working more completely later this year It would be even cooler if there was some way (perhaps with explicit release metadata) that would link the reported release artifacts to the related vote threads. would be good but not sure how to do it (quickly). any ideas - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] NoNameYet - Pluto
Stefan Hepper wrote: It is not true that after the JSR was final everything stopped. In fact once we had finished 1.0 there was still work done to get to a more stable 1.0.1 release. After that the pluto community re-structed the code which led to the pluto 1.1 stream, so you can see that it was an active community not only some code drop. I mentioned this. JSR 168 itself was Final Release on 27 Oct, 2003. Wading through the repository: The first entry of Pluto in Subversion is Tue Sep 30 14:03:01 2003 (cvs2svn import). Pluto 1.0.1-RC1 was tagged Thu Oct 7 09:25:40 2004. Pluto 1.0.1-RC4 was tagged Mon Jul 25 01:06:54 2005. Pluto 1.0.1 was ReTagged Mon Oct 10 18:29:33 2005. 1.0.1, the first minor-revision above the inital code drop, being a fix of the most crazy bugs, was tagged more than two years after the inital code drop. Pluto 1.1.0 was tagged [maven-scm] copy for tag pluto-1.1.0 Sun Feb 11 17:29:23 2007. 1.1.0 was, IIRC, a larger refactor to make the code somewhat more embeddable. If the tags don't lie, the 1.1.0 came out less than a year ago, 3 years and 4 months after the initial drop. This time period isn't really extreme in itself, but compared to the developer activity on a project that literally screamed for help, it becomes sad. The following fact I'm not _quite_ certain of, and it takes a bit too much time to search the archives to prove it (this isn't exactly some court), but I do believe I have my words intact if I state that there wasn't much involvement in any of those versions after the initial dump to come from any of you IBM folks. Repos and mailing list archives are available. And for my comments of code quality - I might be wrong, I might be a nit-picker, or I might just be a bad coder - but the initial drop and all the versions are still there in the repository: have a look-see. There might be some tools better than ViewVC to run through the repository and mailing lists to get a better picture of these facts. But AFAIK, and I've been lurking lots (due to the fact that I had interests in a embeddable standards compliant container at the time), Pluto has *never* had much of an active community. I believe most of the 1.1.0 was done by one man. Had the initial code been of quite a bit better quality, or had it had quite a bit more backing from the droppers to bootstrap any community, it had at least had ONE more active developer, that I can guarantee. I tried, but I could just not start anywhere with that code, and I could not start doing a complete rewrite of that dump on my own (I'd actually rather start from scratch, to be honest). Also in my view pluto was a success, take a look at all the projects using the pluto container: http://portals.apache.org/pluto/powered.html. Compared to the amount of portals, this isn't exactly amazing. That IBM doesn't use it itself (I belive?), an Apache product which they themselves created, is quite telling, compared to the fact that IBM isn't exactly shy of using lots of other Apache products in their products and services. Endre. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tuscany Java SCA Release 1.1-incubating and new Incubator distribution policy
Hi The Tuscany project is now ready to distribute its Java SCA Release 1.1-incubating. Following up from Robert's recent post to the Tuscany dev list [1] I am posting here before proceeding to copy the artifacts up to www.apache.org/dist/incubator. The proposal it to use a similar release structure to the one we already use [2] tuscany/ native/ java/ das/ sca/ 1.1-incubating/ release artifacts here sdo/ Please advise Thanks Simon [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg26970.html [2] http://archive.apache.org/dist/incubator/tuscany/
Re: [VOTE] Accept PDFBox for incubation
[X] +1 Accept PDFBox as a new podling A must have ! -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept PDFBox for incubation
+1 On 2/1/08, Jukka Zitting [EMAIL PROTECTED] wrote: Incubator PMC, Please vote on accepting the PDFBox project for incubation. The full PDFBox proposal is available at the end of this message and as a wiki page at http://wiki.apache.org/incubator/PDFBoxProposal. We ask the Incubator PMC to sponsor the PDFBox podling, with myself, Jeremias Maerki, and Niall Pemberton as the mentors. The vote is open for the next 72 hours and only votes from the Incubator PMC are binding. [ ] +1 Accept PDFBox as a new podling [ ] -1 Do not accept the new podling (provide reason, please) Here's my +1 BR, Jukka Zitting = PDFBox = === Abstract === PDFBox is an open source Java PDF library for working with PDF documents. === Proposal === The PDFBox library allows creation of new PDF documents, manipulation of existing documents and the ability to extract content from documents. PDFBox also includes several command line utilities. Future development plans include extending PDFBox with advanced data extraction and high level PDF creation functionality. In addition to PDFBox, this proposal also covers the !FontBox and !JempBox companion libraries. !FontBox is a Java font library used to obtain low level information from font files. !JempBox is a Java library that implements Adobe's XMP specification. All these components would be incubated as a single Apache PDFBox podling project. === Background === The PDFBox project started in 2002 and was originally written by Ben Litchfield in 2002 and currently lives on SourceForge. The initial purpose of PDFBox was to extract text content to be indexed by the Lucene search engine. In addition to text extraction the library also supports a low level API for PDF creation and manipulation. In the past, several developers have helped develop specific features in PDFBox but none have continued once their specific needs where met. In 2006 discussions began with the FOP team to collaborate on a single PDF library within the Apache organization. New projects have expressed interest in advancing the functionality of PDFBox. Recently, Tika also expressed interest in advancing the content extraction capabilities of PDFBox. The !FontBox and !JempBox libraries have no dependencies to PDFBox, but their primary purpose is to support PDFBox and the development community is largely overlapping. It makes sense to include all three libraries in a single project. === Rationale === The PDF document format is a common format found on internet and across industries as a way of sharing documents. Several Apache projects utilize PDF technologies but there is not a single independent PDF library within the Apache organization. The Apache XML Graphics project (FOP/Batik) has a write-only PDF library and is in need of PDF parsing functionality. Many features overlap those of PDFBox. This is currently a duplication of effort, bringing PDFBox into Apache and combining our efforts will result in a more robust PDF library that will be able to support many more use cases for working with PDF technologies. !FontBox, FOP and Batik all contain font loading/handling code that could likely be merged into a single common library either within the PDFBox podling or outside it. === Initial Goals === The initial goals are: * Advanced text extraction techniques * Increase community involvement * Cooperation with existing Apache projects such as XML Graphics * Increasing support for PDF document features * Adding a high level API for document creation * Adding a streaming API for document creation * PDF/A creation and validation functionality * Review licensing of both bundled and external dependencies * Manage export control notices for cryptographic features * Figure out how to handle font handling code across !FontBox, FOP, and Batik * Replace !JempBox with Adobe's XMP library == Current Status == === Meritocracy === Not all initial committers are familiar with the meritocracy principles of Apache. It is expected that the committers that are not will learn the meritocracy rules and they will be followed through the life of the project. === Community === PDFBox has existed for several years on SourceForge and has an active community and continues to grow each day. There are hundreds of existing projects that utilize the current version of PDFBox. === Core Developers === Ben Litchfield is the main developer on this project although it is expected that developers from a variety of existing Apache projects will become part of the team. === Alignment === The ability to search PDF documents is a basic requirement for any enterprise search solution. PDFBox provides the basic content that is needed for content indexing. This functionality aligns with the those of Lucene, Nutch, Tika and UIMA and all users of these projects will benefit from continued development of
Re: [VOTE] Accept PDFBox for incubation
Jukka Zitting schrieb: Incubator PMC, Please vote on accepting the PDFBox project for incubation. The full PDFBox proposal is available at the end of this message and as a wiki +1 Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Thrift] RE: [PROPOSAL] Thrift
On Jan 30, 2008, at 5:55 AM, Upayavira wrote: As you can see from other proposals, I think you'll find it work better with a single committer pool. As others have said, I personally have never seen a problem with this approach - people steer away from code that they are unfamiliar with, or tend to ask permission before wandering that way. So, so while separating committerships might sound useful, I don't think it is really necessary. ++1... In fact, I would almost consider this a deal-breaker for incubation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] i18n4data Proposal
Neng Geng Huang wrote: Currently I cannot find any sponsors for this project, so if anyone reading this message would like to get on board, it will be really appreciated. I am not a sponsor/mentor, but I would be interested in participating. I ran into this issue before, when working on this [1]. My main problem was how to i18n a dropdown menu. Resource Bundles did not allow you to store multiple values per key, and they did not have a reverse lookup, i.e. from french value to key. The solution that I was going to work on, was to move the messages from ResourceBundles to a database table. Is this a similar approach? [1] - Business Application Framework. http://mail-archives.apache.org/mod_mbox/incubator-general/200801.mbox/[EMAIL PROTECTED] Regards, Ahmad - 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]
Pig and Hadoop - Yahoo Folks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Yahoo Folks, Hang in there and keep us updated... - -- dims -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFHo2vigNg6eWEDv1kRAlt4AJ9vuZQqbR9x8j23yPHl2tOJIj1ZyACfQTVb hRtLR+n0f2e15Ay423ihKsY= =Cv/t -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] NoNameYet : Link Error - please use this link
On Feb 1, 2008 10:04 AM, Simon Nash [EMAIL PROTECTED] wrote: Paul Fremantle wrote: Kelvin, NoNameProposers Maybe no-one has responded yet because no-one wants to ask the hard questions! So here I go: Perhaps you can explain why this effort isn't being rolled into the Tuscany work. There are some obvious reasons why I am confused by this proposal: 1. Tuscany already has the objective of producing code for SDO, and already has code for SDO. 2. Tuscany was another proposal to the IPMC predominantly coming from IBM and BEA employees. 3. The BEA committers left Tuscany and created a fork elsewhere 3. Tuscany has been identified as lacking diversity. Why will this project gain diversity when Tuscany is finding it hard? This move seems designed to make it even harder for both Tuscany and NNYP to get diversity by splitting the pool of potential committers even more thinly. I did read the paragraph on the relationship to Tuscany but I'm afraid I came out more confused. I'm sure there are more hard questions but I think that's enough to be going on with. I'll jump in on the points related to Tuscany. I don't think this new incubator would necessarily harm Tuscany's diversity. If it broadens the open source community around SDO, there will more people interested in SDO and they may get involved in Tuscany to improve Tuscany's SCA support for SDO (as well as the many other databindings that Tuscany SCA provides). I think it's good for this work to be done in an open community rather than as an in-house collaboration between vendors. I'm not sure why the points about the history of IBM and BEA's involvement in Tuscany are being raised. The facts as stated are correct, and I'm sure the IBM and BEA people putting forward this proposal are well aware of them. If they have decided that they are willing to work together on this project and open it to a broader community, I see this as something positive that should be encouraged. And what about bringing this in Tuscany instead of creating another podling? Seems that the goals are similar enough to have a single project driving the effort and it would probably greatly improve cross-pollination. Cheers, Matthieu Simon Regards, Paul On Jan 31, 2008 9:47 AM, kelvin goodson [EMAIL PROTECTED] wrote: http://wiki.apache.org/incubator/NoNameYetProposal That's what you get for employing reuse tactics -- gmail remembers the original URL. I've been caught by this before, so I thought I had taken appropriate action to avoid this behaviour, but sadly not so, apologies. Kelvin On 31/01/2008, kelvin goodson [EMAIL PROTECTED] wrote: Hi all, We've posted an Apache Incubator proposal onto the incubator wiki http://wiki.apache.org/incubator/NoNameYetProposal We haven't got a good name yet, SandStorm is a contender, as is Snowdon Suggestions and comments welcome, Kelvin. http://wiki.apache.org/incubator/ThriftProposal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] NoNameYet : Link Error - please use this link
On Fri, 2008-02-01 at 12:37 -0800, Matthieu Riou wrote: On Feb 1, 2008 10:04 AM, Simon Nash [EMAIL PROTECTED] wrote: Paul Fremantle wrote: Kelvin, NoNameProposers Maybe no-one has responded yet because no-one wants to ask the hard questions! So here I go: Perhaps you can explain why this effort isn't being rolled into the Tuscany work. There are some obvious reasons why I am confused by this proposal: 1. Tuscany already has the objective of producing code for SDO, and already has code for SDO. 2. Tuscany was another proposal to the IPMC predominantly coming from IBM and BEA employees. 3. The BEA committers left Tuscany and created a fork elsewhere 3. Tuscany has been identified as lacking diversity. Why will this project gain diversity when Tuscany is finding it hard? This move seems designed to make it even harder for both Tuscany and NNYP to get diversity by splitting the pool of potential committers even more thinly. I did read the paragraph on the relationship to Tuscany but I'm afraid I came out more confused. I'm sure there are more hard questions but I think that's enough to be going on with. I'll jump in on the points related to Tuscany. I don't think this new incubator would necessarily harm Tuscany's diversity. If it broadens the open source community around SDO, there will more people interested in SDO and they may get involved in Tuscany to improve Tuscany's SCA support for SDO (as well as the many other databindings that Tuscany SCA provides). I think it's good for this work to be done in an open community rather than as an in-house collaboration between vendors. I'm not sure why the points about the history of IBM and BEA's involvement in Tuscany are being raised. The facts as stated are correct, and I'm sure the IBM and BEA people putting forward this proposal are well aware of them. If they have decided that they are willing to work together on this project and open it to a broader community, I see this as something positive that should be encouraged. And what about bringing this in Tuscany instead of creating another podling? Seems that the goals are similar enough to have a single project driving the effort and it would probably greatly improve cross-pollination. I haven't followed this thread at all, so I could be off-base, but surely it would need to become a podling, even if its destination were a subproject of Tuscany? Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] NoNameYet : Link Error - please use this link
On Feb 1, 2008 1:15 PM, Upayavira [EMAIL PROTECTED] wrote: On Fri, 2008-02-01 at 12:37 -0800, Matthieu Riou wrote: On Feb 1, 2008 10:04 AM, Simon Nash [EMAIL PROTECTED] wrote: Paul Fremantle wrote: Kelvin, NoNameProposers Maybe no-one has responded yet because no-one wants to ask the hard questions! So here I go: Perhaps you can explain why this effort isn't being rolled into the Tuscany work. There are some obvious reasons why I am confused by this proposal: 1. Tuscany already has the objective of producing code for SDO, and already has code for SDO. 2. Tuscany was another proposal to the IPMC predominantly coming from IBM and BEA employees. 3. The BEA committers left Tuscany and created a fork elsewhere 3. Tuscany has been identified as lacking diversity. Why will this project gain diversity when Tuscany is finding it hard? This move seems designed to make it even harder for both Tuscany and NNYP to get diversity by splitting the pool of potential committers even more thinly. I did read the paragraph on the relationship to Tuscany but I'm afraid I came out more confused. I'm sure there are more hard questions but I think that's enough to be going on with. I'll jump in on the points related to Tuscany. I don't think this new incubator would necessarily harm Tuscany's diversity. If it broadens the open source community around SDO, there will more people interested in SDO and they may get involved in Tuscany to improve Tuscany's SCA support for SDO (as well as the many other databindings that Tuscany SCA provides). I think it's good for this work to be done in an open community rather than as an in-house collaboration between vendors. I'm not sure why the points about the history of IBM and BEA's involvement in Tuscany are being raised. The facts as stated are correct, and I'm sure the IBM and BEA people putting forward this proposal are well aware of them. If they have decided that they are willing to work together on this project and open it to a broader community, I see this as something positive that should be encouraged. And what about bringing this in Tuscany instead of creating another podling? Seems that the goals are similar enough to have a single project driving the effort and it would probably greatly improve cross-pollination. I haven't followed this thread at all, so I could be off-base, but surely it would need to become a podling, even if its destination were a subproject of Tuscany? Nor necessarily. I'm pretty sure we've had additional code granted to an existing podling before. I can actually think of at least 2 past occurrences. Matthieu Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: [PROPOSAL] Thrift
Following up on what David sent out yesterday, I think we're all on board with having a single committers pool based upon mutual trust and respect. However, dropping parts of the code feels counterproductive to me, as I think it might put up a perceived barrier to collaboration with the Thrift project. Alternate language bindings were one of the main things we were really hoping to see come from the open source community, and we'd like to make sure this continues to be a really approachable thing. We wouldn't want developers to feel like their changes to Thrift won't be accepted without an up front investment of time building reputation in the Thrift community. I think reverting and reapplying these changes creates another risk. Developers would have incentive to keep some language-specific changes to themselves and not share them, simply because it would be more efficient, not because they are philosophically opposed to open source or sharing their changes at all. And to be quite frank, it feels very counterproductive to me to remove code from the project with full a priori intention of putting it back in. We'd rather focus on keeping development open and moving forwards. Removing people's code from the project could send an insulting and negative message. Cheers, Mark -Original Message- From: Martijn Dashorst [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 30, 2008 10:39 AM To: general@incubator.apache.org Subject: Re: Re: [PROPOSAL] Thrift Perhaps in the interest of code audit (which needs to be done) and community building, the code parts of the missing committers should be removed from the code drop prior to incubation start, and be re-introduced inside the incubating podling by providing patches through bugzilla? Martijn On 1/30/08, David Reiss [EMAIL PROTECTED] wrote: If there are people who have already proven their *merit* on the project that are not included on the initial list of committers then I think they should be. In reality, many parts of the Thrift code base are already entirely owned by non-Facebook entities. The Cocoa, C#, Perl, and Smalltalk implementations for Thrift were all developed entirely outside of Facebook, and although Facebook still maintains the trunk, we defer review of all these patches to the developers working on those libraries. So are these people on the initial list of committers? Perl was contributed by Jake Luciani, who is a committer, but the developers of the Cocoa, C#, and Smalltalk bindings are not. These bindings were submitted as a set of a few patches (or in some cases, even a single large patch), and added to the tree without extensive review because, quite frankly, no committers were qualified to review them. Because, as far as we know, the original contributors are the only users of these bindings, we've just been blindly committing any changes they make, so it would make sense for them to have commit access to their parts of the project. However, they have not been active enough in the Thrift community to warrant the trust that comes with full commit access. I would say that the requirements for a language-binding contributor to become a committer would be some amount of activity on the mailing list and either a significant review of the binding by a qualified committer or a significant project using the binding. --David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [PROPOSAL] Thrift
On Feb 1, 2008 2:32 PM, Mark Slee [EMAIL PROTECTED] wrote: Following up on what David sent out yesterday, I think we're all on board with having a single committers pool based upon mutual trust and respect. However, dropping parts of the code feels counterproductive to me, as I think it might put up a perceived barrier to collaboration with the Thrift project. Alternate language bindings were one of the main things we were really hoping to see come from the open source community, and we'd like to make sure this continues to be a really approachable thing. We wouldn't want developers to feel like their changes to Thrift won't be accepted without an up front investment of time building reputation in the Thrift community. I think reverting and reapplying these changes creates another risk. Developers would have incentive to keep some language-specific changes to themselves and not share them, simply because it would be more efficient, not because they are philosophically opposed to open source or sharing their changes at all. And to be quite frank, it feels very counterproductive to me to remove code from the project with full a priori intention of putting it back in. We'd rather focus on keeping development open and moving forwards. Removing people's code from the project could send an insulting and negative message. I tend to agree with your observation. There have been donations in the past that weren't completely clear in term of IP at the time the incubation started and that have been cleared later on. IP cleanup is actually one of the main purpose of the incubator. So I don't think this is a roadblock for incubation even though it definitely is one for an official Apache release and you'll need to clear up the remaining issues *before* being able to release. I would also advise the creation of a page somewhere listing the parts of the code that have unclear IPs as well as their respective status for the sake of transparency and to keep track of the evolution. If you already have a good idea of what these parts are, maybe this could even be included in the proposal? Cheers, Matthieu Cheers, Mark -Original Message- From: Martijn Dashorst [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 30, 2008 10:39 AM To: general@incubator.apache.org Subject: Re: Re: [PROPOSAL] Thrift Perhaps in the interest of code audit (which needs to be done) and community building, the code parts of the missing committers should be removed from the code drop prior to incubation start, and be re-introduced inside the incubating podling by providing patches through bugzilla? Martijn On 1/30/08, David Reiss [EMAIL PROTECTED] wrote: If there are people who have already proven their *merit* on the project that are not included on the initial list of committers then I think they should be. In reality, many parts of the Thrift code base are already entirely owned by non-Facebook entities. The Cocoa, C#, Perl, and Smalltalk implementations for Thrift were all developed entirely outside of Facebook, and although Facebook still maintains the trunk, we defer review of all these patches to the developers working on those libraries. So are these people on the initial list of committers? Perl was contributed by Jake Luciani, who is a committer, but the developers of the Cocoa, C#, and Smalltalk bindings are not. These bindings were submitted as a set of a few patches (or in some cases, even a single large patch), and added to the tree without extensive review because, quite frankly, no committers were qualified to review them. Because, as far as we know, the original contributors are the only users of these bindings, we've just been blindly committing any changes they make, so it would make sense for them to have commit access to their parts of the project. However, they have not been active enough in the Thrift community to warrant the trust that comes with full commit access. I would say that the requirements for a language-binding contributor to become a committer would be some amount of activity on the mailing list and either a significant review of the binding by a qualified committer or a significant project using the binding. --David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Buy Wicket in Action: http://manning.com/dashorst Apache Wicket 1.3.0 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [PROPOSAL] Thrift
J Aaron Farr wrote: git could be an issue. Can you explain what the issue is with Git? We have at least seven contributors (three at Facebook, four external) using git-svn right now, and I know that at least a few of us would really like to use native Git as the main repository for Thrift. Paul Querna mentioned on the Thrift list that Apache likes things to happen in the open, but he said that others could explain it better. If the concern is that key developers would maintain their own repositories and exchange patches in private emails, I can assure you that this is not what we have in mind. Perhaps it would help if I explained the sort of repository I am picturing. (I am locally testing some hooks to implement this, so hopefully we can launch it in a trial mode as soon as I can get a machine.) There would be once central repository that would track the trunk. In addition, every committer would be able to post their own branches to the repository. The preferred workflow would be for a committer to post a patch to a branch in the repo, then send out an email to the list like hey guys, my patch for project space-age is on branch priv/dreiss/space-age. Do you think this is ready to be merged into master? Then anyone could go to gitweb to look at the patch, pull the patch into their repo and hack on it, or download a tarball and test it out. I think this is much less error prone than having to manually apply a patch sent over an email. I think it even has the potential to be more open than Subversion. If we encourage developers to continuously push their experimental work to the repository in branches, everyone could follow along and contribute. I think this is a much better situation than the current case with Subversion where local changes that aren't ready to be merged into the main repository yet stay on developers' private machines. I also have a set of scripts to allow non-committers to submit changes directly to the repository, tag the submissions, and email a list of committers. There are two benefits of this. The first is that it is a far less error prone way for patches to be submitted and applied. The second is that non-committers would submit patches for consideration in almost the exact same way as committers. This way, new committers wouldn't have to change their workflows at all, and we wouldn't have to worry about them making newbie mistakes, because they would just continue to work in the same way that led us to believe they would be responsible committers. Well, this email is getting a bit long, so I'll cut myself off here. Let me say in closing, though, that I don't want this issue to hold up the vote on Thrift. 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. But please consider Git. Thank you. --David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Thrift] Re: Re: [PROPOSAL] Thrift
On Fri, 2008-02-01 at 16:20 -0800, David Reiss wrote: J Aaron Farr wrote: git could be an issue. Can you explain what the issue is with Git? We have at least seven contributors (three at Facebook, four external) using git-svn right now, and I know that at least a few of us would really like to use native Git as the main repository for Thrift. Paul Querna mentioned on the Thrift list that Apache likes things to happen in the open, but he said that others could explain it better. I think the main issue is one of uniformity, not a technology. I'm quite happy to believe that git has some significant advantages. However, the ASF has currently standardised on Subversion. It is where _all_ of the ASF's code lies. If one ASF project chooses an alternative source control, we no longer have all the code in one place. We already have this 'diversified' situation with wikis and with bug tracking. We have two wikis (moin and confluence) and three bug trackers (Jira/bugzilla/Scarab - although Scarab may have been shut down already), and it certainly makes life harder in terms of maintenance. So, as an ASF infrastructure person, my first response to git would be 'no', much like an accountant's answer would be 'no' when you ask them for money. I think you should assume that you won't have git as a part of what you get at Apache. You are welcome to enter the Apache world, and evangelise as to why git would be good for the whole ASF, and it is certainly not impossible that it could be adopted. However, if a project made something like the installation and use of git a core part of their proposal, you can be sure it wouldn't be accepted. I hope that makes it a little clearer. It isn't the easiest thing to explain. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Thrift] Re: Re: [PROPOSAL] Thrift
On Feb 1, 2008 4:48 PM, Upayavira [EMAIL PROTECTED] wrote: On Fri, 2008-02-01 at 16:20 -0800, David Reiss wrote: J Aaron Farr wrote: git could be an issue. Can you explain what the issue is with Git? We have at least seven contributors (three at Facebook, four external) using git-svn right now, and I know that at least a few of us would really like to use native Git as the main repository for Thrift. Paul Querna mentioned on the Thrift list that Apache likes things to happen in the open, but he said that others could explain it better. I think the main issue is one of uniformity, not a technology. I'm quite happy to believe that git has some significant advantages. However, the ASF has currently standardised on Subversion. It is where _all_ of the ASF's code lies. If one ASF project chooses an alternative source control, we no longer have all the code in one place. We already have this 'diversified' situation with wikis and with bug tracking. We have two wikis (moin and confluence) and three bug trackers (Jira/bugzilla/Scarab - although Scarab may have been shut down already), and it certainly makes life harder in terms of maintenance. So, as an ASF infrastructure person, my first response to git would be 'no', much like an accountant's answer would be 'no' when you ask them for money. I think you should assume that you won't have git as a part of what you get at Apache. You are welcome to enter the Apache world, and evangelise as to why git would be good for the whole ASF, and it is certainly not impossible that it could be adopted. However, if a project made something like the installation and use of git a core part of their proposal, you can be sure it wouldn't be accepted. +1 Said differently, I would love to use Bazaar at the ASF. Some others would like Mercurial. You'd like Git. I bet we could even find a couple of people who'd like to get back to CVS. Also it would take me 5mn to setup a Bazaar repository on my machine and share it with friends. In the context of the foundation (where the current svn revision is 617723) it would probably take weeks to get something that would fly, plus years of maintenance behind. Cheers, Matthieu I hope that makes it a little clearer. It isn't the easiest thing to explain. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] i18n4data Proposal
Hello, Ahmad: Thank you for your interesting in i18n4data. i18n4data is an alternative to resource bundles. If one wants to shift from resource bundles to i18n4data then he might need to move the messages from resource bundles to a database table. At present my project is only focus on i18n of user's data, which could not be done by resource bundles. It will be helpful to include this transfer tool into i18n4data. The proposal you mentioned is quite different from mine. You are thinking about Business Application Framework, a very high level of development. The i18n4data is only an tool to help an existing application to be in18ned. Best regards, Huang On 2/2/08, Ahmad Khalifa [EMAIL PROTECTED] wrote: Neng Geng Huang wrote: Currently I cannot find any sponsors for this project, so if anyone reading this message would like to get on board, it will be really appreciated. I am not a sponsor/mentor, but I would be interested in participating. I ran into this issue before, when working on this [1]. My main problem was how to i18n a dropdown menu. Resource Bundles did not allow you to store multiple values per key, and they did not have a reverse lookup, i.e. from french value to key. The solution that I was going to work on, was to move the messages from ResourceBundles to a database table. Is this a similar approach? [1] - Business Application Framework. http://mail-archives.apache.org/mod_mbox/incubator-general/200801.mbox/[EMAIL PROTECTED] Regards, Ahmad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Mr. Huang Neng Geng -- Associate Professor Computer Information Engineering Department Wuxi Institute of Technology Wuxi, Jiangsu, China, 214073 Tel: 86-510-5414627(8087) Mobile: 13921501950 email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [PROPOSAL] i18n4data Proposal
On Jan 31, 2008 9:24 PM, Neng Geng Huang [EMAIL PROTECTED] wrote: Hello Dear incubators: I am Huang Neng Geng. I would like to post my proposal about i18n4data, an i18n tool for java web application, that I would like to be incubated. Currently I cannot find any sponsors for this project, so if anyone reading this message would like to get on board, it will be really appreciated. If I can find some time this weekend, I'd like to take a look. I might be interested in getting on board depending on whether I think the project has enough potential etc. Cheers, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [Thrift] Re: Re: [PROPOSAL] Thrift
Thanks for the explanations. Maybe it is too early for me to start evangelizing, but let me know if either of these factors makes a difference. 1/ I don't think we would be putting any load on the Apache infrastructure team. As Matthieu said, it would take about five minutes for one of us to set up the server. 2/ It would be almost as easy to mirror the master branch of the repository into Subversion, so there is no reason the latest and greatest Thrift code could not be available with the rest of the Apache products. Thanks for your consideration! --David Matthieu Riou wrote: On Feb 1, 2008 4:48 PM, Upayavira [EMAIL PROTECTED] wrote: On Fri, 2008-02-01 at 16:20 -0800, David Reiss wrote: J Aaron Farr wrote: git could be an issue. Can you explain what the issue is with Git? We have at least seven contributors (three at Facebook, four external) using git-svn right now, and I know that at least a few of us would really like to use native Git as the main repository for Thrift. Paul Querna mentioned on the Thrift list that Apache likes things to happen in the open, but he said that others could explain it better. I think the main issue is one of uniformity, not a technology. I'm quite happy to believe that git has some significant advantages. However, the ASF has currently standardised on Subversion. It is where _all_ of the ASF's code lies. If one ASF project chooses an alternative source control, we no longer have all the code in one place. We already have this 'diversified' situation with wikis and with bug tracking. We have two wikis (moin and confluence) and three bug trackers (Jira/bugzilla/Scarab - although Scarab may have been shut down already), and it certainly makes life harder in terms of maintenance. So, as an ASF infrastructure person, my first response to git would be 'no', much like an accountant's answer would be 'no' when you ask them for money. I think you should assume that you won't have git as a part of what you get at Apache. You are welcome to enter the Apache world, and evangelise as to why git would be good for the whole ASF, and it is certainly not impossible that it could be adopted. However, if a project made something like the installation and use of git a core part of their proposal, you can be sure it wouldn't be accepted. +1 Said differently, I would love to use Bazaar at the ASF. Some others would like Mercurial. You'd like Git. I bet we could even find a couple of people who'd like to get back to CVS. Also it would take me 5mn to setup a Bazaar repository on my machine and share it with friends. In the context of the foundation (where the current svn revision is 617723) it would probably take weeks to get something that would fly, plus years of maintenance behind. Cheers, Matthieu I hope that makes it a little clearer. It isn't the easiest thing to explain. Regards, Upayavira - 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: [Thrift] Re: Re: [PROPOSAL] Thrift
On Fri, 2008-02-01 at 17:21 -0800, David Reiss wrote: Thanks for the explanations. Maybe it is too early for me to start evangelizing, but let me know if either of these factors makes a difference. 1/ I don't think we would be putting any load on the Apache infrastructure team. As Matthieu said, it would take about five minutes for one of us to set up the server. 2/ It would be almost as easy to mirror the master branch of the repository into Subversion, so there is no reason the latest and greatest Thrift code could not be available with the rest of the Apache products. As to evangelising, I'd say, come along, enter the world of the ASF, join its infrastructure list, help out, get to know us, come to ApacheCons and meet us (if you can). Evangelising will be much easier then! As to using git, I would personally have no problem with a developer (or a group of developers) chosing to use git on top of SVN (assuming it does not put undue load on our SVN servers, like some tools do). I would probably feel uncomfortable with a situation where all devs were _required_ to use git in order to participate in the project, as that would effectively make it a core part of the project. So (a) so long as all code resides in SVN and (b) no-one is required to use git, nor prejudiced against for not using it, I would not have any problems. Regards, Upayavira Matthieu Riou wrote: On Feb 1, 2008 4:48 PM, Upayavira [EMAIL PROTECTED] wrote: On Fri, 2008-02-01 at 16:20 -0800, David Reiss wrote: J Aaron Farr wrote: git could be an issue. Can you explain what the issue is with Git? We have at least seven contributors (three at Facebook, four external) using git-svn right now, and I know that at least a few of us would really like to use native Git as the main repository for Thrift. Paul Querna mentioned on the Thrift list that Apache likes things to happen in the open, but he said that others could explain it better. I think the main issue is one of uniformity, not a technology. I'm quite happy to believe that git has some significant advantages. However, the ASF has currently standardised on Subversion. It is where _all_ of the ASF's code lies. If one ASF project chooses an alternative source control, we no longer have all the code in one place. We already have this 'diversified' situation with wikis and with bug tracking. We have two wikis (moin and confluence) and three bug trackers (Jira/bugzilla/Scarab - although Scarab may have been shut down already), and it certainly makes life harder in terms of maintenance. So, as an ASF infrastructure person, my first response to git would be 'no', much like an accountant's answer would be 'no' when you ask them for money. I think you should assume that you won't have git as a part of what you get at Apache. You are welcome to enter the Apache world, and evangelise as to why git would be good for the whole ASF, and it is certainly not impossible that it could be adopted. However, if a project made something like the installation and use of git a core part of their proposal, you can be sure it wouldn't be accepted. +1 Said differently, I would love to use Bazaar at the ASF. Some others would like Mercurial. You'd like Git. I bet we could even find a couple of people who'd like to get back to CVS. Also it would take me 5mn to setup a Bazaar repository on my machine and share it with friends. In the context of the foundation (where the current svn revision is 617723) it would probably take weeks to get something that would fly, plus years of maintenance behind. Cheers, Matthieu I hope that makes it a little clearer. It isn't the easiest thing to explain. Regards, Upayavira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Thrift mailing list [EMAIL PROTECTED] http://lists.pub.facebook.com/mailman/listinfo/thrift - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] i18n4data Proposal
Dear Eelco: Thank you very much that you will spend time on my proposal. I will be really appreciated if you could be a sponsor. Best regards Huang On 2/2/08, Eelco Hillenius [EMAIL PROTECTED] wrote: On Jan 31, 2008 9:24 PM, Neng Geng Huang [EMAIL PROTECTED] wrote: Hello Dear incubators: I am Huang Neng Geng. I would like to post my proposal about i18n4data, an i18n tool for java web application, that I would like to be incubated. Currently I cannot find any sponsors for this project, so if anyone reading this message would like to get on board, it will be really appreciated. If I can find some time this weekend, I'd like to take a look. I might be interested in getting on board depending on whether I think the project has enough potential etc. Cheers, Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Mr. Huang Neng Geng -- Associate Professor Computer Information Engineering Department Wuxi Institute of Technology Wuxi, Jiangsu, China, 214073 Tel: 86-510-5414627(8087) Mobile: 13921501950 email: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: [PROPOSAL] i18n4data Proposal
Hi, In OFBiz we have taken another but similar approach using XML as repository (and not a real database), please see : http://www.nabble.com/XML-properties-files---brainstorm-td13955196.html#a13955196 https://issues.apache.org/jira/browse/OFBIZ-1442 There is currently an effort to migrate all our properties files to XML files. Jacques Le Roux From: Neng Geng Huang [EMAIL PROTECTED] Hello, Ahmad: Thank you for your interesting in i18n4data. i18n4data is an alternative to resource bundles. If one wants to shift from resource bundles to i18n4data then he might need to move the messages from resource bundles to a database table. At present my project is only focus on i18n of user's data, which could not be done by resource bundles. It will be helpful to include this transfer tool into i18n4data. The proposal you mentioned is quite different from mine. You are thinking about Business Application Framework, a very high level of development. The i18n4data is only an tool to help an existing application to be in18ned. Best regards, Huang On 2/2/08, Ahmad Khalifa [EMAIL PROTECTED] wrote: Neng Geng Huang wrote: Currently I cannot find any sponsors for this project, so if anyone reading this message would like to get on board, it will be really appreciated. I am not a sponsor/mentor, but I would be interested in participating. I ran into this issue before, when working on this [1]. My main problem was how to i18n a dropdown menu. Resource Bundles did not allow you to store multiple values per key, and they did not have a reverse lookup, i.e. from french value to key. The solution that I was going to work on, was to move the messages from ResourceBundles to a database table. Is this a similar approach? [1] - Business Application Framework. http://mail-archives.apache.org/mod_mbox/incubator-general/200801.mbox/[EMAIL PROTECTED] Regards, Ahmad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Mr. Huang Neng Geng -- Associate Professor Computer Information Engineering Department Wuxi Institute of Technology Wuxi, Jiangsu, China, 214073 Tel: 86-510-5414627(8087) Mobile: 13921501950 email: [EMAIL PROTECTED], [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
