Re: [IMPC] [VOTE] Graduate Apache Jena as a Top Level Project
+1 non-binding Cheers, Andreas On 02.04.2012 11:10, Andy Seaborne wrote: > This is a call for vote to graduate the Apache Jena podling from > Apache Incubator to be a top level project. > > Jena entered incubation in November 2010. The project has added two > new committers and PPMC members, made several releases and has a > diverse committer base. The user and development communities are > active. The PPMC has indicated [1,2,3] that it believes the project > is ready to graduate as a top-level project with the resolution draft > below. > > We ask that the IPMC approve this graduation request though this VOTE. > > [1] Vote: http://s.apache.org/jena-graduation-vote > [2] Result: http://s.apache.org/jena-graduation > [3] Request for comments: > http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3C5C4A33CB-B122-43A8-B082-CBD63B526DE7%40cray.com%3E > > > On behalf of the Apache Jena PPMC, > > Andy > > - > > [ ] +1 Recommend to the ASF Board that Apache Jena Proposal >is ready to graduate to being a top level project. > [ ] 0 > [ ] -1 Do not graduate Apache Jena because ... > > The vote will be tallied no earlier than: > >Thursday April 5th, at 23:59 UTC. > > - > > X. Establish the Apache Jena Project > >WHEREAS, the Board of Directors deems it to be in the best >interests of the Foundation and consistent with the >Foundation's purpose to establish a Project Management >Committee charged with the creation and maintenance of >open-source software related to accessing, storing, querying, >publishing and reasoning with semantic web data while >adhering to relevant W3C and community standards. > >NOW, THEREFORE, BE IT RESOLVED, that a Project Management >Committee (PMC), to be known as the "Apache Jena Project", >be and hereby is established pursuant to Bylaws of the >Foundation; and be it further > >RESOLVED, that the Apache Jena Project be and hereby is >responsible for the creation and maintenance of software >related to accessing, storing, querying, >publishing and reasoning with semantic web data while >adhering to relevant W3C and community standards; >and be it further > >RESOLVED, that the office of "Vice President, Apache Jena" be >and hereby is created, the person holding such office to >serve at the direction of the Board of Directors as the chair >of the Apache Jena Project, and to have primary responsibility >for management of the projects within the scope of >responsibility of the Apache Jena Project; and be it further > >RESOLVED, that the persons listed immediately below be and >hereby are appointed to serve as the initial members of the >Apache Jena Project: > > * Andy Seaborne (andy) > * Benson Marguilies (bimargulies) > * Chris Dollin (chrisdollin) > * Damian Steer (damian) > * Dave Reynolds (der) > * Ian Dickinson (ijd) > * Paolo Castagna (castagna) > * Rob Vesse (rvesse) > * Stephen Allen (sallen) > >NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andy Seaborne >be appointed to the office of Vice President, Apache Jena, to >serve in accordance with and subject to the direction of the >Board of Directors and the Bylaws of the Foundation until >death, resignation, retirement, removal or disqualification, >or until a successor is appointed; and be it further > >RESOLVED, that the initial Apache Jena PMC be and hereby is >tasked with the creation of a set of bylaws intended to >encourage open development and increased participation in the >Apache Jena Project; and be it further > >RESOLVED, that the Apache Jena Project be and hereby >is tasked with the migration and rationalization of the Apache >Incubator Jena podling; and be it further > >RESOLVED, that all responsibilities pertaining to the Apache >Incubator Jena podling encumbered upon the Apache Incubator >Project are hereafter discharged. > > - > 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: [IMPC] [VOTE] Graduate Apache Jena as a Top Level Project
+1 binding Congrats! Regards, Alan On Apr 2, 2012, at 2:10 AM, Andy Seaborne wrote: > [ ] +1 Recommend to the ASF Board that Apache Jena Proposal > is ready to graduate to being a top level project. > [ ] 0 > [ ] -1 Do not graduate Apache Jena because ... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about downloading binaries
On 3 April 2012 00:48, Jukka Zitting wrote: > Hi, > > [dropped infrastructure@] > > On Tue, Apr 3, 2012 at 1:43 AM, sebb wrote: >> Can you be certain that the non-standard jars will not interfere with >> the standard jars? > > ManifoldCF is a standalone application, not a library you'd use as a > dependency of another application. Thus whatever code goes into > ManifoldCF has a near-zero chance of affecting the classpath of any > other Java application. In that case, it's only necessary to ensure that the jar is not published where it can be picked up and used independently. > BR, > > Jukka Zitting > > - > 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: Question about downloading binaries
Hi, [dropped infrastructure@] On Tue, Apr 3, 2012 at 1:43 AM, sebb wrote: > Can you be certain that the non-standard jars will not interfere with > the standard jars? ManifoldCF is a standalone application, not a library you'd use as a dependency of another application. Thus whatever code goes into ManifoldCF has a near-zero chance of affecting the classpath of any other Java application. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about downloading binaries
On 3 April 2012 00:38, Karl Wright wrote: > "Whether it is necessary is another matter, and is not easy to answer > in general as "it depends"." > > I'm going to treat this as "unnecessary", because we were extremely > careful to maintain backwards compatibility when writing the changes. The API may be backwards compatible, but the behaviour presumably isn't, otherwise there would be no need to apply the patch. [The physical API of an AA battery is identical for Zinc-carbon, NiCd and NiMh, and they are often interchangeable, but their behaviour is not identical.] Can you be certain that the non-standard jars will not interfere with the standard jars? > > Karl > > On Mon, Apr 2, 2012 at 6:59 PM, sebb wrote: >> On 2 April 2012 22:45, Karl Wright wrote: >>> I think the bigger picture here is that resolving differences of this >>> kind requires time, and during the interim we need to be able to >>> release software anyway. I have no wish to maintain a forked copy of >>> either xerces or httpclient indefinitely, but right at the moment we >>> are not prepared or able to use the released versions of these >>> libraries. I hope that we can all agree that pragmatism has a value; >>> we're certainly not trying to step on people's toes, we're simply >>> trying to solve a problem. >> >> One sure way to solve the problem is to use your own package namespace >> for any such imported source. >> >> That is definitely sufficient. >> >> Whether it is necessary is another matter, and is not easy to answer >> in general as "it depends". >> >>> Thanks, >>> Karl >>> >>> >>> On Mon, Apr 2, 2012 at 5:28 PM, Karl Wright wrote: "what's the use-case for non-well-formed XML?' This thread is probably not the best place to delve further in that direction." Simple use case: parsing malformed RSS feeds. I agree, though, we're getting into the weeds here; I'd love to have this discussion elsewhere, but the point does stand that none of these patch decisions was done lightly. Hopefully the community can accept that. Karl On Mon, Apr 2, 2012 at 4:54 PM, Benson Margulies wrote: > Karl, > > I'm exceedingly sorry here that the IPMC as a whole let you down by > not turning into these issues and dealing with them at the outset. > There's been a lot of sensitivity expressed lately to Apache projects > stepping on each other's toes. > > Personally, I have no objection to including mutant jars in a -deps > binary with a clear explanation of what they are, but I would like to > see some support for that view, because I'd could imagine some > objections based on recent email. > > In the longer term, if ManifoldCF really wants to include an "XML > parser with a difference", then it's certainly possible for you to > maintain and release a fork of Xerces under your own package names. I > agree with Sebb that you would be well advised to find some other way > around it. My personal reaction, in complete isolation from the > problem at hand, was 'really? what's the use-case for non-well-formed > XML?' This thread is probably not the best place to delve further in > that direction. > > --benson - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about downloading binaries
"Whether it is necessary is another matter, and is not easy to answer in general as "it depends"." I'm going to treat this as "unnecessary", because we were extremely careful to maintain backwards compatibility when writing the changes. Karl On Mon, Apr 2, 2012 at 6:59 PM, sebb wrote: > On 2 April 2012 22:45, Karl Wright wrote: >> I think the bigger picture here is that resolving differences of this >> kind requires time, and during the interim we need to be able to >> release software anyway. I have no wish to maintain a forked copy of >> either xerces or httpclient indefinitely, but right at the moment we >> are not prepared or able to use the released versions of these >> libraries. I hope that we can all agree that pragmatism has a value; >> we're certainly not trying to step on people's toes, we're simply >> trying to solve a problem. > > One sure way to solve the problem is to use your own package namespace > for any such imported source. > > That is definitely sufficient. > > Whether it is necessary is another matter, and is not easy to answer > in general as "it depends". > >> Thanks, >> Karl >> >> >> On Mon, Apr 2, 2012 at 5:28 PM, Karl Wright wrote: >>> "what's the use-case for non-well-formed >>> XML?' This thread is probably not the best place to delve further in >>> that direction." >>> >>> Simple use case: parsing malformed RSS feeds. I agree, though, we're >>> getting into the weeds here; I'd love to have this discussion >>> elsewhere, but the point does stand that none of these patch decisions >>> was done lightly. Hopefully the community can accept that. >>> >>> Karl >>> >>> On Mon, Apr 2, 2012 at 4:54 PM, Benson Margulies >>> wrote: Karl, I'm exceedingly sorry here that the IPMC as a whole let you down by not turning into these issues and dealing with them at the outset. There's been a lot of sensitivity expressed lately to Apache projects stepping on each other's toes. Personally, I have no objection to including mutant jars in a -deps binary with a clear explanation of what they are, but I would like to see some support for that view, because I'd could imagine some objections based on recent email. In the longer term, if ManifoldCF really wants to include an "XML parser with a difference", then it's certainly possible for you to maintain and release a fork of Xerces under your own package names. I agree with Sebb that you would be well advised to find some other way around it. My personal reaction, in complete isolation from the problem at hand, was 'really? what's the use-case for non-well-formed XML?' This thread is probably not the best place to delve further in that direction. --benson - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about downloading binaries
On 2 April 2012 22:45, Karl Wright wrote: > I think the bigger picture here is that resolving differences of this > kind requires time, and during the interim we need to be able to > release software anyway. I have no wish to maintain a forked copy of > either xerces or httpclient indefinitely, but right at the moment we > are not prepared or able to use the released versions of these > libraries. I hope that we can all agree that pragmatism has a value; > we're certainly not trying to step on people's toes, we're simply > trying to solve a problem. One sure way to solve the problem is to use your own package namespace for any such imported source. That is definitely sufficient. Whether it is necessary is another matter, and is not easy to answer in general as "it depends". > Thanks, > Karl > > > On Mon, Apr 2, 2012 at 5:28 PM, Karl Wright wrote: >> "what's the use-case for non-well-formed >> XML?' This thread is probably not the best place to delve further in >> that direction." >> >> Simple use case: parsing malformed RSS feeds. I agree, though, we're >> getting into the weeds here; I'd love to have this discussion >> elsewhere, but the point does stand that none of these patch decisions >> was done lightly. Hopefully the community can accept that. >> >> Karl >> >> On Mon, Apr 2, 2012 at 4:54 PM, Benson Margulies >> wrote: >>> Karl, >>> >>> I'm exceedingly sorry here that the IPMC as a whole let you down by >>> not turning into these issues and dealing with them at the outset. >>> There's been a lot of sensitivity expressed lately to Apache projects >>> stepping on each other's toes. >>> >>> Personally, I have no objection to including mutant jars in a -deps >>> binary with a clear explanation of what they are, but I would like to >>> see some support for that view, because I'd could imagine some >>> objections based on recent email. >>> >>> In the longer term, if ManifoldCF really wants to include an "XML >>> parser with a difference", then it's certainly possible for you to >>> maintain and release a fork of Xerces under your own package names. I >>> agree with Sebb that you would be well advised to find some other way >>> around it. My personal reaction, in complete isolation from the >>> problem at hand, was 'really? what's the use-case for non-well-formed >>> XML?' This thread is probably not the best place to delve further in >>> that direction. >>> >>> --benson - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: VXQuery status (Was: [Incubator Wiki] Update of "April2012" by TillWestmann)
Hi Jukka, We in the VXQuery trenches need some help with growing the community. We understand the technical aspects of implementing the XQuery engine, but need some guidance with community building. With respect to the system we are in a catch-22 situation. We feel that some part of the system needs to exist and work before we can bring on-board a community and we are not quite there. At the same time, we need pairs of hands to help build out that core part of the system that will attract a community. I do believe that the new focus on big-data will indeed attract a community once we have something up and running. On other issue is that the committers of VXQuery are working on this project out of personal interest and have no agency that is funding its development. As a result, we work on this after our day jobs and so progress is slow. My day-job is at a university where I meet students with various interests. The GSoC project proposals were done with the aim of using students for the summer (with funding by Google through GSoC), to work on bootstrapping the VXQuery project so it gets into a functional state. I do agree that GSoC is not our method to grow a community. Please advise. Thanks, Vinayak On 4/2/12 5:30 AM, Jukka Zitting wrote: Hi, Thanks for the report, VXQuery! On Mon, Apr 2, 2012 at 5:26 AM, Apache Wiki wrote: + * change of the focus of the project (the previous focus was to be + flexible wrt the representation of the data model, the new focus + is parallel processing of large amounts of XML data) + * re-newed development activity I see a single "VXQuery focus" thread on vxquery-dev@ and a handful of related commits, but the activity on those seems rather to decline than increase over time. So looking at the project from the outside it unfortunately doesn't seem like the new focus is yet helping re-activate the project. Do you expect this to change over the next few months? Does VXQuery have concrete plans on how to drive the new focus forward? If yes, is help from the larger Incubator community or ComDev needed? + * 2 proposals for GSoC (1 person expressed interest in working on + VXQuery for GSoC) I'm concerned about starting a GSoC project on a codebase without an active community. GSoC students are supposed to be working with the community, not *be* the community. Have you talked about this with ComDev? PS. VXQuery has four mentors listed: Paul Fremantle, Sanjiva Weerawarana, Radu Preotiuc-Pietro, and Jochen Wiedmann. I only see Jochen interacting with the community on vxquery-dev@ over the past two years. Are the other mentors still actively following the project? BR, Jukka Zitting - 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: Podling website cleanup permissions
On Mon, Apr 2, 2012 at 12:42 PM, sebb wrote: > You need to ask Infra via JIRA; svnwc is the id used by svnpubsub and > is deliberately not writable by committers. Thanks, Tony took care of it with https://issues.apache.org/jira/browse/INFRA-4643 and I updated the Incubator documentation. Cheers, Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPC] [VOTE] Graduate Apache Jena as a Top Level Project
+1 from me, great work guys! (binding) Cheers, Chris On Apr 2, 2012, at 2:10 AM, Andy Seaborne wrote: > This is a call for vote to graduate the Apache Jena podling from Apache > Incubator to be a top level project. > > Jena entered incubation in November 2010. The project has added two new > committers and PPMC members, made several releases and has a diverse > committer base. The user and development communities are active. The > PPMC has indicated [1,2,3] that it believes the project is ready to > graduate as a top-level project with the resolution draft below. > > We ask that the IPMC approve this graduation request though this VOTE. > > [1] Vote: http://s.apache.org/jena-graduation-vote > [2] Result: http://s.apache.org/jena-graduation > [3] Request for comments: > http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3C5C4A33CB-B122-43A8-B082-CBD63B526DE7%40cray.com%3E > > On behalf of the Apache Jena PPMC, > > Andy > > - > > [ ] +1 Recommend to the ASF Board that Apache Jena Proposal >is ready to graduate to being a top level project. > [ ] 0 > [ ] -1 Do not graduate Apache Jena because ... > > The vote will be tallied no earlier than: > >Thursday April 5th, at 23:59 UTC. > > - > > X. Establish the Apache Jena Project > >WHEREAS, the Board of Directors deems it to be in the best >interests of the Foundation and consistent with the >Foundation's purpose to establish a Project Management >Committee charged with the creation and maintenance of >open-source software related to accessing, storing, querying, >publishing and reasoning with semantic web data while >adhering to relevant W3C and community standards. > >NOW, THEREFORE, BE IT RESOLVED, that a Project Management >Committee (PMC), to be known as the "Apache Jena Project", >be and hereby is established pursuant to Bylaws of the >Foundation; and be it further > >RESOLVED, that the Apache Jena Project be and hereby is >responsible for the creation and maintenance of software >related to accessing, storing, querying, >publishing and reasoning with semantic web data while >adhering to relevant W3C and community standards; >and be it further > >RESOLVED, that the office of "Vice President, Apache Jena" be >and hereby is created, the person holding such office to >serve at the direction of the Board of Directors as the chair >of the Apache Jena Project, and to have primary responsibility >for management of the projects within the scope of >responsibility of the Apache Jena Project; and be it further > >RESOLVED, that the persons listed immediately below be and >hereby are appointed to serve as the initial members of the >Apache Jena Project: > > * Andy Seaborne (andy) > * Benson Marguilies (bimargulies) > * Chris Dollin (chrisdollin) > * Damian Steer (damian) > * Dave Reynolds (der) > * Ian Dickinson (ijd) > * Paolo Castagna (castagna) > * Rob Vesse (rvesse) > * Stephen Allen (sallen) > >NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andy Seaborne >be appointed to the office of Vice President, Apache Jena, to >serve in accordance with and subject to the direction of the >Board of Directors and the Bylaws of the Foundation until >death, resignation, retirement, removal or disqualification, >or until a successor is appointed; and be it further > >RESOLVED, that the initial Apache Jena PMC be and hereby is >tasked with the creation of a set of bylaws intended to >encourage open development and increased participation in the >Apache Jena Project; and be it further > >RESOLVED, that the Apache Jena Project be and hereby >is tasked with the migration and rationalization of the Apache >Incubator Jena podling; and be it further > >RESOLVED, that all responsibilities pertaining to the Apache >Incubator Jena podling encumbered upon the Apache Incubator >Project are hereafter discharged. > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++
Re: Question about downloading binaries
I think the bigger picture here is that resolving differences of this kind requires time, and during the interim we need to be able to release software anyway. I have no wish to maintain a forked copy of either xerces or httpclient indefinitely, but right at the moment we are not prepared or able to use the released versions of these libraries. I hope that we can all agree that pragmatism has a value; we're certainly not trying to step on people's toes, we're simply trying to solve a problem. Thanks, Karl On Mon, Apr 2, 2012 at 5:28 PM, Karl Wright wrote: > "what's the use-case for non-well-formed > XML?' This thread is probably not the best place to delve further in > that direction." > > Simple use case: parsing malformed RSS feeds. I agree, though, we're > getting into the weeds here; I'd love to have this discussion > elsewhere, but the point does stand that none of these patch decisions > was done lightly. Hopefully the community can accept that. > > Karl > > On Mon, Apr 2, 2012 at 4:54 PM, Benson Margulies > wrote: >> Karl, >> >> I'm exceedingly sorry here that the IPMC as a whole let you down by >> not turning into these issues and dealing with them at the outset. >> There's been a lot of sensitivity expressed lately to Apache projects >> stepping on each other's toes. >> >> Personally, I have no objection to including mutant jars in a -deps >> binary with a clear explanation of what they are, but I would like to >> see some support for that view, because I'd could imagine some >> objections based on recent email. >> >> In the longer term, if ManifoldCF really wants to include an "XML >> parser with a difference", then it's certainly possible for you to >> maintain and release a fork of Xerces under your own package names. I >> agree with Sebb that you would be well advised to find some other way >> around it. My personal reaction, in complete isolation from the >> problem at hand, was 'really? what's the use-case for non-well-formed >> XML?' This thread is probably not the best place to delve further in >> that direction. >> >> --benson - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Chukwa status (Was: [Incubator Wiki] Update of "April2012" by EricYang)
Hi Jukka, Chukwa has been used in various organization. For Chukwa 0.5.0 release, the majority of code has been contributed from single individual. There are questions raised that there should be more diversity of the contribution from the community from mentors. There are increased activities on user mailing list in the past month, but momentum and traction is still a concern. I plan to update the report per Bernd's recommendation. regards, Eric On Sat, Mar 31, 2012 at 1:46 AM, Jukka Zitting wrote: > Hi, > > Thanks for the early report, Chukwa! > > On Thu, Mar 29, 2012 at 6:07 AM, Apache Wiki wrote: >> + Chukwa is an open source data collection system for monitoring large >> distributed systems. Chukwa is built on top of the Hadoop Distributed File >> System (HDFS), HBase and Map/Reduce framework and inherits Hadoop’s >> scalability and robustness. Chukwa also includes a flexible and powerful >> toolkit for displaying, monitoring and analyzing results to make the best >> use of the collected data. > > I think the first sentence would be enough context for the report. > Please also include a note of when Chukwa entered incubation. > >> + - Chukwa 0.5.0 has been released >> + - New committer Ahmed Fathalla has been voted in and granted proper krama >> + - Mentor William A. Rowe Jr resigned >> + - Alan D. Cabrera volunteer to become new mentor > > Sounds good. > > What's your status regarding graduation, most notably in terms of > community activity and diversity? > > BR, > > Jukka Zitting > > - > 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: Question about downloading binaries
"what's the use-case for non-well-formed XML?' This thread is probably not the best place to delve further in that direction." Simple use case: parsing malformed RSS feeds. I agree, though, we're getting into the weeds here; I'd love to have this discussion elsewhere, but the point does stand that none of these patch decisions was done lightly. Hopefully the community can accept that. Karl On Mon, Apr 2, 2012 at 4:54 PM, Benson Margulies wrote: > Karl, > > I'm exceedingly sorry here that the IPMC as a whole let you down by > not turning into these issues and dealing with them at the outset. > There's been a lot of sensitivity expressed lately to Apache projects > stepping on each other's toes. > > Personally, I have no objection to including mutant jars in a -deps > binary with a clear explanation of what they are, but I would like to > see some support for that view, because I'd could imagine some > objections based on recent email. > > In the longer term, if ManifoldCF really wants to include an "XML > parser with a difference", then it's certainly possible for you to > maintain and release a fork of Xerces under your own package names. I > agree with Sebb that you would be well advised to find some other way > around it. My personal reaction, in complete isolation from the > problem at hand, was 'really? what's the use-case for non-well-formed > XML?' This thread is probably not the best place to delve further in > that direction. > > --benson - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Jena LARQ 1.0.0-incubating
+1
On Sun, Apr 1, 2012 at 3:48 PM, Paolo Castagna
wrote:
> Hi,
> here is a vote on a release for Apache Jena LARQ module:
> jena-larq-1.0.0-incubating.
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] 0 Don't care
> [ ] -1 Don't release, because ...
>
> This vote will be open until:
>
> Wednesday 4/April 23:59 UTC
> (3 whole days: 72 hours from the same hour tonight).
>
> jena-dev thread:
> http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201203.mbox/%3C4F6ADCBF.3030005%40googlemail.com%3E
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachejena-100/
>
> Proposed files and structure to merge with existing dist/ area:
> http://people.apache.org/~castagna/merge-jena-larq-1.0.0-RC-1/
>
> Keys:
> http://www.apache.org/dist/incubator/jena/KEYS
>
> SVN tag:
> https://svn.apache.org/repos/asf/incubator/jena/Jena2/LARQ/tags/jena-larq-1.0.0-incubating-RC-1/
>
> The module is tagged with the version and "RC-1" to denote the first release
> candidate for this release cycle. If voted on successfully, the tag will be
> changed ("svn mv") to the same name but minus the RC-1.
>
> Paolo
>
> -
> 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: Question about downloading binaries
Karl, I'm exceedingly sorry here that the IPMC as a whole let you down by not turning into these issues and dealing with them at the outset. There's been a lot of sensitivity expressed lately to Apache projects stepping on each other's toes. Personally, I have no objection to including mutant jars in a -deps binary with a clear explanation of what they are, but I would like to see some support for that view, because I'd could imagine some objections based on recent email. In the longer term, if ManifoldCF really wants to include an "XML parser with a difference", then it's certainly possible for you to maintain and release a fork of Xerces under your own package names. I agree with Sebb that you would be well advised to find some other way around it. My personal reaction, in complete isolation from the problem at hand, was 'really? what's the use-case for non-well-formed XML?' This thread is probably not the best place to delve further in that direction. --benson - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPC] [VOTE] Graduate Apache Jena as a Top Level Project
+1 binding mentor On Mon, Apr 2, 2012 at 5:20 AM, Bertrand Delacretaz wrote: > On Mon, Apr 2, 2012 at 11:10 AM, Andy Seaborne wrote: >> ...We ask that the IPMC approve this graduation request though this VOTE. > > [X ] +1 Recommend to the ASF Board that Apache Jena Proposal > is ready to graduate to being a top level project. > > And congrats! > > -Bertrand (Jena mentor) > > - > 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: Podling website cleanup permissions
On 2 April 2012 20:27, Marvin Humphrey wrote: > Greets, > > I'm having difficulty following through on this directive: > > http://incubator.apache.org/guides/graduation.html#transfer > > 3. Delete the podling website from /www/incubator.apache.org on > people.apache.org. > > I can't rm -rf /www/incubator.apache.org/content/lucy because it > belongs to svnwc: > > marvin@minotaur:/www/incubator.apache.org/content$ ls -l | grep lucy > drwxr-sr-x 6 svnwc svnwc 14 Mar 29 02:44 lucy > > Ideas? You need to ask Infra via JIRA; svnwc is the id used by svnpubsub and is deliberately not writable by committers. > Marvin Humphrey > > - > 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: Question about downloading binaries
On 2 April 2012 20:11, Karl Wright wrote: > Please see below. > > On Mon, Apr 2, 2012 at 3:03 PM, Benson Margulies > wrote: >> > cliff.> >> >> On Mon, Apr 2, 2012 at 2:19 PM, Karl Wright wrote: >>> "Since the 3rd-party material is consumed in source code form, I assume >>> it must have a source-compatible license." >>> >>> The releases we patch are: >>> >>> - commons-httpclient 3.1 >>> - xerces 2.9.1 >> >> Uh, oh. Now we have another problem, since these are your fellow >> Apache people at work. >> >> Have you submitted patches back to commons and xerces? What sort of >> reaction did you get? >> > > I submitted patches for all the materials. In the case of httpclient, > the patches were partly accepted and partly rejected - but they are > only available in the 4.x version of the library, which we have not > yet gone to. You really should upgrade; 3.x is end-of-life. > The reason is complex; the connectors that would use it > are difficult to test in the absence of available instances of the > kinds of repositories they would be communicating with. That's a long > standing problem I've been trying to find a solution for for more than > 2 years now. Depending on the original source, it may be possible to provide local code that works round the issues. This can generally be in your own package space. If the required hooks are missing in the libraries, have you tried asking the developers to provide a hook? That may be possible without compromising the original library. > The patches that were rejected involved things that the package > developers considered to be "not consistent with mission". For > example, the xerces change basically allows the parser to accept > broken xml (if a certain configuration switch is enabled). I'm not surprised that was rejected. There has to be a better way to do that. >> Releasing 'convenience binaries' of modified sources of Apache >> projects strikes me as somewhat contrary to the overall goals here. >> I'd like others to weigh in here, but I'd propose that you always >> ship modified Apache products as source. Forget about 'patch'. Just >> ship modified sources files and drop them into place in fetched copies >> of their releases, and build the results. >> > > I'd love to acheive closure, believe me, and there are open tickets to > this end, but until we do it I don't believe it is wise or feasible to > withhold ManifoldCF from the community. > >> As Sebb points out, you really, really, must not push your modified >> binaries to maven central unless you use shade or equivalent to change >> the package names. >> > > I would never do that, obviously. > >> I wish that others would weigh in here; how bad an idea is a >> 'convenience binary' consisting of a modified Apache project library? >> >>> - jetty 6.1 >> >> As a courtesy to the Jetty project, the same rule of 'don't stick this >> out into maven as a standalone artifact' applies. Otherwise, the >> two-pronged approach is fine: make convenience binaries, and also >> provide the user with the ability to rebuild them for themselves. I'd >> propose the 'whole file replacement' mechanism here as well to solve >> the Windows problem. >> > > Actually it occurred to me that since there are published binary > releases of these artifacts, I can download and unpack those. So I > think I have a solution for this one. > > Karl > >>> >>> We also build the jdk1.5 version of hsqldb, which does not require >>> patching but does require recompilation. >> >> That's simple enough as a -dep convenience binary. >> >>> >>> I believe all of these are covered by the Apache 2.0 license. >>> >>> Karl >>> >>> On Mon, Apr 2, 2012 at 2:14 PM, sebb wrote: On 2 April 2012 17:53, Benson Margulies wrote: > Karl, > > I hope that you are making this too hard. > > We don't care about the contents of someone else's binaries. If you > make and deploy a -deps package of third-party binaries, as a > convenience for your users, it can contain any strange mixture of > sources and binaries it contains. If you provide a script to download > a third-party package, we don't care what it downloads so long as the > license is acceptable for a dependency. > > I don't follow the logic that prevents you from having a release manager: > > a) retrieve third-part sources > b) apply your patches from your svn > c) create -deps bundle > d) deploy to dist, appropriately marked as 'not an Apache release', > > so long as the third-party material has an acceptable license in the > first place. I would add: We should not publish patched builds of source in such a way that they can interfere with the normal use of the unpatched source builds. This includes (but is not limited to) publishing patched binaries on Maven Central (regardless of the groupId) with the original package names. Since the 3rd-party material is consumed in source
Podling website cleanup permissions
Greets, I'm having difficulty following through on this directive: http://incubator.apache.org/guides/graduation.html#transfer 3. Delete the podling website from /www/incubator.apache.org on people.apache.org. I can't rm -rf /www/incubator.apache.org/content/lucy because it belongs to svnwc: marvin@minotaur:/www/incubator.apache.org/content$ ls -l | grep lucy drwxr-sr-x 6 svnwc svnwc 14 Mar 29 02:44 lucy Ideas? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about downloading binaries
I've created CONNECTORS-443 to describe the current proposal. Karl On Mon, Apr 2, 2012 at 3:11 PM, Karl Wright wrote: > Please see below. > > On Mon, Apr 2, 2012 at 3:03 PM, Benson Margulies > wrote: >> > cliff.> >> >> On Mon, Apr 2, 2012 at 2:19 PM, Karl Wright wrote: >>> "Since the 3rd-party material is consumed in source code form, I assume >>> it must have a source-compatible license." >>> >>> The releases we patch are: >>> >>> - commons-httpclient 3.1 >>> - xerces 2.9.1 >> >> Uh, oh. Now we have another problem, since these are your fellow >> Apache people at work. >> >> Have you submitted patches back to commons and xerces? What sort of >> reaction did you get? >> > > I submitted patches for all the materials. In the case of httpclient, > the patches were partly accepted and partly rejected - but they are > only available in the 4.x version of the library, which we have not > yet gone to. The reason is complex; the connectors that would use it > are difficult to test in the absence of available instances of the > kinds of repositories they would be communicating with. That's a long > standing problem I've been trying to find a solution for for more than > 2 years now. > > The patches that were rejected involved things that the package > developers considered to be "not consistent with mission". For > example, the xerces change basically allows the parser to accept > broken xml (if a certain configuration switch is enabled). > >> Releasing 'convenience binaries' of modified sources of Apache >> projects strikes me as somewhat contrary to the overall goals here. >> I'd like others to weigh in here, but I'd propose that you always >> ship modified Apache products as source. Forget about 'patch'. Just >> ship modified sources files and drop them into place in fetched copies >> of their releases, and build the results. >> > > I'd love to acheive closure, believe me, and there are open tickets to > this end, but until we do it I don't believe it is wise or feasible to > withhold ManifoldCF from the community. > >> As Sebb points out, you really, really, must not push your modified >> binaries to maven central unless you use shade or equivalent to change >> the package names. >> > > I would never do that, obviously. > >> I wish that others would weigh in here; how bad an idea is a >> 'convenience binary' consisting of a modified Apache project library? >> >>> - jetty 6.1 >> >> As a courtesy to the Jetty project, the same rule of 'don't stick this >> out into maven as a standalone artifact' applies. Otherwise, the >> two-pronged approach is fine: make convenience binaries, and also >> provide the user with the ability to rebuild them for themselves. I'd >> propose the 'whole file replacement' mechanism here as well to solve >> the Windows problem. >> > > Actually it occurred to me that since there are published binary > releases of these artifacts, I can download and unpack those. So I > think I have a solution for this one. > > Karl > >>> >>> We also build the jdk1.5 version of hsqldb, which does not require >>> patching but does require recompilation. >> >> That's simple enough as a -dep convenience binary. >> >>> >>> I believe all of these are covered by the Apache 2.0 license. >>> >>> Karl >>> >>> On Mon, Apr 2, 2012 at 2:14 PM, sebb wrote: On 2 April 2012 17:53, Benson Margulies wrote: > Karl, > > I hope that you are making this too hard. > > We don't care about the contents of someone else's binaries. If you > make and deploy a -deps package of third-party binaries, as a > convenience for your users, it can contain any strange mixture of > sources and binaries it contains. If you provide a script to download > a third-party package, we don't care what it downloads so long as the > license is acceptable for a dependency. > > I don't follow the logic that prevents you from having a release manager: > > a) retrieve third-part sources > b) apply your patches from your svn > c) create -deps bundle > d) deploy to dist, appropriately marked as 'not an Apache release', > > so long as the third-party material has an acceptable license in the > first place. I would add: We should not publish patched builds of source in such a way that they can interfere with the normal use of the unpatched source builds. This includes (but is not limited to) publishing patched binaries on Maven Central (regardless of the groupId) with the original package names. Since the 3rd-party material is consumed in source code form, I assume it must have a source-compatible license. I.e. a license which is only normally permitted for binary dependencies would I think be excluded for this use case. > In case I'm wrong here, I'll ask: what is the build tool of choice for > ManifoldCF? On the other hand from all of these, perhaps there is, or > could be, a plugin
Re: Question about downloading binaries
Please see below. On Mon, Apr 2, 2012 at 3:03 PM, Benson Margulies wrote: > cliff.> > > On Mon, Apr 2, 2012 at 2:19 PM, Karl Wright wrote: >> "Since the 3rd-party material is consumed in source code form, I assume >> it must have a source-compatible license." >> >> The releases we patch are: >> >> - commons-httpclient 3.1 >> - xerces 2.9.1 > > Uh, oh. Now we have another problem, since these are your fellow > Apache people at work. > > Have you submitted patches back to commons and xerces? What sort of > reaction did you get? > I submitted patches for all the materials. In the case of httpclient, the patches were partly accepted and partly rejected - but they are only available in the 4.x version of the library, which we have not yet gone to. The reason is complex; the connectors that would use it are difficult to test in the absence of available instances of the kinds of repositories they would be communicating with. That's a long standing problem I've been trying to find a solution for for more than 2 years now. The patches that were rejected involved things that the package developers considered to be "not consistent with mission". For example, the xerces change basically allows the parser to accept broken xml (if a certain configuration switch is enabled). > Releasing 'convenience binaries' of modified sources of Apache > projects strikes me as somewhat contrary to the overall goals here. > I'd like others to weigh in here, but I'd propose that you always > ship modified Apache products as source. Forget about 'patch'. Just > ship modified sources files and drop them into place in fetched copies > of their releases, and build the results. > I'd love to acheive closure, believe me, and there are open tickets to this end, but until we do it I don't believe it is wise or feasible to withhold ManifoldCF from the community. > As Sebb points out, you really, really, must not push your modified > binaries to maven central unless you use shade or equivalent to change > the package names. > I would never do that, obviously. > I wish that others would weigh in here; how bad an idea is a > 'convenience binary' consisting of a modified Apache project library? > >> - jetty 6.1 > > As a courtesy to the Jetty project, the same rule of 'don't stick this > out into maven as a standalone artifact' applies. Otherwise, the > two-pronged approach is fine: make convenience binaries, and also > provide the user with the ability to rebuild them for themselves. I'd > propose the 'whole file replacement' mechanism here as well to solve > the Windows problem. > Actually it occurred to me that since there are published binary releases of these artifacts, I can download and unpack those. So I think I have a solution for this one. Karl >> >> We also build the jdk1.5 version of hsqldb, which does not require >> patching but does require recompilation. > > That's simple enough as a -dep convenience binary. > >> >> I believe all of these are covered by the Apache 2.0 license. >> >> Karl >> >> On Mon, Apr 2, 2012 at 2:14 PM, sebb wrote: >>> On 2 April 2012 17:53, Benson Margulies wrote: Karl, I hope that you are making this too hard. We don't care about the contents of someone else's binaries. If you make and deploy a -deps package of third-party binaries, as a convenience for your users, it can contain any strange mixture of sources and binaries it contains. If you provide a script to download a third-party package, we don't care what it downloads so long as the license is acceptable for a dependency. I don't follow the logic that prevents you from having a release manager: a) retrieve third-part sources b) apply your patches from your svn c) create -deps bundle d) deploy to dist, appropriately marked as 'not an Apache release', so long as the third-party material has an acceptable license in the first place. >>> >>> I would add: >>> >>> We should not publish patched builds of source in such a way that they >>> can interfere with the normal use of the unpatched source builds. >>> This includes (but is not limited to) publishing patched binaries on >>> Maven Central (regardless of the groupId) with the original package >>> names. >>> >>> Since the 3rd-party material is consumed in source code form, I assume >>> it must have a source-compatible license. >>> I.e. a license which is only normally permitted for binary >>> dependencies would I think be excluded for this use case. >>> In case I'm wrong here, I'll ask: what is the build tool of choice for ManifoldCF? On the other hand from all of these, perhaps there is, or could be, a plugin for that build tool that could implement the 'patch' utility for you on Windows? On Mon, Apr 2, 2012 at 12:37 PM, Karl Wright wrote: > Sorry about the list cc'ing - the gmail client is fighting me today. > > To try and clarify, whi
Re: Question about downloading binaries
On Mon, Apr 2, 2012 at 2:19 PM, Karl Wright wrote: > "Since the 3rd-party material is consumed in source code form, I assume > it must have a source-compatible license." > > The releases we patch are: > > - commons-httpclient 3.1 > - xerces 2.9.1 Uh, oh. Now we have another problem, since these are your fellow Apache people at work. Have you submitted patches back to commons and xerces? What sort of reaction did you get? Releasing 'convenience binaries' of modified sources of Apache projects strikes me as somewhat contrary to the overall goals here. I'd like others to weigh in here, but I'd propose that you always ship modified Apache products as source. Forget about 'patch'. Just ship modified sources files and drop them into place in fetched copies of their releases, and build the results. As Sebb points out, you really, really, must not push your modified binaries to maven central unless you use shade or equivalent to change the package names. I wish that others would weigh in here; how bad an idea is a 'convenience binary' consisting of a modified Apache project library? > - jetty 6.1 As a courtesy to the Jetty project, the same rule of 'don't stick this out into maven as a standalone artifact' applies. Otherwise, the two-pronged approach is fine: make convenience binaries, and also provide the user with the ability to rebuild them for themselves. I'd propose the 'whole file replacement' mechanism here as well to solve the Windows problem. > > We also build the jdk1.5 version of hsqldb, which does not require > patching but does require recompilation. That's simple enough as a -dep convenience binary. > > I believe all of these are covered by the Apache 2.0 license. > > Karl > > On Mon, Apr 2, 2012 at 2:14 PM, sebb wrote: >> On 2 April 2012 17:53, Benson Margulies wrote: >>> Karl, >>> >>> I hope that you are making this too hard. >>> >>> We don't care about the contents of someone else's binaries. If you >>> make and deploy a -deps package of third-party binaries, as a >>> convenience for your users, it can contain any strange mixture of >>> sources and binaries it contains. If you provide a script to download >>> a third-party package, we don't care what it downloads so long as the >>> license is acceptable for a dependency. >>> >>> I don't follow the logic that prevents you from having a release manager: >>> >>> a) retrieve third-part sources >>> b) apply your patches from your svn >>> c) create -deps bundle >>> d) deploy to dist, appropriately marked as 'not an Apache release', >>> >>> so long as the third-party material has an acceptable license in the >>> first place. >> >> I would add: >> >> We should not publish patched builds of source in such a way that they >> can interfere with the normal use of the unpatched source builds. >> This includes (but is not limited to) publishing patched binaries on >> Maven Central (regardless of the groupId) with the original package >> names. >> >> Since the 3rd-party material is consumed in source code form, I assume >> it must have a source-compatible license. >> I.e. a license which is only normally permitted for binary >> dependencies would I think be excluded for this use case. >> >>> In case I'm wrong here, I'll ask: what is the build tool of choice for >>> ManifoldCF? On the other hand from all of these, perhaps there is, or >>> could be, a plugin for that build tool that could implement the >>> 'patch' utility for you on Windows? >>> >>> >>> >>> On Mon, Apr 2, 2012 at 12:37 PM, Karl Wright wrote: Sorry about the list cc'ing - the gmail client is fighting me today. To try and clarify, which will take some time I'm afraid: (1) The 0.5 version of the ManifoldCF release candidate was rejected because the tar contained binary dependencies. The binary dependencies were checked into svn. This has been standard practice for a decade or more for Java projects built with ant, but has now been deemed unacceptable. (2) In trying to find a solution which would still be convenient but not include binaries, we considered supplying ant logic that downloads the dependencies on demand. The download would use binaries from the Maven repository, where possible. (3) In some cases, there is either no corresponding jar in the Maven repository, or there is a jar but it doesn't include critical patches. (4) In these cases, we needed to see whether there was another place those dependent jars could live. They were in svn before, so one possibility was that they remain there. Other possibilities include putting them into a googlecode repository, or downloading and building them as part of the overall build process. Hope this helps. Karl On Mon, Apr 2, 2012 at 12:26 PM, Daniel Shahaf wrote: > Forward to list > > I can't answer your question as it's too abstract. I don't understand > what you're t
Re: Question about downloading binaries
"Since the 3rd-party material is consumed in source code form, I assume it must have a source-compatible license." The releases we patch are: - commons-httpclient 3.1 - xerces 2.9.1 - jetty 6.1 We also build the jdk1.5 version of hsqldb, which does not require patching but does require recompilation. I believe all of these are covered by the Apache 2.0 license. Karl On Mon, Apr 2, 2012 at 2:14 PM, sebb wrote: > On 2 April 2012 17:53, Benson Margulies wrote: >> Karl, >> >> I hope that you are making this too hard. >> >> We don't care about the contents of someone else's binaries. If you >> make and deploy a -deps package of third-party binaries, as a >> convenience for your users, it can contain any strange mixture of >> sources and binaries it contains. If you provide a script to download >> a third-party package, we don't care what it downloads so long as the >> license is acceptable for a dependency. >> >> I don't follow the logic that prevents you from having a release manager: >> >> a) retrieve third-part sources >> b) apply your patches from your svn >> c) create -deps bundle >> d) deploy to dist, appropriately marked as 'not an Apache release', >> >> so long as the third-party material has an acceptable license in the >> first place. > > I would add: > > We should not publish patched builds of source in such a way that they > can interfere with the normal use of the unpatched source builds. > This includes (but is not limited to) publishing patched binaries on > Maven Central (regardless of the groupId) with the original package > names. > > Since the 3rd-party material is consumed in source code form, I assume > it must have a source-compatible license. > I.e. a license which is only normally permitted for binary > dependencies would I think be excluded for this use case. > >> In case I'm wrong here, I'll ask: what is the build tool of choice for >> ManifoldCF? On the other hand from all of these, perhaps there is, or >> could be, a plugin for that build tool that could implement the >> 'patch' utility for you on Windows? >> >> >> >> On Mon, Apr 2, 2012 at 12:37 PM, Karl Wright wrote: >>> Sorry about the list cc'ing - the gmail client is fighting me today. >>> >>> To try and clarify, which will take some time I'm afraid: >>> >>> (1) The 0.5 version of the ManifoldCF release candidate was rejected >>> because the tar contained binary dependencies. The binary >>> dependencies were checked into svn. This has been standard practice >>> for a decade or more for Java projects built with ant, but has now >>> been deemed unacceptable. >>> (2) In trying to find a solution which would still be convenient but >>> not include binaries, we considered supplying ant logic that downloads >>> the dependencies on demand. The download would use binaries from the >>> Maven repository, where possible. >>> (3) In some cases, there is either no corresponding jar in the Maven >>> repository, or there is a jar but it doesn't include critical patches. >>> (4) In these cases, we needed to see whether there was another place >>> those dependent jars could live. They were in svn before, so one >>> possibility was that they remain there. Other possibilities include >>> putting them into a googlecode repository, or downloading and building >>> them as part of the overall build process. >>> >>> >>> >>> Hope this helps. >>> Karl >>> >>> >>> On Mon, Apr 2, 2012 at 12:26 PM, Daniel Shahaf >>> wrote: Forward to list I can't answer your question as it's too abstract. I don't understand what you're trying to do from either infra@ or legal@ perspective. Karl Wright wrote on Mon, Apr 02, 2012 at 12:21:17 -0400: > "'svn patch' exists in 1.7." > > Ok, so that implies that we would create the patched jar by checking > out the project tag from svn and using svn patch, not by downloading > the source tarball. Do you think it is ok to allow svn access as part > of a project's build process? > > Karl > > > On Mon, Apr 2, 2012 at 12:16 PM, Daniel Shahaf > wrote: > > 'svn patch' exists in 1.7. (and tortoise includes svn.exe as an > > optional component, I hear) > > > > Karl Wright wrote on Mon, Apr 02, 2012 at 12:05:47 -0400: > >> The patches are contained in SVN, yes, but the build process is > >> structured to work on Windows as well as Linux, and there isn't a > >> standard patch utility on Windows. > >> > >> We could insist that people only build on Linux, I suppose, but that > >> would be a huge inconvenience for a lot of people. > >> > >> Karl > >> > >> On Mon, Apr 2, 2012 at 11:47 AM, sebb wrote: > >> > On 2 April 2012 16:36, Karl Wright wrote: > >> >> -- Forwarded message -- > >> >> From: Daniel Shahaf > >> >> Date: Mon, Apr 2, 2012 at 11:35 AM > >> >> Subject: Re: Question about downloading binaries > >> >> To: Karl Wright > >> >> > >
Re: Question about downloading binaries
On 2 April 2012 17:53, Benson Margulies wrote: > Karl, > > I hope that you are making this too hard. > > We don't care about the contents of someone else's binaries. If you > make and deploy a -deps package of third-party binaries, as a > convenience for your users, it can contain any strange mixture of > sources and binaries it contains. If you provide a script to download > a third-party package, we don't care what it downloads so long as the > license is acceptable for a dependency. > > I don't follow the logic that prevents you from having a release manager: > > a) retrieve third-part sources > b) apply your patches from your svn > c) create -deps bundle > d) deploy to dist, appropriately marked as 'not an Apache release', > > so long as the third-party material has an acceptable license in the > first place. I would add: We should not publish patched builds of source in such a way that they can interfere with the normal use of the unpatched source builds. This includes (but is not limited to) publishing patched binaries on Maven Central (regardless of the groupId) with the original package names. Since the 3rd-party material is consumed in source code form, I assume it must have a source-compatible license. I.e. a license which is only normally permitted for binary dependencies would I think be excluded for this use case. > In case I'm wrong here, I'll ask: what is the build tool of choice for > ManifoldCF? On the other hand from all of these, perhaps there is, or > could be, a plugin for that build tool that could implement the > 'patch' utility for you on Windows? > > > > On Mon, Apr 2, 2012 at 12:37 PM, Karl Wright wrote: >> Sorry about the list cc'ing - the gmail client is fighting me today. >> >> To try and clarify, which will take some time I'm afraid: >> >> (1) The 0.5 version of the ManifoldCF release candidate was rejected >> because the tar contained binary dependencies. The binary >> dependencies were checked into svn. This has been standard practice >> for a decade or more for Java projects built with ant, but has now >> been deemed unacceptable. >> (2) In trying to find a solution which would still be convenient but >> not include binaries, we considered supplying ant logic that downloads >> the dependencies on demand. The download would use binaries from the >> Maven repository, where possible. >> (3) In some cases, there is either no corresponding jar in the Maven >> repository, or there is a jar but it doesn't include critical patches. >> (4) In these cases, we needed to see whether there was another place >> those dependent jars could live. They were in svn before, so one >> possibility was that they remain there. Other possibilities include >> putting them into a googlecode repository, or downloading and building >> them as part of the overall build process. >> >> >> >> Hope this helps. >> Karl >> >> >> On Mon, Apr 2, 2012 at 12:26 PM, Daniel Shahaf >> wrote: >>> Forward to list >>> >>> I can't answer your question as it's too abstract. I don't understand >>> what you're trying to do from either infra@ or legal@ perspective. >>> >>> Karl Wright wrote on Mon, Apr 02, 2012 at 12:21:17 -0400: "'svn patch' exists in 1.7." Ok, so that implies that we would create the patched jar by checking out the project tag from svn and using svn patch, not by downloading the source tarball. Do you think it is ok to allow svn access as part of a project's build process? Karl On Mon, Apr 2, 2012 at 12:16 PM, Daniel Shahaf wrote: > 'svn patch' exists in 1.7. (and tortoise includes svn.exe as an > optional component, I hear) > > Karl Wright wrote on Mon, Apr 02, 2012 at 12:05:47 -0400: >> The patches are contained in SVN, yes, but the build process is >> structured to work on Windows as well as Linux, and there isn't a >> standard patch utility on Windows. >> >> We could insist that people only build on Linux, I suppose, but that >> would be a huge inconvenience for a lot of people. >> >> Karl >> >> On Mon, Apr 2, 2012 at 11:47 AM, sebb wrote: >> > On 2 April 2012 16:36, Karl Wright wrote: >> >> -- Forwarded message -- >> >> From: Daniel Shahaf >> >> Date: Mon, Apr 2, 2012 at 11:35 AM >> >> Subject: Re: Question about downloading binaries >> >> To: Karl Wright >> >> >> >> >> >> You didn't CC the list >> >> >> >> Karl Wright wrote on Mon, Apr 02, 2012 at 11:33:56 -0400: >> >>> The patches for the dependencies for the main release are sourced >> >>> only >> >>> as part of the project in question at this time. So there is no >> >>> other >> >>> logical place for them to live. >> > >> > The project SVN presumably contains the patches? >> > If not, it should. >> > >> > In which case, can't you download the source and apply the patches as
[ANNOUNCE] Apache Bigtop (incubating) 0.3.0 released
Greetings, The Apache Bigtop team is pleased to announce the release of version 0.3.0 from the Apache Incubator: a first ever 100% open-source Apache Hadoop 1.0 based big data stack! For a list of issues resolved in this version, please see the release notes: http://incubator.apache.org/bigtop/release-notes.html The most recent release can be obtained from our download page: http://www.apache.org/dyn/closer.cgi/incubator/bigtop/ For installing binary distribution of Bigtop data management stack, please follow our Installation Guide: https://cwiki.apache.org/confluence/display/BIGTOP/How+to+install+Hadoop+distribution+from+Bigtop For general information on Apache Bigtop, please visit the project website: http://incubator.apache.org/bigtop Disclaimer: Apache Bigtop is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. Regards, Bigtop 0.3.0 (incubating) release manager. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about downloading binaries
We use ant. Ant simply invokes the patch utility, as described here: http://ant.1045680.n5.nabble.com/Patch-task-td1354764.html Karl On Mon, Apr 2, 2012 at 12:53 PM, Benson Margulies wrote: > Karl, > > I hope that you are making this too hard. > > We don't care about the contents of someone else's binaries. If you > make and deploy a -deps package of third-party binaries, as a > convenience for your users, it can contain any strange mixture of > sources and binaries it contains. If you provide a script to download > a third-party package, we don't care what it downloads so long as the > license is acceptable for a dependency. > > I don't follow the logic that prevents you from having a release manager: > > a) retrieve third-part sources > b) apply your patches from your svn > c) create -deps bundle > d) deploy to dist, appropriately marked as 'not an Apache release', > > so long as the third-party material has an acceptable license in the > first place. > > In case I'm wrong here, I'll ask: what is the build tool of choice for > ManifoldCF? On the other hand from all of these, perhaps there is, or > could be, a plugin for that build tool that could implement the > 'patch' utility for you on Windows? > > > > On Mon, Apr 2, 2012 at 12:37 PM, Karl Wright wrote: >> Sorry about the list cc'ing - the gmail client is fighting me today. >> >> To try and clarify, which will take some time I'm afraid: >> >> (1) The 0.5 version of the ManifoldCF release candidate was rejected >> because the tar contained binary dependencies. The binary >> dependencies were checked into svn. This has been standard practice >> for a decade or more for Java projects built with ant, but has now >> been deemed unacceptable. >> (2) In trying to find a solution which would still be convenient but >> not include binaries, we considered supplying ant logic that downloads >> the dependencies on demand. The download would use binaries from the >> Maven repository, where possible. >> (3) In some cases, there is either no corresponding jar in the Maven >> repository, or there is a jar but it doesn't include critical patches. >> (4) In these cases, we needed to see whether there was another place >> those dependent jars could live. They were in svn before, so one >> possibility was that they remain there. Other possibilities include >> putting them into a googlecode repository, or downloading and building >> them as part of the overall build process. >> >> >> >> Hope this helps. >> Karl >> >> >> On Mon, Apr 2, 2012 at 12:26 PM, Daniel Shahaf >> wrote: >>> Forward to list >>> >>> I can't answer your question as it's too abstract. I don't understand >>> what you're trying to do from either infra@ or legal@ perspective. >>> >>> Karl Wright wrote on Mon, Apr 02, 2012 at 12:21:17 -0400: "'svn patch' exists in 1.7." Ok, so that implies that we would create the patched jar by checking out the project tag from svn and using svn patch, not by downloading the source tarball. Do you think it is ok to allow svn access as part of a project's build process? Karl On Mon, Apr 2, 2012 at 12:16 PM, Daniel Shahaf wrote: > 'svn patch' exists in 1.7. (and tortoise includes svn.exe as an > optional component, I hear) > > Karl Wright wrote on Mon, Apr 02, 2012 at 12:05:47 -0400: >> The patches are contained in SVN, yes, but the build process is >> structured to work on Windows as well as Linux, and there isn't a >> standard patch utility on Windows. >> >> We could insist that people only build on Linux, I suppose, but that >> would be a huge inconvenience for a lot of people. >> >> Karl >> >> On Mon, Apr 2, 2012 at 11:47 AM, sebb wrote: >> > On 2 April 2012 16:36, Karl Wright wrote: >> >> -- Forwarded message -- >> >> From: Daniel Shahaf >> >> Date: Mon, Apr 2, 2012 at 11:35 AM >> >> Subject: Re: Question about downloading binaries >> >> To: Karl Wright >> >> >> >> >> >> You didn't CC the list >> >> >> >> Karl Wright wrote on Mon, Apr 02, 2012 at 11:33:56 -0400: >> >>> The patches for the dependencies for the main release are sourced >> >>> only >> >>> as part of the project in question at this time. So there is no >> >>> other >> >>> logical place for them to live. >> > >> > The project SVN presumably contains the patches? >> > If not, it should. >> > >> > In which case, can't you download the source and apply the patches as >> > part of the build process? >> > >> > This is what the Tomcat project does (though it's not changing code, >> > just changing package names to avoid collisions). >> > >> >>> Karl >> >>> >> >>> On Mon, Apr 2, 2012 at 11:31 AM, Daniel Shahaf >> >>> wrote: >> >>> > Why do they have to be hosted on Apache infrastructure? The
Re: Question about downloading binaries
Karl, I hope that you are making this too hard. We don't care about the contents of someone else's binaries. If you make and deploy a -deps package of third-party binaries, as a convenience for your users, it can contain any strange mixture of sources and binaries it contains. If you provide a script to download a third-party package, we don't care what it downloads so long as the license is acceptable for a dependency. I don't follow the logic that prevents you from having a release manager: a) retrieve third-part sources b) apply your patches from your svn c) create -deps bundle d) deploy to dist, appropriately marked as 'not an Apache release', so long as the third-party material has an acceptable license in the first place. In case I'm wrong here, I'll ask: what is the build tool of choice for ManifoldCF? On the other hand from all of these, perhaps there is, or could be, a plugin for that build tool that could implement the 'patch' utility for you on Windows? On Mon, Apr 2, 2012 at 12:37 PM, Karl Wright wrote: > Sorry about the list cc'ing - the gmail client is fighting me today. > > To try and clarify, which will take some time I'm afraid: > > (1) The 0.5 version of the ManifoldCF release candidate was rejected > because the tar contained binary dependencies. The binary > dependencies were checked into svn. This has been standard practice > for a decade or more for Java projects built with ant, but has now > been deemed unacceptable. > (2) In trying to find a solution which would still be convenient but > not include binaries, we considered supplying ant logic that downloads > the dependencies on demand. The download would use binaries from the > Maven repository, where possible. > (3) In some cases, there is either no corresponding jar in the Maven > repository, or there is a jar but it doesn't include critical patches. > (4) In these cases, we needed to see whether there was another place > those dependent jars could live. They were in svn before, so one > possibility was that they remain there. Other possibilities include > putting them into a googlecode repository, or downloading and building > them as part of the overall build process. > > > > Hope this helps. > Karl > > > On Mon, Apr 2, 2012 at 12:26 PM, Daniel Shahaf > wrote: >> Forward to list >> >> I can't answer your question as it's too abstract. I don't understand >> what you're trying to do from either infra@ or legal@ perspective. >> >> Karl Wright wrote on Mon, Apr 02, 2012 at 12:21:17 -0400: >>> "'svn patch' exists in 1.7." >>> >>> Ok, so that implies that we would create the patched jar by checking >>> out the project tag from svn and using svn patch, not by downloading >>> the source tarball. Do you think it is ok to allow svn access as part >>> of a project's build process? >>> >>> Karl >>> >>> >>> On Mon, Apr 2, 2012 at 12:16 PM, Daniel Shahaf >>> wrote: >>> > 'svn patch' exists in 1.7. (and tortoise includes svn.exe as an >>> > optional component, I hear) >>> > >>> > Karl Wright wrote on Mon, Apr 02, 2012 at 12:05:47 -0400: >>> >> The patches are contained in SVN, yes, but the build process is >>> >> structured to work on Windows as well as Linux, and there isn't a >>> >> standard patch utility on Windows. >>> >> >>> >> We could insist that people only build on Linux, I suppose, but that >>> >> would be a huge inconvenience for a lot of people. >>> >> >>> >> Karl >>> >> >>> >> On Mon, Apr 2, 2012 at 11:47 AM, sebb wrote: >>> >> > On 2 April 2012 16:36, Karl Wright wrote: >>> >> >> -- Forwarded message -- >>> >> >> From: Daniel Shahaf >>> >> >> Date: Mon, Apr 2, 2012 at 11:35 AM >>> >> >> Subject: Re: Question about downloading binaries >>> >> >> To: Karl Wright >>> >> >> >>> >> >> >>> >> >> You didn't CC the list >>> >> >> >>> >> >> Karl Wright wrote on Mon, Apr 02, 2012 at 11:33:56 -0400: >>> >> >>> The patches for the dependencies for the main release are sourced >>> >> >>> only >>> >> >>> as part of the project in question at this time. So there is no >>> >> >>> other >>> >> >>> logical place for them to live. >>> >> > >>> >> > The project SVN presumably contains the patches? >>> >> > If not, it should. >>> >> > >>> >> > In which case, can't you download the source and apply the patches as >>> >> > part of the build process? >>> >> > >>> >> > This is what the Tomcat project does (though it's not changing code, >>> >> > just changing package names to avoid collisions). >>> >> > >>> >> >>> Karl >>> >> >>> >>> >> >>> On Mon, Apr 2, 2012 at 11:31 AM, Daniel Shahaf >>> >> >>> wrote: >>> >> >>> > Why do they have to be hosted on Apache infrastructure? The >>> >> >>> > Subversion >>> >> >>> > build depends on a C compiler but we don't host that on ASF >>> >> >>> > hardware. >>> >> >>> > >>> >> >>> > Karl Wright wrote on Mon, Apr 02, 2012 at 11:16:22 -0400: >>> >> >>> >> Hi folks, >>> >> >>> >> >>> >> >>> >> As a result of a change in the way Java releases must be >>> >> >>> >> struc
VXQuery status (Was: [Incubator Wiki] Update of "April2012" by TillWestmann)
Hi, Thanks for the report, VXQuery! On Mon, Apr 2, 2012 at 5:26 AM, Apache Wiki wrote: > + * change of the focus of the project (the previous focus was to be > + flexible wrt the representation of the data model, the new focus > + is parallel processing of large amounts of XML data) > + * re-newed development activity I see a single "VXQuery focus" thread on vxquery-dev@ and a handful of related commits, but the activity on those seems rather to decline than increase over time. So looking at the project from the outside it unfortunately doesn't seem like the new focus is yet helping re-activate the project. Do you expect this to change over the next few months? Does VXQuery have concrete plans on how to drive the new focus forward? If yes, is help from the larger Incubator community or ComDev needed? > + * 2 proposals for GSoC (1 person expressed interest in working on > + VXQuery for GSoC) I'm concerned about starting a GSoC project on a codebase without an active community. GSoC students are supposed to be working with the community, not *be* the community. Have you talked about this with ComDev? PS. VXQuery has four mentors listed: Paul Fremantle, Sanjiva Weerawarana, Radu Preotiuc-Pietro, and Jochen Wiedmann. I only see Jochen interacting with the community on vxquery-dev@ over the past two years. Are the other mentors still actively following the project? BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPC] [VOTE] Graduate Apache Jena as a Top Level Project
On Mon, Apr 2, 2012 at 11:10 AM, Andy Seaborne wrote: > ...We ask that the IPMC approve this graduation request though this VOTE. [X ] +1 Recommend to the ASF Board that Apache Jena Proposal is ready to graduate to being a top level project. And congrats! -Bertrand (Jena mentor) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[IMPC] [VOTE] Graduate Apache Jena as a Top Level Project
This is a call for vote to graduate the Apache Jena podling from Apache Incubator to be a top level project. Jena entered incubation in November 2010. The project has added two new committers and PPMC members, made several releases and has a diverse committer base. The user and development communities are active. The PPMC has indicated [1,2,3] that it believes the project is ready to graduate as a top-level project with the resolution draft below. We ask that the IPMC approve this graduation request though this VOTE. [1] Vote: http://s.apache.org/jena-graduation-vote [2] Result: http://s.apache.org/jena-graduation [3] Request for comments: http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3C5C4A33CB-B122-43A8-B082-CBD63B526DE7%40cray.com%3E On behalf of the Apache Jena PPMC, Andy - [ ] +1 Recommend to the ASF Board that Apache Jena Proposal is ready to graduate to being a top level project. [ ] 0 [ ] -1 Do not graduate Apache Jena because ... The vote will be tallied no earlier than: Thursday April 5th, at 23:59 UTC. - X. Establish the Apache Jena Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to accessing, storing, querying, publishing and reasoning with semantic web data while adhering to relevant W3C and community standards. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Apache Jena Project", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Jena Project be and hereby is responsible for the creation and maintenance of software related to accessing, storing, querying, publishing and reasoning with semantic web data while adhering to relevant W3C and community standards; and be it further RESOLVED, that the office of "Vice President, Apache Jena" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Jena Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Jena Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Jena Project: * Andy Seaborne (andy) * Benson Marguilies (bimargulies) * Chris Dollin (chrisdollin) * Damian Steer (damian) * Dave Reynolds (der) * Ian Dickinson (ijd) * Paolo Castagna (castagna) * Rob Vesse (rvesse) * Stephen Allen (sallen) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andy Seaborne be appointed to the office of Vice President, Apache Jena, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Jena PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Jena Project; and be it further RESOLVED, that the Apache Jena Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Jena podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Jena podling encumbered upon the Apache Incubator Project are hereafter discharged. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
