Re: [IP CLEARANCE] Atomos Codebase
I updated it to mention the SGA - not sure when the refresh will happen. regards, Karl On Fri, Feb 14, 2020 at 10:28 PM Justin Mclean wrote: > > HI, > > > given that we have an SGA from IBM now I'll assume that your concerns > > are addressed - please let me know if that is not the case. > > I don’t see these details recorded here [1] > > Thanks, > Justin > > 1. https://incubator.apache.org/ip-clearance/felix-atomos.html > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][IP CLEARANCE] Atomos Codebase
After clearing up some questions and getting an SGA from IBM to make sure, the IP Clearance of the "Atomos Codebase" contribution passes. We will proceed to incorporate the code in Felix. regards, Karl -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] Atomos Codebase
Hi Justin, given that we have an SGA from IBM now I'll assume that your concerns are addressed - please let me know if that is not the case. regards, Karl On Tue, Feb 11, 2020 at 9:42 AM Justin Mclean wrote: > > Hi, > > -1 until the following is cleared up. > > I can see that until a month ago it was under the EPL license. Did all of the > contributors agree to the license change? > > It also seems that the code was copyright is IBM. Have they given permission > for this software to be donated or license headers to be changed? It looks > like the SGA may need to come from them. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] Atomos Codebase
> > I think the problem at the root is the fact that the code was relicensed, > > removing IBM specific headers. If the code never had IBM licensing on it, > > this would be a very easy +1 but because of the relicensing, it's a -1 from > > me until we get an SGA from IBM. > > I'll talk with Tom about it and get back to you. I discussed it with Tom and since he did have the internal clearance he figured it would be easiest to just get an SGA from IBM. It has just been received by secretary (its in the grants.txt) and gives us card blanche for https://github.com/tjwatson/atomos. John and Justin, does this address your concerns? regards, Karl - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] Atomos Codebase
On Tue, Feb 11, 2020 at 2:04 PM John D. Ament wrote: > > CCLAs simply tell us that a company is aware that their employees are > contributing to ASF projects. They don't really help much in the way of > getting code transitioned here. > > I think the problem at the root is the fact that the code was relicensed, > removing IBM specific headers. If the code never had IBM licensing on it, > this would be a very easy +1 but because of the relicensing, it's a -1 from > me until we get an SGA from IBM. I'll talk with Tom about it and get back to you. > Do we have an ICLA from Stefan Bischof as > well? It looks like his contributions are post-relicensing but wanted to > check. Yes, we have an ICLA form Stefan Bischof. regards, Karl > John > > On Tue, Feb 11, 2020 at 5:08 AM Karl Pauls wrote: > > > Let me try to rephrase that: > > > > The project has been done by Thomas Watson who has an iCLA, works for > > IBM, and is a Felix PMC. I was assuming that would be enough to have > > him be able to contribute this code. If we think we want something > > more like a specific SGA or CCLA from IBM than I can try to work with > > him on that. Is that what we want? > > > > regards, > > > > Karl > > > > On Tue, Feb 11, 2020 at 10:18 AM Karl Pauls wrote: > > > > > > On Tue, Feb 11, 2020 at 10:05 AM Justin Mclean > > > wrote: > > > > > > > > Hi, > > > > > > > > > Thomas Watson is from IBM and should be covered by their CCLA and has > > > > > an iCLA on file. > > > > > > > > Nope a CCLA is not a blanket permission to donate this code if it is > > copyright IBM. > > > > > > I think we've been here before - so what would you think is required? > > > We have an iCLA and we have an CCLA from IBM but you want a more > > > specific one? > > > > > > regards, > > > > > > Karl > > > > > > > > > > Thanks, > > > > Justin > > > > - > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > -- > > > Karl Pauls > > > karlpa...@gmail.com > > > > > > > > -- > > Karl Pauls > > karlpa...@gmail.com > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] Atomos Codebase
Let me try to rephrase that: The project has been done by Thomas Watson who has an iCLA, works for IBM, and is a Felix PMC. I was assuming that would be enough to have him be able to contribute this code. If we think we want something more like a specific SGA or CCLA from IBM than I can try to work with him on that. Is that what we want? regards, Karl On Tue, Feb 11, 2020 at 10:18 AM Karl Pauls wrote: > > On Tue, Feb 11, 2020 at 10:05 AM Justin Mclean > wrote: > > > > Hi, > > > > > Thomas Watson is from IBM and should be covered by their CCLA and has > > > an iCLA on file. > > > > Nope a CCLA is not a blanket permission to donate this code if it is > > copyright IBM. > > I think we've been here before - so what would you think is required? > We have an iCLA and we have an CCLA from IBM but you want a more > specific one? > > regards, > > Karl > > > > Thanks, > > Justin > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > -- > Karl Pauls > karlpa...@gmail.com -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] Atomos Codebase
On Tue, Feb 11, 2020 at 10:05 AM Justin Mclean wrote: > > Hi, > > > Thomas Watson is from IBM and should be covered by their CCLA and has > > an iCLA on file. > > Nope a CCLA is not a blanket permission to donate this code if it is > copyright IBM. I think we've been here before - so what would you think is required? We have an iCLA and we have an CCLA from IBM but you want a more specific one? regards, Karl > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] Atomos Codebase
On Tue, Feb 11, 2020 at 10:09 AM Justin Mclean wrote: > > Hi, > > > I'm not sure how that follows - which code is EPL? > > Several pieces of code in the repo still have headers that claim IBM is the > copyright holder and under EPL license. I can't see any code - there are only some profiles that contain that notice. regards, Karl > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] Atomos Codebase
On Tue, Feb 11, 2020 at 9:49 AM Justin Mclean wrote: > > Hi, > > BTW if the code in general is not from IBM then it contains code that is and > is licensed EPL, that can’t be included in an ASF source release so I would > be -1 on those grounds. I'm not sure how that follows - which code is EPL? Anyways, the code is from an IBM employee that got clearance to contribute it to Apache. regards, Karl > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] Atomos Codebase
On Tue, Feb 11, 2020 at 9:42 AM Justin Mclean wrote: > > Hi, > > -1 until the following is cleared up. > > I can see that until a month ago it was under the EPL license. Did all of the > contributors agree to the license change? The main contributor is Thomas Watson (who did the change) - there is very little contribution from somebody else in the first place. However, if we want to go through we have Raymond Auge who voted on the contribution acceptance, Stefan Bischof who agreed to the contribution as is and submitted an icla for it, and one commit from Samuel E Bratton. > It also seems that the code was copyright is IBM. Have they given permission > for this software to be donated or license headers to be changed? It looks > like the SGA may need to come from them. Thomas Watson is from IBM and should be covered by their CCLA and has an iCLA on file. regards, Karl > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[IP CLEARANCE] Atomos Codebase
The Apache Felix project has received an "Atomos" contribution from Thomas Watson. Atomos is a Java module framework using OSGi Connect which is a proposal (RFC) for the upcoming OSGI R8 Core specification. - A snapshot of the code, that is already ALv2, is available in a github repo: [0] - The IP Clearance form has been committed [1] - The acceptance vote has passed on the d...@felix.apache.org mailing list [2] The clearance passes by lazy consensus if no -1 votes are cast within the next 72 hours. regards, Karl [0] https://github.com/tjwatson/atomos [1] https://incubator.apache.org/ip-clearance/felix-atomos.html [2] https://www.mail-archive.com/dev@felix.apache.org/msg49396.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn commit: r1873757 - /incubator/public/trunk/content/ip-clearance/index.xml
I did, thanks. regards, Karl On Fri, Feb 7, 2020 at 11:58 PM Dave Fisher wrote: > > +Weex UI > > > You need to fix this. > > Thanks, > Dave > > Begin forwarded message: > > From: pa...@apache.org > Subject: svn commit: r1873757 - > /incubator/public/trunk/content/ip-clearance/index.xml > Date: February 7, 2020 at 5:28:20 PM EST > To: c...@incubator.apache.org > Reply-To: general@incubator.apache.org > > Author: pauls > Date: Fri Feb 7 22:28:20 2020 > New Revision: 1873757 > > URL: http://svn.apache.org/viewvc?rev=1873757=rev > Log: > Add the Apache Felix Atomos contribution ip-clearance form. > > Modified: >incubator/public/trunk/content/ip-clearance/index.xml > > Modified: incubator/public/trunk/content/ip-clearance/index.xml > URL: > http://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/index.xml?rev=1873757=1873756=1873757=diff > == > --- incubator/public/trunk/content/ip-clearance/index.xml [utf-8] (original) > +++ incubator/public/trunk/content/ip-clearance/index.xml [utf-8] Fri Feb 7 > 22:28:20 2020 > @@ -48,6 +48,13 @@ > > > > +Weex UI > + > +Apache Felix > +2020-02-07 > + > + > + > Weex UI > > Apache Weex (Incubating) > > > > ----- > To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org > For additional commands, e-mail: cvs-h...@incubator.apache.org > > -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][IP CLEARANCE] Logback integration with OSGi Log 1.4
IP Clearance of the "Logback integration with OSGi Log 1.4" contribution passes by lazy consensus. We will proceed to incorporate the code in Felix. regards, Karl On Fri, May 4, 2018 at 10:01 PM, Karl Pauls <karlpa...@gmail.com> wrote: > The Apache Felix project has received a "Logback integration with OSGi > Log 1.4" contribution from Raymond Auge. > > - A snapshot of the code is available in a github repo: [0] > - The IP Clearance form has been committed [1] > - The acceptance vote has passed on the d...@felix.apache.org mailing list [2] > > The clearance passes by lazy consensus if no -1 votes are cast within > the next 72 hours. > > regards, > > Karl > > [0] https://github.com/rotty3000/osgi.to.logback > [1] http://incubator.apache.org/ip-clearance/felix-logback-integration.html > [2] https://www.mail-archive.com/dev@felix.apache.org/msg45354.html -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][IP CLEARANCE] System Readiness Check Framework
IP Clearance of the "System Readiness Check Framework" contribution passes by lazy consensus. We will proceed to incorporate the code in Felix. regards, Karl On Fri, May 4, 2018 at 10:01 PM, Karl Pauls <karlpa...@gmail.com> wrote: > The Apache Felix project has received a "System Readiness Check > Framework" contribution from Andrei Dulvac and Christian Schneider. > > - A snapshot of the code is available in a github repo: [0] > - The IP Clearance form has been committed [1] > - The acceptance vote has passed on the d...@felix.apache.org mailing list [2] > > The clearance passes by lazy consensus if no -1 votes are cast within > the next 72 hours. > > regards, > > Karl > > [0] https://github.com/dulvac/system-readiness > [1] http://incubator.apache.org/ip-clearance/felix-system-readiness.html > [2] https://www.mail-archive.com/dev@felix.apache.org/msg45355.html -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[IP CLEARANCE] System Readiness Check Framework
The Apache Felix project has received a "System Readiness Check Framework" contribution from Andrei Dulvac and Christian Schneider. - A snapshot of the code is available in a github repo: [0] - The IP Clearance form has been committed [1] - The acceptance vote has passed on the d...@felix.apache.org mailing list [2] The clearance passes by lazy consensus if no -1 votes are cast within the next 72 hours. regards, Karl [0] https://github.com/dulvac/system-readiness [1] http://incubator.apache.org/ip-clearance/felix-system-readiness.html [2] https://www.mail-archive.com/dev@felix.apache.org/msg45355.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[IP CLEARANCE] Logback integration with OSGi Log 1.4
The Apache Felix project has received a "Logback integration with OSGi Log 1.4" contribution from Raymond Auge. - A snapshot of the code is available in a github repo: [0] - The IP Clearance form has been committed [1] - The acceptance vote has passed on the d...@felix.apache.org mailing list [2] The clearance passes by lazy consensus if no -1 votes are cast within the next 72 hours. regards, Karl [0] https://github.com/rotty3000/osgi.to.logback [1] http://incubator.apache.org/ip-clearance/felix-logback-integration.html [2] https://www.mail-archive.com/dev@felix.apache.org/msg45354.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][IP CLEARANCE] Apache Felix Bundle Archive File Installer Extension
As we waited another 72 hours and no -1 has been cast the ip clearance has been accepted and we will proceed to incorporate the code in Felix. regards, Karl On Wed, Feb 14, 2018 at 11:58 AM, Karl Pauls <karlpa...@gmail.com> wrote: > Great! > > I think we can just resume this vote. I updated the ip-clearance form > and will wait another 72 hours. > > If no -1 is cast within the next 72 hours I will wrap it up and we > will accept the contribution into Felix. > > regards, > > Karl > > On Wed, Feb 14, 2018 at 12:50 AM, John D. Ament <johndam...@apache.org> wrote: >> Yes, an ICLA on file should suffice. >> >> John >> >> On Tue, Feb 13, 2018 at 5:07 PM Karl Pauls <karlpa...@gmail.com> wrote: >> >>> John, >>> >>> we have an ICLA for Jessica now. >>> >>> However, Intel is maintaining the position that it shouldn't be >>> required to identify the software granted in detail but rather stating >>> the top-level project it is granted to should be sufficient. >>> Furthermore, they argue that they have done that many times over the >>> years and only used the project level in Schedule B. >>> >>> Personally (IANAL), I think we should be good as the size of the >>> donation isn't that big, Intel claims the copyright and has clearly >>> green lighted Jessica to contribute in their name to Felix (and we >>> have an ICLA as well) - hence: >>> >>> Are you willing to withdraw your veto based on the ICLA and the given CCLA? >>> >>> Otherwise, I guess I'll go and ask legal to see if they can clear this up. >>> >>> regards, >>> >>> Karl >>> >>> >>> On Thu, Dec 14, 2017 at 2:41 PM, Karl Pauls <karlpa...@gmail.com> wrote: >>> > John, >>> > >>> > yeah, I see that the schedule B is somewhat lacking. Oh well, ok, so >>> > basically we are fine with a CCLA but in this case we don't think the >>> > provided one is explicit enough (plus we want an ICLA for Jessica >>> > Marz). >>> > >>> > I'll let them know and get back to this thread when there is either an >>> > SGA or a new CCLA with the zip name and hash + ICLA for Jessica. >>> > >>> > Thank you for looking into this! >>> > >>> > regards, >>> > >>> > Karl >>> > >>> > On Thu, Dec 14, 2017 at 2:06 PM, John D. Ament <johndam...@apache.org> >>> wrote: >>> >> Karl, >>> >> >>> >> I just read the CCLA that was filed. I do not believe it is clear >>> enough >>> >> in the schedule B that it contains to conclude what is meant to be >>> >> included. Since you're a chair, you should have access to it at >>> >> >>> https://svn.apache.org/repos/private/documents/cclas/intel-corporation-felix.pdf >>> >> >>> >> Typically, to use a schedule B (as you're noting) I would expect: >>> >> >>> >> - A zip/tar archive with checksum & md5 listed OR >>> >> - A list of files >>> >> >>> >> As well as: >>> >> >>> >> - ICLA(s) on file for the individual(s). >>> >> >>> >> So you could also do another CCLA but listing out one of those two items >>> >> above, as well as request an ICLA from Jessica Marz. >>> >> >>> >> John >>> >> >>> >> On Thu, Dec 14, 2017 at 7:08 AM Karl Pauls <karlpa...@gmail.com> wrote: >>> >> >>> >>> John, >>> >>> >>> >>> it might typically be an SGA but it does say: "This grant can either >>> >>> be done by the ASF Corporate CLA (via Schedule B) or the Software >>> >>> Grant Agreement". Should we change that wording then? >>> >>> >>> >>> Anyways, I will follow-up with Intel via Jessica and let them know >>> >>> that the provided Corporate CLA isn't sufficient and see if they can >>> >>> provide a Software Grant Agreement instead. Thanks! >>> >>> >>> >>> regards, >>> >>> >>> >>> Karl >>> >>> >>> >>> On Thu, Dec 14, 2017 at 1:01 PM, John D. Ament <johndam...@apache.org> >>> >>> wrote: >>> >>> > Karl, >>> >>> > >>> >>> >
Re: [IP CLEARANCE] Apache Felix Bundle Archive File Installer Extension
Great! I think we can just resume this vote. I updated the ip-clearance form and will wait another 72 hours. If no -1 is cast within the next 72 hours I will wrap it up and we will accept the contribution into Felix. regards, Karl On Wed, Feb 14, 2018 at 12:50 AM, John D. Ament <johndam...@apache.org> wrote: > Yes, an ICLA on file should suffice. > > John > > On Tue, Feb 13, 2018 at 5:07 PM Karl Pauls <karlpa...@gmail.com> wrote: > >> John, >> >> we have an ICLA for Jessica now. >> >> However, Intel is maintaining the position that it shouldn't be >> required to identify the software granted in detail but rather stating >> the top-level project it is granted to should be sufficient. >> Furthermore, they argue that they have done that many times over the >> years and only used the project level in Schedule B. >> >> Personally (IANAL), I think we should be good as the size of the >> donation isn't that big, Intel claims the copyright and has clearly >> green lighted Jessica to contribute in their name to Felix (and we >> have an ICLA as well) - hence: >> >> Are you willing to withdraw your veto based on the ICLA and the given CCLA? >> >> Otherwise, I guess I'll go and ask legal to see if they can clear this up. >> >> regards, >> >> Karl >> >> >> On Thu, Dec 14, 2017 at 2:41 PM, Karl Pauls <karlpa...@gmail.com> wrote: >> > John, >> > >> > yeah, I see that the schedule B is somewhat lacking. Oh well, ok, so >> > basically we are fine with a CCLA but in this case we don't think the >> > provided one is explicit enough (plus we want an ICLA for Jessica >> > Marz). >> > >> > I'll let them know and get back to this thread when there is either an >> > SGA or a new CCLA with the zip name and hash + ICLA for Jessica. >> > >> > Thank you for looking into this! >> > >> > regards, >> > >> > Karl >> > >> > On Thu, Dec 14, 2017 at 2:06 PM, John D. Ament <johndam...@apache.org> >> wrote: >> >> Karl, >> >> >> >> I just read the CCLA that was filed. I do not believe it is clear >> enough >> >> in the schedule B that it contains to conclude what is meant to be >> >> included. Since you're a chair, you should have access to it at >> >> >> https://svn.apache.org/repos/private/documents/cclas/intel-corporation-felix.pdf >> >> >> >> Typically, to use a schedule B (as you're noting) I would expect: >> >> >> >> - A zip/tar archive with checksum & md5 listed OR >> >> - A list of files >> >> >> >> As well as: >> >> >> >> - ICLA(s) on file for the individual(s). >> >> >> >> So you could also do another CCLA but listing out one of those two items >> >> above, as well as request an ICLA from Jessica Marz. >> >> >> >> John >> >> >> >> On Thu, Dec 14, 2017 at 7:08 AM Karl Pauls <karlpa...@gmail.com> wrote: >> >> >> >>> John, >> >>> >> >>> it might typically be an SGA but it does say: "This grant can either >> >>> be done by the ASF Corporate CLA (via Schedule B) or the Software >> >>> Grant Agreement". Should we change that wording then? >> >>> >> >>> Anyways, I will follow-up with Intel via Jessica and let them know >> >>> that the provided Corporate CLA isn't sufficient and see if they can >> >>> provide a Software Grant Agreement instead. Thanks! >> >>> >> >>> regards, >> >>> >> >>> Karl >> >>> >> >>> On Thu, Dec 14, 2017 at 1:01 PM, John D. Ament <johndam...@apache.org> >> >>> wrote: >> >>> > Karl, >> >>> > >> >>> > If the code is already Apache licensed, then I would check w/ >> secretary@ >> >>> or >> >>> > legal-discuss@ to confirm what documents need to be in place to >> remove >> >>> the >> >>> > Intel copyright claim (typically those would go in to the NOTICE >> file for >> >>> > Apache Felix going forward). This is typically done as an SGA [1]. >> >>> > >> >>> > John >> >>> > >> >>> > [1]: https://www.apache.org/licenses/software-grant-template.pdf >> >>> > >> >>&g
Re: [IP CLEARANCE] Apache Felix Bundle Archive File Installer Extension
John, we have an ICLA for Jessica now. However, Intel is maintaining the position that it shouldn't be required to identify the software granted in detail but rather stating the top-level project it is granted to should be sufficient. Furthermore, they argue that they have done that many times over the years and only used the project level in Schedule B. Personally (IANAL), I think we should be good as the size of the donation isn't that big, Intel claims the copyright and has clearly green lighted Jessica to contribute in their name to Felix (and we have an ICLA as well) - hence: Are you willing to withdraw your veto based on the ICLA and the given CCLA? Otherwise, I guess I'll go and ask legal to see if they can clear this up. regards, Karl On Thu, Dec 14, 2017 at 2:41 PM, Karl Pauls <karlpa...@gmail.com> wrote: > John, > > yeah, I see that the schedule B is somewhat lacking. Oh well, ok, so > basically we are fine with a CCLA but in this case we don't think the > provided one is explicit enough (plus we want an ICLA for Jessica > Marz). > > I'll let them know and get back to this thread when there is either an > SGA or a new CCLA with the zip name and hash + ICLA for Jessica. > > Thank you for looking into this! > > regards, > > Karl > > On Thu, Dec 14, 2017 at 2:06 PM, John D. Ament <johndam...@apache.org> wrote: >> Karl, >> >> I just read the CCLA that was filed. I do not believe it is clear enough >> in the schedule B that it contains to conclude what is meant to be >> included. Since you're a chair, you should have access to it at >> https://svn.apache.org/repos/private/documents/cclas/intel-corporation-felix.pdf >> >> Typically, to use a schedule B (as you're noting) I would expect: >> >> - A zip/tar archive with checksum & md5 listed OR >> - A list of files >> >> As well as: >> >> - ICLA(s) on file for the individual(s). >> >> So you could also do another CCLA but listing out one of those two items >> above, as well as request an ICLA from Jessica Marz. >> >> John >> >> On Thu, Dec 14, 2017 at 7:08 AM Karl Pauls <karlpa...@gmail.com> wrote: >> >>> John, >>> >>> it might typically be an SGA but it does say: "This grant can either >>> be done by the ASF Corporate CLA (via Schedule B) or the Software >>> Grant Agreement". Should we change that wording then? >>> >>> Anyways, I will follow-up with Intel via Jessica and let them know >>> that the provided Corporate CLA isn't sufficient and see if they can >>> provide a Software Grant Agreement instead. Thanks! >>> >>> regards, >>> >>> Karl >>> >>> On Thu, Dec 14, 2017 at 1:01 PM, John D. Ament <johndam...@apache.org> >>> wrote: >>> > Karl, >>> > >>> > If the code is already Apache licensed, then I would check w/ secretary@ >>> or >>> > legal-discuss@ to confirm what documents need to be in place to remove >>> the >>> > Intel copyright claim (typically those would go in to the NOTICE file for >>> > Apache Felix going forward). This is typically done as an SGA [1]. >>> > >>> > John >>> > >>> > [1]: https://www.apache.org/licenses/software-grant-template.pdf >>> > >>> > On Thu, Dec 14, 2017 at 6:57 AM Karl Pauls <karlpa...@gmail.com> wrote: >>> > >>> >> Hi John, >>> >> >>> >> the code has been available as AL with the Intel copyright already >>> >> (the license headers in the files are unchanged). It is mainly an >>> >> attempt to get it contributed to Apache Felix. I told them we need the >>> >> following (from the incubator ip-clearance form): >>> >> >>> >> "A software grant must be provided to the ASF. This grant can either >>> >> be done by the ASF Corporate CLA (via Schedule B) or the Software >>> >> Grant Agreement. The completed and signed grant must be emailed to >>> >> secret...@apache.org" >>> >> >>> >> Consequently, they send (the received) CCLA which was supposed to >>> >> cover for that. >>> >> >>> >> Apologies if I misunderstood the requirement. Could you please help me >>> >> out here and list what exactly we need from Intel and/or Jessica to >>> >> get this done? >>> >> >>> >> regards, >>> >> >>> >> Karl >>> >> >>> >> >&
Re: [IP CLEARANCE] Apache Felix Bundle Archive File Installer Extension
John, yeah, I see that the schedule B is somewhat lacking. Oh well, ok, so basically we are fine with a CCLA but in this case we don't think the provided one is explicit enough (plus we want an ICLA for Jessica Marz). I'll let them know and get back to this thread when there is either an SGA or a new CCLA with the zip name and hash + ICLA for Jessica. Thank you for looking into this! regards, Karl On Thu, Dec 14, 2017 at 2:06 PM, John D. Ament <johndam...@apache.org> wrote: > Karl, > > I just read the CCLA that was filed. I do not believe it is clear enough > in the schedule B that it contains to conclude what is meant to be > included. Since you're a chair, you should have access to it at > https://svn.apache.org/repos/private/documents/cclas/intel-corporation-felix.pdf > > Typically, to use a schedule B (as you're noting) I would expect: > > - A zip/tar archive with checksum & md5 listed OR > - A list of files > > As well as: > > - ICLA(s) on file for the individual(s). > > So you could also do another CCLA but listing out one of those two items > above, as well as request an ICLA from Jessica Marz. > > John > > On Thu, Dec 14, 2017 at 7:08 AM Karl Pauls <karlpa...@gmail.com> wrote: > >> John, >> >> it might typically be an SGA but it does say: "This grant can either >> be done by the ASF Corporate CLA (via Schedule B) or the Software >> Grant Agreement". Should we change that wording then? >> >> Anyways, I will follow-up with Intel via Jessica and let them know >> that the provided Corporate CLA isn't sufficient and see if they can >> provide a Software Grant Agreement instead. Thanks! >> >> regards, >> >> Karl >> >> On Thu, Dec 14, 2017 at 1:01 PM, John D. Ament <johndam...@apache.org> >> wrote: >> > Karl, >> > >> > If the code is already Apache licensed, then I would check w/ secretary@ >> or >> > legal-discuss@ to confirm what documents need to be in place to remove >> the >> > Intel copyright claim (typically those would go in to the NOTICE file for >> > Apache Felix going forward). This is typically done as an SGA [1]. >> > >> > John >> > >> > [1]: https://www.apache.org/licenses/software-grant-template.pdf >> > >> > On Thu, Dec 14, 2017 at 6:57 AM Karl Pauls <karlpa...@gmail.com> wrote: >> > >> >> Hi John, >> >> >> >> the code has been available as AL with the Intel copyright already >> >> (the license headers in the files are unchanged). It is mainly an >> >> attempt to get it contributed to Apache Felix. I told them we need the >> >> following (from the incubator ip-clearance form): >> >> >> >> "A software grant must be provided to the ASF. This grant can either >> >> be done by the ASF Corporate CLA (via Schedule B) or the Software >> >> Grant Agreement. The completed and signed grant must be emailed to >> >> secret...@apache.org" >> >> >> >> Consequently, they send (the received) CCLA which was supposed to >> >> cover for that. >> >> >> >> Apologies if I misunderstood the requirement. Could you please help me >> >> out here and list what exactly we need from Intel and/or Jessica to >> >> get this done? >> >> >> >> regards, >> >> >> >> Karl >> >> >> >> >> >> >> >> On Thu, Dec 14, 2017 at 12:48 PM, John D. Ament <johndam...@apache.org> >> >> wrote: >> >> > Karl, >> >> > >> >> > CCLA [1] is just a document indicating that the corporate entity has >> >> given >> >> > approval for individuals associated to it to contribute to Apache >> under >> >> > ICLAs. It really doesn't provide any legal bearing to relicense code >> >> > outside of an ICLA/SGA. >> >> > >> >> > Usually when projects come to us with an IP clearance, its for a >> >> > significant amount of code. In those scenarios, there's an SGA >> >> associated >> >> > with the contribution (from a corporate entity) indicating that they >> are >> >> > licensing the ASF to use the code under the Apache license >> (irrespective >> >> of >> >> > the original license). I'm assuming that at Intel some # of engineers >> >> > contributed to this code, and that it was under a proprietary license >> >> until >> >&g
Re: [IP CLEARANCE] Apache Felix Bundle Archive File Installer Extension
John, it might typically be an SGA but it does say: "This grant can either be done by the ASF Corporate CLA (via Schedule B) or the Software Grant Agreement". Should we change that wording then? Anyways, I will follow-up with Intel via Jessica and let them know that the provided Corporate CLA isn't sufficient and see if they can provide a Software Grant Agreement instead. Thanks! regards, Karl On Thu, Dec 14, 2017 at 1:01 PM, John D. Ament <johndam...@apache.org> wrote: > Karl, > > If the code is already Apache licensed, then I would check w/ secretary@ or > legal-discuss@ to confirm what documents need to be in place to remove the > Intel copyright claim (typically those would go in to the NOTICE file for > Apache Felix going forward). This is typically done as an SGA [1]. > > John > > [1]: https://www.apache.org/licenses/software-grant-template.pdf > > On Thu, Dec 14, 2017 at 6:57 AM Karl Pauls <karlpa...@gmail.com> wrote: > >> Hi John, >> >> the code has been available as AL with the Intel copyright already >> (the license headers in the files are unchanged). It is mainly an >> attempt to get it contributed to Apache Felix. I told them we need the >> following (from the incubator ip-clearance form): >> >> "A software grant must be provided to the ASF. This grant can either >> be done by the ASF Corporate CLA (via Schedule B) or the Software >> Grant Agreement. The completed and signed grant must be emailed to >> secret...@apache.org" >> >> Consequently, they send (the received) CCLA which was supposed to >> cover for that. >> >> Apologies if I misunderstood the requirement. Could you please help me >> out here and list what exactly we need from Intel and/or Jessica to >> get this done? >> >> regards, >> >> Karl >> >> >> >> On Thu, Dec 14, 2017 at 12:48 PM, John D. Ament <johndam...@apache.org> >> wrote: >> > Karl, >> > >> > CCLA [1] is just a document indicating that the corporate entity has >> given >> > approval for individuals associated to it to contribute to Apache under >> > ICLAs. It really doesn't provide any legal bearing to relicense code >> > outside of an ICLA/SGA. >> > >> > Usually when projects come to us with an IP clearance, its for a >> > significant amount of code. In those scenarios, there's an SGA >> associated >> > with the contribution (from a corporate entity) indicating that they are >> > licensing the ASF to use the code under the Apache license (irrespective >> of >> > the original license). I'm assuming that at Intel some # of engineers >> > contributed to this code, and that it was under a proprietary license >> until >> > this JIRA ticket was filed. In that case, SGA is almost always the right >> > document to get signed. >> > >> > In the situations where we see ICLAs, there isn't usually a SGA involved >> > since its covered under an ICLA for that committer and needs to be >> applied >> > as a patch/pull request. The other clear thing this indicates is a loss >> of >> > provenance, since (I haven't looked at all of the source files) we're >> > receiving a flat dump of code to be brought into an existing repository. >> > >> > So, unfortunately, until that's resolved I'm -1 to accepting it. >> > >> > [1]: https://www.apache.org/licenses/cla-corporate.txt >> > >> > On Thu, Dec 14, 2017 at 5:03 AM Karl Pauls <karlpa...@gmail.com> wrote: >> > >> >> Hi John, >> >> >> >> as far as I understand the situation, the contribution has been >> >> submitted by Jessica Marz on behalf of Intel. The copyright is >> >> entirely Intel and the CCLA received is _from_ Intel, covering Jessica >> >> Marz and the contribution. Does that help? >> >> >> >> regards, >> >> >> >> Karl >> >> >> >> On Thu, Dec 14, 2017 at 1:54 AM, John D. Ament <johndam...@apache.org> >> >> wrote: >> >> > Hello, >> >> > >> >> > Can you please clarify whether only a CCLA was received, or if >> ICLAs/SGA >> >> > were received as well? The document indicates a CCLA was received >> from >> >> an >> >> > individual, which doesn't sound right. >> >> > >> >> > John >> >> > >> >> > On Wed, Dec 13, 2017 at 1:32 AM Karl Pauls <karlpa...@gmail.com>
Re: [IP CLEARANCE] Apache Felix Bundle Archive File Installer Extension
Hi John, the code has been available as AL with the Intel copyright already (the license headers in the files are unchanged). It is mainly an attempt to get it contributed to Apache Felix. I told them we need the following (from the incubator ip-clearance form): "A software grant must be provided to the ASF. This grant can either be done by the ASF Corporate CLA (via Schedule B) or the Software Grant Agreement. The completed and signed grant must be emailed to secret...@apache.org" Consequently, they send (the received) CCLA which was supposed to cover for that. Apologies if I misunderstood the requirement. Could you please help me out here and list what exactly we need from Intel and/or Jessica to get this done? regards, Karl On Thu, Dec 14, 2017 at 12:48 PM, John D. Ament <johndam...@apache.org> wrote: > Karl, > > CCLA [1] is just a document indicating that the corporate entity has given > approval for individuals associated to it to contribute to Apache under > ICLAs. It really doesn't provide any legal bearing to relicense code > outside of an ICLA/SGA. > > Usually when projects come to us with an IP clearance, its for a > significant amount of code. In those scenarios, there's an SGA associated > with the contribution (from a corporate entity) indicating that they are > licensing the ASF to use the code under the Apache license (irrespective of > the original license). I'm assuming that at Intel some # of engineers > contributed to this code, and that it was under a proprietary license until > this JIRA ticket was filed. In that case, SGA is almost always the right > document to get signed. > > In the situations where we see ICLAs, there isn't usually a SGA involved > since its covered under an ICLA for that committer and needs to be applied > as a patch/pull request. The other clear thing this indicates is a loss of > provenance, since (I haven't looked at all of the source files) we're > receiving a flat dump of code to be brought into an existing repository. > > So, unfortunately, until that's resolved I'm -1 to accepting it. > > [1]: https://www.apache.org/licenses/cla-corporate.txt > > On Thu, Dec 14, 2017 at 5:03 AM Karl Pauls <karlpa...@gmail.com> wrote: > >> Hi John, >> >> as far as I understand the situation, the contribution has been >> submitted by Jessica Marz on behalf of Intel. The copyright is >> entirely Intel and the CCLA received is _from_ Intel, covering Jessica >> Marz and the contribution. Does that help? >> >> regards, >> >> Karl >> >> On Thu, Dec 14, 2017 at 1:54 AM, John D. Ament <johndam...@apache.org> >> wrote: >> > Hello, >> > >> > Can you please clarify whether only a CCLA was received, or if ICLAs/SGA >> > were received as well? The document indicates a CCLA was received from >> an >> > individual, which doesn't sound right. >> > >> > John >> > >> > On Wed, Dec 13, 2017 at 1:32 AM Karl Pauls <karlpa...@gmail.com> wrote: >> > >> >> Hi, >> >> >> >> the Apache Felix project has received the contribution of the Bundle >> >> Archive File Installer Extension. >> >> >> >> - The code is attached to FELIX-5732 [0]. >> >> - The IP Clearance form has been committed [1]. >> >> - The acceptance vote has passed on the dev@felix malining list [2]. >> >> >> >> The clearance passes by lazy consensus if no -1 votes are cast within >> >> the next 72 hours. >> >> >> >> regards, >> >> >> >> Karl >> >> >> >> >> >> [0] https://issues.apache.org/jira/browse/FELIX-5732 >> >> [1] >> >> >> https://incubator.apache.org/ip-clearance/felix-bar-file-install-extension.html >> >> [2] https://www.mail-archive.com/dev@felix.apache.org/msg44409.html >> >> >> >> -- >> >> Karl Pauls >> >> karlpa...@gmail.com >> >> >> >> - >> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> >> >> >> >> >> >> -- >> Karl Pauls >> karlpa...@gmail.com >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] Apache Felix Bundle Archive File Installer Extension
Hi John, as far as I understand the situation, the contribution has been submitted by Jessica Marz on behalf of Intel. The copyright is entirely Intel and the CCLA received is _from_ Intel, covering Jessica Marz and the contribution. Does that help? regards, Karl On Thu, Dec 14, 2017 at 1:54 AM, John D. Ament <johndam...@apache.org> wrote: > Hello, > > Can you please clarify whether only a CCLA was received, or if ICLAs/SGA > were received as well? The document indicates a CCLA was received from an > individual, which doesn't sound right. > > John > > On Wed, Dec 13, 2017 at 1:32 AM Karl Pauls <karlpa...@gmail.com> wrote: > >> Hi, >> >> the Apache Felix project has received the contribution of the Bundle >> Archive File Installer Extension. >> >> - The code is attached to FELIX-5732 [0]. >> - The IP Clearance form has been committed [1]. >> - The acceptance vote has passed on the dev@felix malining list [2]. >> >> The clearance passes by lazy consensus if no -1 votes are cast within >> the next 72 hours. >> >> regards, >> >> Karl >> >> >> [0] https://issues.apache.org/jira/browse/FELIX-5732 >> [1] >> https://incubator.apache.org/ip-clearance/felix-bar-file-install-extension.html >> [2] https://www.mail-archive.com/dev@felix.apache.org/msg44409.html >> >> -- >> Karl Pauls >> karlpa...@gmail.com >> >> ----- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[IP CLEARANCE] Apache Felix Bundle Archive File Installer Extension
Hi, the Apache Felix project has received the contribution of the Bundle Archive File Installer Extension. - The code is attached to FELIX-5732 [0]. - The IP Clearance form has been committed [1]. - The acceptance vote has passed on the dev@felix malining list [2]. The clearance passes by lazy consensus if no -1 votes are cast within the next 72 hours. regards, Karl [0] https://issues.apache.org/jira/browse/FELIX-5732 [1] https://incubator.apache.org/ip-clearance/felix-bar-file-install-extension.html [2] https://www.mail-archive.com/dev@felix.apache.org/msg44409.html -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept OpenWhisk into the Apache Incubator
+1 regards, Karl On Thu, Nov 17, 2016 at 4:22 PM, Sam Ruby <ru...@intertwingly.net> wrote: > Now that the discussion thread on the OpenWhisk Proposal has died > down, please take a moment to vote on accepting OpenWhisk into the > Apache Incubator. > > The ASF voting rules are described at: >http://www.apache.org/foundation/voting.html > > A vote for accepting a new Apache Incubator podling is a majority vote > for which only Incubator PMC member votes are binding. > > Votes from other people are also welcome as an indication of peoples > enthusiasm (or lack thereof). > > Please do not use this VOTE thread for discussions. > If needed, start a new thread instead. > > This vote will run for at least 72 hours. Please VOTE as follows > [] +1 Accept OpenWhisk into the Apache Incubator > [] +0 Abstain. > [] -1 Do not accept OpenWhisk into the Apache Incubator because ... > > The proposal is listed below, but you can also access it on the wiki: > https://wiki.apache.org/incubator/OpenWhiskProposal > > - Sam Ruby -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Re: [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)
+1 regards, Karl On Fri, Feb 10, 2012 at 10:02 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: On Fri, Feb 10, 2012 at 3:31 AM, Noel J. Bergman n...@devtech.com wrote: ...I have no issue with standing down after 8 years, and Jukka is an excellent and active successor. I was exceedingly pleased to see his message that he had reconsidered... Thanks Noel for the clarification. +1 for Jukka then! -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache ACE as a TLP
+1 However, somehow my mail is wrong, should be pa...@apache.org and _not_ kpa...@apache.org regards, Karl On Sat, Dec 17, 2011 at 12:55 PM, Marcel Offermans marcel.offerm...@luminis.nl wrote: Hello all, As the discussion about the resolution [1] offered no further feedback, it is time for the Apache ACE community to request that the IPMC vote on recommending this resolution [2] to the ASF board. Please cast your vote: [ ] +1 to recommend ACE's graduation [ ] 0 don't care [ ] -1 no, don't recommend yet, (because...) The vote will be open for 72 hours. Greetings, Marcel [1] http://markmail.org/thread/wfrvwmnu3y22oxys [2] see below: ## Resolution to create a TLP from graduating Incubator podling X. Establish the Apache ACE 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 the management and deployment of OSGi based and other software artifacts for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache ACE Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache ACE Project be and hereby is responsible for the creation and maintenance of software related to the management and deployment of OSGi based and other software artifacts; and be it further RESOLVED, that the office of Vice President, Apache ACE 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 ACE Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache ACE 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 ACE Project: * Angelo van der Sijpt ange...@apache.org * Brian Topping btopp...@apache.org * Clement Escoffier clem...@apache.org * Carsten Ziegeler cziege...@apache.org * Jean-Baptiste Onofre jbono...@apache.org * Karl Pauls kpa...@apache.org * Marcel Offermans ma...@apache.org * Toni Menzel to...@apache.org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Marcel Offermans be appointed to the office of Vice President, Apache ACE, 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 ACE 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 ACE Project; and be it further RESOLVED, that the Apache ACE Project be and hereby is tasked with the migration and rationalization of the Apache Incubator ACE podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator ACE podling encumbered upon the Apache Incubator Project are hereafter discharged. Note to moderators: I sent this message before, over 24 hours ago, with my apache e-mail address (that is not subscribed to this list). It's still stuck in moderation, which is why I'm sending it again today. If ultimately both end up on the list, my apologies, I will summarize the responses over both messages. -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][VOTE] Release ace version 0.8.1-incubator subprojects
Time to call the vote on the ace version 0.8.1-incubator subprojects releases. As we didn't get any additional votes, I'm going to close this vote with the original results from the dev list as follows, * +1 votes from Marcel Offermans***, Jean-Baptiste Onofré***, Toni Menzel*, Bram de Kruijff, Angelo van der Sijpt*, Carsten Ziegeler***, and Karl Pauls***. * No other votes As we have 4 binding IPMC +1, the vote is successful. I'll make the artifacts available as soon as possible. * == PPMC ** == IPMC *** == PPMC + IPMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[DISCUSS][VOTE] Release ace version 0.8.1-incubator subprojects
The vote on Release ace version 0.8.1-incubator subprojects has been running for 72h and we didn't see any more votes from IPMC members other than the 4 votes we already have from the vote on the ace dev list. Given that this release was created specifically because some issues with our last release where causing some debate on our should we ask for graduation vote I really would have hoped that we get some feedback on this one -- hence, I'm going to give it another 24h but if I don't see any other votes nor any request for more time (as I appreciate that it is a big release) I'm going to call this vote successful based on the 4 IPMC member votes we did already get. In that case, however, I don't want to see it debated again during graduation i.e., speak now or forever hold your peace. regards, Karl On Sun, Dec 4, 2011 at 10:56 PM, Karl Pauls karlpa...@gmail.com wrote: This is the second release of the ace incubator project called ace version 0.8.1-incubator subprojects releases. For details of the release see the original vote thread: http://markmail.org/thread/bxk47uzt7dzbajir We have already received 4 binding IPMC votes during the PPMC voting below. I'd like to continue the vote on general@ now to get the IPMC approval -- hence, Please vote to approve this release. On Sun, Dec 4, 2011 at 10:36 PM, Karl Pauls karlpa...@gmail.com wrote: Time to call the vote on the ace version 0.8.1-incubator subprojects releases. * +1 votes from Marcel Offermans***, Jean-Baptiste Onofré***, Toni Menzel*, Bram de Kruijff, Angelo van der Sijpt*, Carsten Ziegeler***, and Karl Pauls***. * No other votes The vote is successful. I will approach the Incubator PMC for approval. * == PPMC ** == IPMC *** == PPMC + IPMC -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS][VOTE] Release ace version 0.8.1-incubator subprojects
On Thu, Dec 8, 2011 at 1:08 PM, sebb seb...@gmail.com wrote: On 8 December 2011 10:39, sebb seb...@gmail.com wrote: On 8 December 2011 10:14, Karl Pauls karlpa...@gmail.com wrote: The vote on Release ace version 0.8.1-incubator subprojects has been running for 72h and we didn't see any more votes from IPMC members other than the 4 votes we already have from the vote on the ace dev list. Given that this release was created specifically because some issues with our last release where causing some debate on our should we ask for graduation vote I really would have hoped that we get some feedback on this one -- hence, I'm not saying this is a big factor in the lack of response, but normally votes include all the relevant information in the e-mail. In this case one has to go digging through another e-mail (using an offsite link as well) to find the details. The easier it is made for users, the more likely they are to respond. I'm copying the details below in case that helps anyone else: === After our community graduation vote lead to a lengthy discussion about the 0.8.0-incubator release we did, we decided to roll a new ACE release, based on the original release. In the release we fix the issue that our previous source artifacts did not contain a pom.xml so building them was hard. You can now download a single, or all sources, and build them with a single command. Also, we added an extra artifact that contains the full source code, which is there for convenience in case someone wants to download all the sources and start developing from there. We did that in a way that is somewhat similar to Sling, but instead of using svn:externals we used Maven to generate this artifact (for more see the README.txt inside org.apache.ace.release.full 0.8.1-incubator) -- hence, I would like to call a vote on the following ace 0.8.1-incubator subproject releases: ace-pom 0.8.1-incubator org.apache.ace.client.automation 0.8.1-incubator org.apache.ace.client.repository.api 0.8.1-incubator org.apache.ace.client.repository.helper.base 0.8.1-incubator org.apache.ace.client.repository.helper.bundle 0.8.1-incubator org.apache.ace.client.repository.helper.configuration 0.8.1-incubator org.apache.ace.client.repository.helper.user 0.8.1-incubator org.apache.ace.client.repository.impl 0.8.1-incubator org.apache.ace.client.repository.useradmin 0.8.1-incubator org.apache.ace.configurator 0.8.1-incubator org.apache.ace.configurator.serveruseradmin 0.8.1-incubator org.apache.ace.configurator.useradmin.task 0.8.1-incubator org.apache.ace.consolelogger 0.8.1-incubator org.apache.ace.deployment.api 0.8.1-incubator org.apache.ace.deployment.deploymentadmin 0.8.1-incubator org.apache.ace.deployment.provider.api 0.8.1-incubator org.apache.ace.deployment.provider.base 0.8.1-incubator org.apache.ace.deployment.provider.filebased 0.8.1-incubator org.apache.ace.deployment.provider.repositorybased 0.8.1-incubator org.apache.ace.deployment.servlet 0.8.1-incubator org.apache.ace.deployment.streamgenerator 0.8.1-incubator org.apache.ace.deployment.task 0.8.1-incubator org.apache.ace.discovery.api 0.8.1-incubator org.apache.ace.discovery.property 0.8.1-incubator org.apache.ace.discovery.upnp 0.8.1-incubator org.apache.ace.gateway.log 0.8.1-incubator org.apache.ace.gateway.log.store 0.8.1-incubator org.apache.ace.httplistener 0.8.1-incubator org.apache.ace.identification.api 0.8.1-incubator org.apache.ace.identification.ifconfig 0.8.1-incubator org.apache.ace.identification.property 0.8.1-incubator org.apache.ace.launcher 0.8.1-incubator org.apache.ace.location.upnp 0.8.1-incubator org.apache.ace.log 0.8.1-incubator org.apache.ace.log.listener 0.8.1-incubator org.apache.ace.log.servlet 0.8.1-incubator org.apache.ace.log.task 0.8.1-incubator org.apache.ace.managementagent 0.8.1-incubator org.apache.ace.nodelauncher.amazon 0.8.1-incubator org.apache.ace.nodelauncher.api 0.8.1-incubator org.apache.ace.nodelauncher.ui 0.8.1-incubator org.apache.ace.obr.metadata 0.8.1-incubator org.apache.ace.obr.servlet 0.8.1-incubator org.apache.ace.obr.storage 0.8.1-incubator org.apache.ace.range.api 0.8.1-incubator org.apache.ace.release.full 0.8.1-incubator org.apache.ace.repository.api 0.8.1-incubator org.apache.ace.repository.ext 0.8.1-incubator org.apache.ace.repository.impl 0.8.1-incubator org.apache.ace.repository.servlet 0.8.1-incubator org.apache.ace.repository.task 0.8.1-incubator org.apache.ace.resourceprocessor.useradmin 0.8.1-incubator org.apache.ace.scheduler 0.8.1-incubator org.apache.ace.scheduler.api 0.8.1-incubator org.apache.ace.server.action 0.8.1-incubator org.apache.ace.server.action.popupmessage 0.8.1-incubator org.apache.ace.server.log.store 0.8.1-incubator org.apache.ace.tageditor 0.8.1-incubator org.apache.ace.target.defaults 0.8.1-incubator org.apache.ace.target.devgateway 0.8.1-incubator org.apache.ace.target.devserver 0.8.1
Re: [DISCUSS][VOTE] Release ace version 0.8.1-incubator subprojects
On Thu, Dec 8, 2011 at 4:21 PM, sebb seb...@gmail.com wrote: On 8 December 2011 14:30, Karl Pauls karlpa...@gmail.com wrote: On Thu, Dec 8, 2011 at 1:08 PM, sebb seb...@gmail.com wrote: On 8 December 2011 10:39, sebb seb...@gmail.com wrote: On 8 December 2011 10:14, Karl Pauls karlpa...@gmail.com wrote: The vote on Release ace version 0.8.1-incubator subprojects has been running for 72h and we didn't see any more votes from IPMC members other than the 4 votes we already have from the vote on the ace dev list. Given that this release was created specifically because some issues with our last release where causing some debate on our should we ask for graduation vote I really would have hoped that we get some feedback on this one -- hence, I'm not saying this is a big factor in the lack of response, but normally votes include all the relevant information in the e-mail. In this case one has to go digging through another e-mail (using an offsite link as well) to find the details. The easier it is made for users, the more likely they are to respond. I'm copying the details below in case that helps anyone else: === After our community graduation vote lead to a lengthy discussion about the 0.8.0-incubator release we did, we decided to roll a new ACE release, based on the original release. In the release we fix the issue that our previous source artifacts did not contain a pom.xml so building them was hard. You can now download a single, or all sources, and build them with a single command. Also, we added an extra artifact that contains the full source code, which is there for convenience in case someone wants to download all the sources and start developing from there. We did that in a way that is somewhat similar to Sling, but instead of using svn:externals we used Maven to generate this artifact (for more see the README.txt inside org.apache.ace.release.full 0.8.1-incubator) -- hence, I would like to call a vote on the following ace 0.8.1-incubator subproject releases: ace-pom 0.8.1-incubator org.apache.ace.client.automation 0.8.1-incubator org.apache.ace.client.repository.api 0.8.1-incubator org.apache.ace.client.repository.helper.base 0.8.1-incubator org.apache.ace.client.repository.helper.bundle 0.8.1-incubator org.apache.ace.client.repository.helper.configuration 0.8.1-incubator org.apache.ace.client.repository.helper.user 0.8.1-incubator org.apache.ace.client.repository.impl 0.8.1-incubator org.apache.ace.client.repository.useradmin 0.8.1-incubator org.apache.ace.configurator 0.8.1-incubator org.apache.ace.configurator.serveruseradmin 0.8.1-incubator org.apache.ace.configurator.useradmin.task 0.8.1-incubator org.apache.ace.consolelogger 0.8.1-incubator org.apache.ace.deployment.api 0.8.1-incubator org.apache.ace.deployment.deploymentadmin 0.8.1-incubator org.apache.ace.deployment.provider.api 0.8.1-incubator org.apache.ace.deployment.provider.base 0.8.1-incubator org.apache.ace.deployment.provider.filebased 0.8.1-incubator org.apache.ace.deployment.provider.repositorybased 0.8.1-incubator org.apache.ace.deployment.servlet 0.8.1-incubator org.apache.ace.deployment.streamgenerator 0.8.1-incubator org.apache.ace.deployment.task 0.8.1-incubator org.apache.ace.discovery.api 0.8.1-incubator org.apache.ace.discovery.property 0.8.1-incubator org.apache.ace.discovery.upnp 0.8.1-incubator org.apache.ace.gateway.log 0.8.1-incubator org.apache.ace.gateway.log.store 0.8.1-incubator org.apache.ace.httplistener 0.8.1-incubator org.apache.ace.identification.api 0.8.1-incubator org.apache.ace.identification.ifconfig 0.8.1-incubator org.apache.ace.identification.property 0.8.1-incubator org.apache.ace.launcher 0.8.1-incubator org.apache.ace.location.upnp 0.8.1-incubator org.apache.ace.log 0.8.1-incubator org.apache.ace.log.listener 0.8.1-incubator org.apache.ace.log.servlet 0.8.1-incubator org.apache.ace.log.task 0.8.1-incubator org.apache.ace.managementagent 0.8.1-incubator org.apache.ace.nodelauncher.amazon 0.8.1-incubator org.apache.ace.nodelauncher.api 0.8.1-incubator org.apache.ace.nodelauncher.ui 0.8.1-incubator org.apache.ace.obr.metadata 0.8.1-incubator org.apache.ace.obr.servlet 0.8.1-incubator org.apache.ace.obr.storage 0.8.1-incubator org.apache.ace.range.api 0.8.1-incubator org.apache.ace.release.full 0.8.1-incubator org.apache.ace.repository.api 0.8.1-incubator org.apache.ace.repository.ext 0.8.1-incubator org.apache.ace.repository.impl 0.8.1-incubator org.apache.ace.repository.servlet 0.8.1-incubator org.apache.ace.repository.task 0.8.1-incubator org.apache.ace.resourceprocessor.useradmin 0.8.1-incubator org.apache.ace.scheduler 0.8.1-incubator org.apache.ace.scheduler.api 0.8.1-incubator org.apache.ace.server.action 0.8.1-incubator org.apache.ace.server.action.popupmessage 0.8.1-incubator org.apache.ace.server.log.store 0.8.1-incubator org.apache.ace.tageditor 0.8.1-incubator
Re: [DISCUSS][VOTE] Release ace version 0.8.1-incubator subprojects
On Thu, Dec 8, 2011 at 5:17 PM, sebb seb...@gmail.com wrote: On 8 December 2011 15:28, Karl Pauls karlpa...@gmail.com wrote: On Thu, Dec 8, 2011 at 4:21 PM, sebb seb...@gmail.com wrote: On 8 December 2011 14:30, Karl Pauls karlpa...@gmail.com wrote: On Thu, Dec 8, 2011 at 1:08 PM, sebb seb...@gmail.com wrote: On 8 December 2011 10:39, sebb seb...@gmail.com wrote: On 8 December 2011 10:14, Karl Pauls karlpa...@gmail.com wrote: The vote on Release ace version 0.8.1-incubator subprojects has been running for 72h and we didn't see any more votes from IPMC members other than the 4 votes we already have from the vote on the ace dev list. Given that this release was created specifically because some issues with our last release where causing some debate on our should we ask for graduation vote I really would have hoped that we get some feedback on this one -- hence, I'm not saying this is a big factor in the lack of response, but normally votes include all the relevant information in the e-mail. In this case one has to go digging through another e-mail (using an offsite link as well) to find the details. The easier it is made for users, the more likely they are to respond. I'm copying the details below in case that helps anyone else: === After our community graduation vote lead to a lengthy discussion about the 0.8.0-incubator release we did, we decided to roll a new ACE release, based on the original release. In the release we fix the issue that our previous source artifacts did not contain a pom.xml so building them was hard. You can now download a single, or all sources, and build them with a single command. Also, we added an extra artifact that contains the full source code, which is there for convenience in case someone wants to download all the sources and start developing from there. We did that in a way that is somewhat similar to Sling, but instead of using svn:externals we used Maven to generate this artifact (for more see the README.txt inside org.apache.ace.release.full 0.8.1-incubator) -- hence, I would like to call a vote on the following ace 0.8.1-incubator subproject releases: ace-pom 0.8.1-incubator org.apache.ace.client.automation 0.8.1-incubator org.apache.ace.client.repository.api 0.8.1-incubator org.apache.ace.client.repository.helper.base 0.8.1-incubator org.apache.ace.client.repository.helper.bundle 0.8.1-incubator org.apache.ace.client.repository.helper.configuration 0.8.1-incubator org.apache.ace.client.repository.helper.user 0.8.1-incubator org.apache.ace.client.repository.impl 0.8.1-incubator org.apache.ace.client.repository.useradmin 0.8.1-incubator org.apache.ace.configurator 0.8.1-incubator org.apache.ace.configurator.serveruseradmin 0.8.1-incubator org.apache.ace.configurator.useradmin.task 0.8.1-incubator org.apache.ace.consolelogger 0.8.1-incubator org.apache.ace.deployment.api 0.8.1-incubator org.apache.ace.deployment.deploymentadmin 0.8.1-incubator org.apache.ace.deployment.provider.api 0.8.1-incubator org.apache.ace.deployment.provider.base 0.8.1-incubator org.apache.ace.deployment.provider.filebased 0.8.1-incubator org.apache.ace.deployment.provider.repositorybased 0.8.1-incubator org.apache.ace.deployment.servlet 0.8.1-incubator org.apache.ace.deployment.streamgenerator 0.8.1-incubator org.apache.ace.deployment.task 0.8.1-incubator org.apache.ace.discovery.api 0.8.1-incubator org.apache.ace.discovery.property 0.8.1-incubator org.apache.ace.discovery.upnp 0.8.1-incubator org.apache.ace.gateway.log 0.8.1-incubator org.apache.ace.gateway.log.store 0.8.1-incubator org.apache.ace.httplistener 0.8.1-incubator org.apache.ace.identification.api 0.8.1-incubator org.apache.ace.identification.ifconfig 0.8.1-incubator org.apache.ace.identification.property 0.8.1-incubator org.apache.ace.launcher 0.8.1-incubator org.apache.ace.location.upnp 0.8.1-incubator org.apache.ace.log 0.8.1-incubator org.apache.ace.log.listener 0.8.1-incubator org.apache.ace.log.servlet 0.8.1-incubator org.apache.ace.log.task 0.8.1-incubator org.apache.ace.managementagent 0.8.1-incubator org.apache.ace.nodelauncher.amazon 0.8.1-incubator org.apache.ace.nodelauncher.api 0.8.1-incubator org.apache.ace.nodelauncher.ui 0.8.1-incubator org.apache.ace.obr.metadata 0.8.1-incubator org.apache.ace.obr.servlet 0.8.1-incubator org.apache.ace.obr.storage 0.8.1-incubator org.apache.ace.range.api 0.8.1-incubator org.apache.ace.release.full 0.8.1-incubator org.apache.ace.repository.api 0.8.1-incubator org.apache.ace.repository.ext 0.8.1-incubator org.apache.ace.repository.impl 0.8.1-incubator org.apache.ace.repository.servlet 0.8.1-incubator org.apache.ace.repository.task 0.8.1-incubator org.apache.ace.resourceprocessor.useradmin 0.8.1-incubator org.apache.ace.scheduler 0.8.1-incubator org.apache.ace.scheduler.api 0.8.1-incubator org.apache.ace.server.action 0.8.1-incubator
Re: [DISCUSS][VOTE] Release ace version 0.8.1-incubator subprojects
On Thu, Dec 8, 2011 at 6:17 PM, sebb seb...@gmail.com wrote: On 8 December 2011 16:54, Karl Pauls karlpa...@gmail.com wrote: On Thu, Dec 8, 2011 at 5:17 PM, sebb seb...@gmail.com wrote: On 8 December 2011 15:28, Karl Pauls karlpa...@gmail.com wrote: On Thu, Dec 8, 2011 at 4:21 PM, sebb seb...@gmail.com wrote: On 8 December 2011 14:30, Karl Pauls karlpa...@gmail.com wrote: On Thu, Dec 8, 2011 at 1:08 PM, sebb seb...@gmail.com wrote: On 8 December 2011 10:39, sebb seb...@gmail.com wrote: On 8 December 2011 10:14, Karl Pauls karlpa...@gmail.com wrote: The vote on Release ace version 0.8.1-incubator subprojects has been running for 72h and we didn't see any more votes from IPMC members other than the 4 votes we already have from the vote on the ace dev list. Given that this release was created specifically because some issues with our last release where causing some debate on our should we ask for graduation vote I really would have hoped that we get some feedback on this one -- hence, I'm not saying this is a big factor in the lack of response, but normally votes include all the relevant information in the e-mail. In this case one has to go digging through another e-mail (using an offsite link as well) to find the details. The easier it is made for users, the more likely they are to respond. I'm copying the details below in case that helps anyone else: === After our community graduation vote lead to a lengthy discussion about the 0.8.0-incubator release we did, we decided to roll a new ACE release, based on the original release. In the release we fix the issue that our previous source artifacts did not contain a pom.xml so building them was hard. You can now download a single, or all sources, and build them with a single command. Also, we added an extra artifact that contains the full source code, which is there for convenience in case someone wants to download all the sources and start developing from there. We did that in a way that is somewhat similar to Sling, but instead of using svn:externals we used Maven to generate this artifact (for more see the README.txt inside org.apache.ace.release.full 0.8.1-incubator) -- hence, I would like to call a vote on the following ace 0.8.1-incubator subproject releases: ace-pom 0.8.1-incubator org.apache.ace.client.automation 0.8.1-incubator org.apache.ace.client.repository.api 0.8.1-incubator org.apache.ace.client.repository.helper.base 0.8.1-incubator org.apache.ace.client.repository.helper.bundle 0.8.1-incubator org.apache.ace.client.repository.helper.configuration 0.8.1-incubator org.apache.ace.client.repository.helper.user 0.8.1-incubator org.apache.ace.client.repository.impl 0.8.1-incubator org.apache.ace.client.repository.useradmin 0.8.1-incubator org.apache.ace.configurator 0.8.1-incubator org.apache.ace.configurator.serveruseradmin 0.8.1-incubator org.apache.ace.configurator.useradmin.task 0.8.1-incubator org.apache.ace.consolelogger 0.8.1-incubator org.apache.ace.deployment.api 0.8.1-incubator org.apache.ace.deployment.deploymentadmin 0.8.1-incubator org.apache.ace.deployment.provider.api 0.8.1-incubator org.apache.ace.deployment.provider.base 0.8.1-incubator org.apache.ace.deployment.provider.filebased 0.8.1-incubator org.apache.ace.deployment.provider.repositorybased 0.8.1-incubator org.apache.ace.deployment.servlet 0.8.1-incubator org.apache.ace.deployment.streamgenerator 0.8.1-incubator org.apache.ace.deployment.task 0.8.1-incubator org.apache.ace.discovery.api 0.8.1-incubator org.apache.ace.discovery.property 0.8.1-incubator org.apache.ace.discovery.upnp 0.8.1-incubator org.apache.ace.gateway.log 0.8.1-incubator org.apache.ace.gateway.log.store 0.8.1-incubator org.apache.ace.httplistener 0.8.1-incubator org.apache.ace.identification.api 0.8.1-incubator org.apache.ace.identification.ifconfig 0.8.1-incubator org.apache.ace.identification.property 0.8.1-incubator org.apache.ace.launcher 0.8.1-incubator org.apache.ace.location.upnp 0.8.1-incubator org.apache.ace.log 0.8.1-incubator org.apache.ace.log.listener 0.8.1-incubator org.apache.ace.log.servlet 0.8.1-incubator org.apache.ace.log.task 0.8.1-incubator org.apache.ace.managementagent 0.8.1-incubator org.apache.ace.nodelauncher.amazon 0.8.1-incubator org.apache.ace.nodelauncher.api 0.8.1-incubator org.apache.ace.nodelauncher.ui 0.8.1-incubator org.apache.ace.obr.metadata 0.8.1-incubator org.apache.ace.obr.servlet 0.8.1-incubator org.apache.ace.obr.storage 0.8.1-incubator org.apache.ace.range.api 0.8.1-incubator org.apache.ace.release.full 0.8.1-incubator org.apache.ace.repository.api 0.8.1-incubator org.apache.ace.repository.ext 0.8.1-incubator org.apache.ace.repository.impl 0.8.1-incubator org.apache.ace.repository.servlet 0.8.1-incubator org.apache.ace.repository.task 0.8.1-incubator org.apache.ace.resourceprocessor.useradmin 0.8.1-incubator org.apache.ace.scheduler 0.8.1-incubator
[VOTE] Release ace version 0.8.1-incubator subprojects
This is the second release of the ace incubator project called ace version 0.8.1-incubator subprojects releases. For details of the release see the original vote thread: http://markmail.org/thread/bxk47uzt7dzbajir We have already received 4 binding IPMC votes during the PPMC voting below. I'd like to continue the vote on general@ now to get the IPMC approval -- hence, Please vote to approve this release. On Sun, Dec 4, 2011 at 10:36 PM, Karl Pauls karlpa...@gmail.com wrote: Time to call the vote on the ace version 0.8.1-incubator subprojects releases. * +1 votes from Marcel Offermans***, Jean-Baptiste Onofré***, Toni Menzel*, Bram de Kruijff, Angelo van der Sijpt*, Carsten Ziegeler***, and Karl Pauls***. * No other votes The vote is successful. I will approach the Incubator PMC for approval. * == PPMC ** == IPMC *** == PPMC + IPMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate ACE from the Apache Incubator
Well, I agree and disagree at the same time :-). On the one hand (as pointed out by Guillaume Nodet), we should have generated the source distribution for each bundle. We switched to a newer parent pom and did miss that we should have configured that. This makes it not very practical to build the release and we for sure will configure it next time. On the other hand, we don't want to provide a single source distribution for all bundles as we still want to release our bundles independently from each other. In summary, the next release will contain easier to build source distributions for each bundle but not a single source distribution for all of them. That is a good catch overall but I don't think it makes this release invalid (as the required things are there - just unfortunately not very practical to build). As we are planning to roll a 1.0.0 release anyways when graduated, I'd say lets ask for graduation and then provide a 1.0.0 release which has the source distribution configured per bundle. How about that? regards, Karl On Mon, Nov 21, 2011 at 2:56 AM, ant elder antel...@apache.org wrote: That seems an unusual approach to building the src. It also means that to build the complete 0.8.0 release which contains 60 something modules would require manually typing in over 400 commands which is not very practical, i doubt anyone who voted +1 for the release actually did that. I think an ASF release like this should have also had a single source distribution that contained all the source for all those modules along with a build script to build them, and IMHO your mentors should have helped you do that. Would you consider doing another release like this before you graduate? ...ant On Thu, Nov 17, 2011 at 2:07 PM, Karl Pauls karlpa...@gmail.com wrote: $ mkdir org.apache.ace.client.automation-0.8.0-incubator $ cd org.apache.ace.client.automation-0.8.0-incubator/ $ wget http://www.apache.org/dist/incubator/ace/org.apache.ace.client.automation-0.8.0-incubator-source.jar $ jar -xf org.apache.ace.client.automation-0.8.0-incubator-sources.jar $ wget http://www.apache.org/dist/incubator/ace/org.apache.ace.client.automation-0.8.0-incubator.pom $ mv org.apache.ace.client.automation-0.8.0-incubator.pom pom.xml $ mvn clean install regards, Karl On Thu, Nov 17, 2011 at 2:54 PM, ant elder ant.el...@gmail.com wrote: To try that I just went to the ACE downloads page which has a bunch of jars and source jars to download, i downloaded the source of the first one, org.apache.ace.client.automation-0.8.0-incubator-sources.jar, and looking inside there is the source to some Java classes but no build scripts or pom.xml file, so how would I go about building this? ...ant On Thu, Nov 17, 2011 at 1:35 PM, Karl Pauls karlpa...@gmail.com wrote: Again, we had this discussion before namely, when the actual release vote happened. I'm still confused why we have to go through this again. You should be able to build all of the components by using the -source.jar's that are provided. They contain what is necessary i.e., the full source. regards, Karl On Thu, Nov 17, 2011 at 2:30 PM, sebb seb...@gmail.com wrote: On 17 November 2011 12:29, Karl Pauls karlpa...@gmail.com wrote: I'm not sure what this has to do with the graduation vote. The release as such has been accepted by the incubator pmc and there only need to be one release. The source for each artifact is there, it is just per artifact in the -source.jar. AFAICT the full source (as in SVN trunk) is not actually present in the distribution directory. For example, where are the top-level files in SVN (BUILDING, README) ? And the etc/ directory? If I wanted to build any or all of the components, there does not appear to be a way to do this from the files in the distribution. There might be different set-up then a lot of other projects have it but we release our stuff on a per artifact basis how it is done by for example Apache Felix as well and never has been an issue (and didn't become unmanageably either - also ymmv). The ASF primarily releases source; releases must include full source. I agree about the KEYS file. We should have uploaded it to the dist dir as well but at least we have it at some place so it should be easy to fix. regards, Karl On Thu, Nov 17, 2011 at 1:07 PM, sebb seb...@gmail.com wrote: On 17 November 2011 10:42, Marcel Offermans marcel.offerm...@luminis.nl wrote: In my opinion, ACE is ready to begin the process of graduating from the Apache Incubator to a Top Level Project. Since joining the incubator in in May 2009 we've added 4 new committers (12 in total now) from diverse organizations and did a release in May this year to demonstrate we follow the Apache guidelines. We've shown an ability to self-govern using accepted Apache practices and ACE continues to attract new contributors and users. The first step is to vote as a community, demonstrating that ACE
Re: [VOTE] Graduate ACE from the Apache Incubator
On Mon, Nov 21, 2011 at 3:08 PM, ant elder antel...@apache.org wrote: Well IMHO i don't think this release demonstrates that the poddling has an understanding of making or reviewing ASF releases and thats the point of requiring releases during incubation. So you want us to do a new release? Fine, whatever, we can just roll a new release which has the source distribution configured. That was a mistake in the first place as it makes the bundles not easily individually buildable. However, we still will not have a combined source release as we want to be able to release our bundles individually. Is that the resolution then? All we have to do is a do a micro release with the source distribution configured on a per artifact level? The comment from Guillaume in this thread was just about naming the SVN folder containing the tags releases instead of tags which no one is saying is a major issue. No, he had two remarks, one about the tags and one about the source releases. regards, Karl ...ant On Mon, Nov 21, 2011 at 1:47 PM, Karl Pauls karlpa...@gmail.com wrote: Well, I agree and disagree at the same time :-). On the one hand (as pointed out by Guillaume Nodet), we should have generated the source distribution for each bundle. We switched to a newer parent pom and did miss that we should have configured that. This makes it not very practical to build the release and we for sure will configure it next time. On the other hand, we don't want to provide a single source distribution for all bundles as we still want to release our bundles independently from each other. In summary, the next release will contain easier to build source distributions for each bundle but not a single source distribution for all of them. That is a good catch overall but I don't think it makes this release invalid (as the required things are there - just unfortunately not very practical to build). As we are planning to roll a 1.0.0 release anyways when graduated, I'd say lets ask for graduation and then provide a 1.0.0 release which has the source distribution configured per bundle. How about that? regards, Karl On Mon, Nov 21, 2011 at 2:56 AM, ant elder antel...@apache.org wrote: That seems an unusual approach to building the src. It also means that to build the complete 0.8.0 release which contains 60 something modules would require manually typing in over 400 commands which is not very practical, i doubt anyone who voted +1 for the release actually did that. I think an ASF release like this should have also had a single source distribution that contained all the source for all those modules along with a build script to build them, and IMHO your mentors should have helped you do that. Would you consider doing another release like this before you graduate? ...ant On Thu, Nov 17, 2011 at 2:07 PM, Karl Pauls karlpa...@gmail.com wrote: $ mkdir org.apache.ace.client.automation-0.8.0-incubator $ cd org.apache.ace.client.automation-0.8.0-incubator/ $ wget http://www.apache.org/dist/incubator/ace/org.apache.ace.client.automation-0.8.0-incubator-source.jar $ jar -xf org.apache.ace.client.automation-0.8.0-incubator-sources.jar $ wget http://www.apache.org/dist/incubator/ace/org.apache.ace.client.automation-0.8.0-incubator.pom $ mv org.apache.ace.client.automation-0.8.0-incubator.pom pom.xml $ mvn clean install regards, Karl On Thu, Nov 17, 2011 at 2:54 PM, ant elder ant.el...@gmail.com wrote: To try that I just went to the ACE downloads page which has a bunch of jars and source jars to download, i downloaded the source of the first one, org.apache.ace.client.automation-0.8.0-incubator-sources.jar, and looking inside there is the source to some Java classes but no build scripts or pom.xml file, so how would I go about building this? ...ant On Thu, Nov 17, 2011 at 1:35 PM, Karl Pauls karlpa...@gmail.com wrote: Again, we had this discussion before namely, when the actual release vote happened. I'm still confused why we have to go through this again. You should be able to build all of the components by using the -source.jar's that are provided. They contain what is necessary i.e., the full source. regards, Karl On Thu, Nov 17, 2011 at 2:30 PM, sebb seb...@gmail.com wrote: On 17 November 2011 12:29, Karl Pauls karlpa...@gmail.com wrote: I'm not sure what this has to do with the graduation vote. The release as such has been accepted by the incubator pmc and there only need to be one release. The source for each artifact is there, it is just per artifact in the -source.jar. AFAICT the full source (as in SVN trunk) is not actually present in the distribution directory. For example, where are the top-level files in SVN (BUILDING, README) ? And the etc/ directory? If I wanted to build any or all of the components, there does not appear to be a way to do this from the files in the distribution. There might be different set-up then a lot of other
Re: [VOTE] Graduate ACE from the Apache Incubator
On Mon, Nov 21, 2011 at 4:11 PM, ant elder ant.el...@gmail.com wrote: On Mon, Nov 21, 2011 at 3:03 PM, Richard S. Hall he...@ungoverned.org wrote: On 11/21/11 09:41 , ant elder wrote: On Mon, Nov 21, 2011 at 2:18 PM, Karl Paulskarlpa...@gmail.com wrote: On Mon, Nov 21, 2011 at 3:08 PM, ant elderantel...@apache.org wrote: Well IMHO i don't think this release demonstrates that the poddling has an understanding of making or reviewing ASF releases and thats the point of requiring releases during incubation. So you want us to do a new release? Fine, whatever, we can just roll a new release which has the source distribution configured. That was a mistake in the first place as it makes the bundles not easily individually buildable. However, we still will not have a combined source release as we want to be able to release our bundles individually. Is that the resolution then? All we have to do is a do a micro release with the source distribution configured on a per artifact level? I agree the requirement for a single source release doesn't seem totally clear, I've said I think you should have one and so has sebb, it would be good to hear what other Incubator PMC people think. I think you need one for two main reasons: 1) The ASF deals with source and the releases are how users get hold of that source. If a user is going to do development with the released ACE source they likely aren't going to be able to do very much useful with just single things like org.apache.ace.repository.imp. At the very least they're probably going to want org.apache.ace.repository.api too but likely there is a big network of the 60 something ACE modules that anyone doing most non-trivial ACE development is going to want. One source distribution makes this easy, making them have to download them all separately isn't particularly practical. That https://svn.apache.org/repos/asf/incubator/ace/trunk/ is structured so the ASF committers can work with them as one single buildable checkout i think shows thats true. 2) If there is only individually buildable source for each jar how are people really going to verify that the release is actually buildable and the artifacts match the SVN tag source when reviewing and voting on release votes? No one reviewing is really likely to download 60 separate distros and build them all one by one are they? I disagree. There seems to be some misunderstanding that there is one single product that must be built. When you develop independently evolving modules, big bang releases do not make sense. Each module has its own release cycle. Occasionally you may end up creating some sort of distribution out of the modules and release that, but that is just one potential distribution. I agree thats an approach used and works in many projects but if that was really the case _here_ then surely the SVN would be structured so that there were separate trunk/branch/tag folders for each module, there would have been more releases than just the single 0.8.0 release, and there would be separate release votes for each module being released. We have a tag per module and that is enough. Furthermore, we do combine several modules if it makes sense (i.e., we want to release them at the same time) in one vote as it would otherwise create a lot of extra traffic. That's all. It is the same set-up some of the other OSGi projects at the asf have (I did quite a lot of their releases). The only thing we missed was the source distributions per artifact. regards, Karl ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate ACE from the Apache Incubator
On Mon, Nov 21, 2011 at 4:31 PM, Joe Schaefer joe_schae...@yahoo.com wrote: I'm confused. In /dist/incubator/ace/, there appears to be an *.incubator-sources.* file for each independent module in the release. Are those not actually what they are advertised to be? What exactly is the problem with the previous release? It has been argued that they are hard to build because they don't contain the pom files (they are in the dist dir too, but as another download). We forgot to configure that in the build. Typically, we make it so that the source artifacts contain the pom as well so all you have to do is to unzip the source distro of a module, cd into it, and mvn clean install. In this case, you have to download the pom first as well. regards, Karl From: Alex Karasulu akaras...@apache.org To: general@incubator.apache.org Sent: Monday, November 21, 2011 10:23 AM Subject: Re: [VOTE] Graduate ACE from the Apache Incubator On Mon, Nov 21, 2011 at 5:18 PM, Karl Pauls karlpa...@gmail.com wrote: On Mon, Nov 21, 2011 at 4:11 PM, ant elder ant.el...@gmail.com wrote: On Mon, Nov 21, 2011 at 3:03 PM, Richard S. Hall he...@ungoverned.org wrote: On 11/21/11 09:41 , ant elder wrote: On Mon, Nov 21, 2011 at 2:18 PM, Karl Paulskarlpa...@gmail.com wrote: On Mon, Nov 21, 2011 at 3:08 PM, ant elderantel...@apache.org wrote: Well IMHO i don't think this release demonstrates that the poddling has an understanding of making or reviewing ASF releases and thats the point of requiring releases during incubation. So you want us to do a new release? Fine, whatever, we can just roll a new release which has the source distribution configured. That was a mistake in the first place as it makes the bundles not easily individually buildable. However, we still will not have a combined source release as we want to be able to release our bundles individually. Is that the resolution then? All we have to do is a do a micro release with the source distribution configured on a per artifact level? I agree the requirement for a single source release doesn't seem totally clear, I've said I think you should have one and so has sebb, it would be good to hear what other Incubator PMC people think. I think you need one for two main reasons: 1) The ASF deals with source and the releases are how users get hold of that source. If a user is going to do development with the released ACE source they likely aren't going to be able to do very much useful with just single things like org.apache.ace.repository.imp. At the very least they're probably going to want org.apache.ace.repository.api too but likely there is a big network of the 60 something ACE modules that anyone doing most non-trivial ACE development is going to want. One source distribution makes this easy, making them have to download them all separately isn't particularly practical. That https://svn.apache.org/repos/asf/incubator/ace/trunk/ is structured so the ASF committers can work with them as one single buildable checkout i think shows thats true. 2) If there is only individually buildable source for each jar how are people really going to verify that the release is actually buildable and the artifacts match the SVN tag source when reviewing and voting on release votes? No one reviewing is really likely to download 60 separate distros and build them all one by one are they? I disagree. There seems to be some misunderstanding that there is one single product that must be built. When you develop independently evolving modules, big bang releases do not make sense. Each module has its own release cycle. Occasionally you may end up creating some sort of distribution out of the modules and release that, but that is just one potential distribution. I agree thats an approach used and works in many projects but if that was really the case _here_ then surely the SVN would be structured so that there were separate trunk/branch/tag folders for each module, there would have been more releases than just the single 0.8.0 release, and there would be separate release votes for each module being released. We have a tag per module and that is enough. Furthermore, we do combine several modules if it makes sense (i.e., we want to release them at the same time) in one vote as it would otherwise create a lot of extra traffic. That's all. It is the same set-up some of the other OSGi projects at the asf have (I did quite a lot of their releases). The only thing we missed was the source distributions per artifact. And that IMHO is not enough to consider the release a failure. Let it be noted and corrected for future releases. AFAIC there's no reason to hold this podling back because of some minor release inconsistencies which are natural as we shift from monolithic products to component based OSGi products. Best, Alex -- Karl
Re: [VOTE] Graduate ACE from the Apache Incubator
I'm not sure what this has to do with the graduation vote. The release as such has been accepted by the incubator pmc and there only need to be one release. The source for each artifact is there, it is just per artifact in the -source.jar. There might be different set-up then a lot of other projects have it but we release our stuff on a per artifact basis how it is done by for example Apache Felix as well and never has been an issue (and didn't become unmanageably either - also ymmv). I agree about the KEYS file. We should have uploaded it to the dist dir as well but at least we have it at some place so it should be easy to fix. regards, Karl On Thu, Nov 17, 2011 at 1:07 PM, sebb seb...@gmail.com wrote: On 17 November 2011 10:42, Marcel Offermans marcel.offerm...@luminis.nl wrote: In my opinion, ACE is ready to begin the process of graduating from the Apache Incubator to a Top Level Project. Since joining the incubator in in May 2009 we've added 4 new committers (12 in total now) from diverse organizations and did a release in May this year to demonstrate we follow the Apache guidelines. We've shown an ability to self-govern using accepted Apache practices and ACE continues to attract new contributors and users. The first step is to vote as a community, demonstrating that ACE is ready and willing to graduate. Once this vote is succesful we create a board resolution proposal or Charter and start a vote on the general incubator list. The full process is described at http://incubator.apache.org/guides/graduation.html#toplevel The vote is open for at least 72 hours. The last (and only) release was 0.8, as far as I can tell. There is no KEYS file in http://www.apache.org/dist/incubator/ace/, and there does not appear to be a full source archive of the project anywhere. The download page does not have a link to any source archives as far as I can tell. It does link to KEYS in SVN, but almost all other ASF projects have a copy of KEYS in the appropriate /dist directory. Normally releases are divided into binaries/ and source/ directories, with a KEYS file in the top-level, i.e. /dist/incubator/ace - KEYS - binaries/ace zip - sources/acezip Most of the files in the /dist/incubator/ace directory appear to be Maven artifacts; normally these are not stored in /dist but only in the Maven repo. Indeed most of the files are also in Maven Central. The only non-Maven files appear to be org.apache.ace.target.devgateway-0.8.0-incubator-distribution.zip org.apache.ace.target.devserver-0.8.0-incubator-distribution.zip neither of which contains the source. I would expect the above zips to be in /dist/incubator/ace/binaries with corresponding source files in /dist/incubator/ace/source The SVN layout [1] is also a bit unusual. There is no tags/ directory for release tags, although there is a releases/ directory containing individual entries for each release for each component. This is likely to become unmanageable very quickly, if every release adds another 63 directory entries under releases/ [1] https://svn.apache.org/repos/asf/incubator/ace/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate ACE from the Apache Incubator
Again, we had this discussion before namely, when the actual release vote happened. I'm still confused why we have to go through this again. You should be able to build all of the components by using the -source.jar's that are provided. They contain what is necessary i.e., the full source. regards, Karl On Thu, Nov 17, 2011 at 2:30 PM, sebb seb...@gmail.com wrote: On 17 November 2011 12:29, Karl Pauls karlpa...@gmail.com wrote: I'm not sure what this has to do with the graduation vote. The release as such has been accepted by the incubator pmc and there only need to be one release. The source for each artifact is there, it is just per artifact in the -source.jar. AFAICT the full source (as in SVN trunk) is not actually present in the distribution directory. For example, where are the top-level files in SVN (BUILDING, README) ? And the etc/ directory? If I wanted to build any or all of the components, there does not appear to be a way to do this from the files in the distribution. There might be different set-up then a lot of other projects have it but we release our stuff on a per artifact basis how it is done by for example Apache Felix as well and never has been an issue (and didn't become unmanageably either - also ymmv). The ASF primarily releases source; releases must include full source. I agree about the KEYS file. We should have uploaded it to the dist dir as well but at least we have it at some place so it should be easy to fix. regards, Karl On Thu, Nov 17, 2011 at 1:07 PM, sebb seb...@gmail.com wrote: On 17 November 2011 10:42, Marcel Offermans marcel.offerm...@luminis.nl wrote: In my opinion, ACE is ready to begin the process of graduating from the Apache Incubator to a Top Level Project. Since joining the incubator in in May 2009 we've added 4 new committers (12 in total now) from diverse organizations and did a release in May this year to demonstrate we follow the Apache guidelines. We've shown an ability to self-govern using accepted Apache practices and ACE continues to attract new contributors and users. The first step is to vote as a community, demonstrating that ACE is ready and willing to graduate. Once this vote is succesful we create a board resolution proposal or Charter and start a vote on the general incubator list. The full process is described at http://incubator.apache.org/guides/graduation.html#toplevel The vote is open for at least 72 hours. The last (and only) release was 0.8, as far as I can tell. There is no KEYS file in http://www.apache.org/dist/incubator/ace/, and there does not appear to be a full source archive of the project anywhere. The download page does not have a link to any source archives as far as I can tell. It does link to KEYS in SVN, but almost all other ASF projects have a copy of KEYS in the appropriate /dist directory. Normally releases are divided into binaries/ and source/ directories, with a KEYS file in the top-level, i.e. /dist/incubator/ace - KEYS - binaries/ace zip - sources/acezip Most of the files in the /dist/incubator/ace directory appear to be Maven artifacts; normally these are not stored in /dist but only in the Maven repo. Indeed most of the files are also in Maven Central. The only non-Maven files appear to be org.apache.ace.target.devgateway-0.8.0-incubator-distribution.zip org.apache.ace.target.devserver-0.8.0-incubator-distribution.zip neither of which contains the source. I would expect the above zips to be in /dist/incubator/ace/binaries with corresponding source files in /dist/incubator/ace/source The SVN layout [1] is also a bit unusual. There is no tags/ directory for release tags, although there is a releases/ directory containing individual entries for each release for each component. This is likely to become unmanageable very quickly, if every release adds another 63 directory entries under releases/ [1] https://svn.apache.org/repos/asf/incubator/ace/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls - 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 -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
Re: [VOTE] Graduate ACE from the Apache Incubator
On Thu, Nov 17, 2011 at 2:34 PM, sebb seb...@gmail.com wrote: On 17 November 2011 12:51, Guillaume Nodet gno...@gmail.com wrote: As much as I don't like this layout, this is not the first projet to use it, and I don't really see how / why the IPMC should decide the svn layout for the project. You won't be the one to manage it daily afaik, so that's not up to you to decide imho. The SVN layout is less of a concern, although the lack of a single tag for a release is odd. Not all of the files in SVN trunk appear in releases/ Why would they have to? We don't release the complete svn trunk but only the part of it that we want to release. Again, we have a modular layout and we only release the modules we want to at a given time _without_ releasing the complete trunk every time. Yes, that is more work but we from the osgi/modular world prefer it over the problems we get with big-bang releases. That said, each binary artifact contains the necessary legal files and -source.jar's are provided that contain the full source and necessary legal files. I admit that it might take some getting used to if you don't know maven well or are not used to modular osgi bundle releases but please, look at the artifacts that have been released - not at the svn trunk. We don't release the trunk, we release releases. They must have legal files and full source and they do. regards, Karl Sling and Felix already use such a layout and they are both TLP, so I really don't see that as a problem. On Thu, Nov 17, 2011 at 13:07, sebb seb...@gmail.com wrote: On 17 November 2011 10:42, Marcel Offermans marcel.offerm...@luminis.nl wrote: In my opinion, ACE is ready to begin the process of graduating from the Apache Incubator to a Top Level Project. Since joining the incubator in in May 2009 we've added 4 new committers (12 in total now) from diverse organizations and did a release in May this year to demonstrate we follow the Apache guidelines. We've shown an ability to self-govern using accepted Apache practices and ACE continues to attract new contributors and users. The first step is to vote as a community, demonstrating that ACE is ready and willing to graduate. Once this vote is succesful we create a board resolution proposal or Charter and start a vote on the general incubator list. The full process is described at http://incubator.apache.org/guides/graduation.html#toplevel The vote is open for at least 72 hours. The last (and only) release was 0.8, as far as I can tell. There is no KEYS file in http://www.apache.org/dist/incubator/ace/, and there does not appear to be a full source archive of the project anywhere. The download page does not have a link to any source archives as far as I can tell. It does link to KEYS in SVN, but almost all other ASF projects have a copy of KEYS in the appropriate /dist directory. Normally releases are divided into binaries/ and source/ directories, with a KEYS file in the top-level, i.e. /dist/incubator/ace - KEYS - binaries/ace zip - sources/acezip Most of the files in the /dist/incubator/ace directory appear to be Maven artifacts; normally these are not stored in /dist but only in the Maven repo. Indeed most of the files are also in Maven Central. The only non-Maven files appear to be org.apache.ace.target.devgateway-0.8.0-incubator-distribution.zip org.apache.ace.target.devserver-0.8.0-incubator-distribution.zip neither of which contains the source. I would expect the above zips to be in /dist/incubator/ace/binaries with corresponding source files in /dist/incubator/ace/source The SVN layout [1] is also a bit unusual. There is no tags/ directory for release tags, although there is a releases/ directory containing individual entries for each release for each component. This is likely to become unmanageable very quickly, if every release adds another 63 directory entries under releases/ [1] https://svn.apache.org/repos/asf/incubator/ace/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate ACE from the Apache Incubator
$ mkdir org.apache.ace.client.automation-0.8.0-incubator $ cd org.apache.ace.client.automation-0.8.0-incubator/ $ wget http://www.apache.org/dist/incubator/ace/org.apache.ace.client.automation-0.8.0-incubator-source.jar $ jar -xf org.apache.ace.client.automation-0.8.0-incubator-sources.jar $ wget http://www.apache.org/dist/incubator/ace/org.apache.ace.client.automation-0.8.0-incubator.pom $ mv org.apache.ace.client.automation-0.8.0-incubator.pom pom.xml $ mvn clean install regards, Karl On Thu, Nov 17, 2011 at 2:54 PM, ant elder ant.el...@gmail.com wrote: To try that I just went to the ACE downloads page which has a bunch of jars and source jars to download, i downloaded the source of the first one, org.apache.ace.client.automation-0.8.0-incubator-sources.jar, and looking inside there is the source to some Java classes but no build scripts or pom.xml file, so how would I go about building this? ...ant On Thu, Nov 17, 2011 at 1:35 PM, Karl Pauls karlpa...@gmail.com wrote: Again, we had this discussion before namely, when the actual release vote happened. I'm still confused why we have to go through this again. You should be able to build all of the components by using the -source.jar's that are provided. They contain what is necessary i.e., the full source. regards, Karl On Thu, Nov 17, 2011 at 2:30 PM, sebb seb...@gmail.com wrote: On 17 November 2011 12:29, Karl Pauls karlpa...@gmail.com wrote: I'm not sure what this has to do with the graduation vote. The release as such has been accepted by the incubator pmc and there only need to be one release. The source for each artifact is there, it is just per artifact in the -source.jar. AFAICT the full source (as in SVN trunk) is not actually present in the distribution directory. For example, where are the top-level files in SVN (BUILDING, README) ? And the etc/ directory? If I wanted to build any or all of the components, there does not appear to be a way to do this from the files in the distribution. There might be different set-up then a lot of other projects have it but we release our stuff on a per artifact basis how it is done by for example Apache Felix as well and never has been an issue (and didn't become unmanageably either - also ymmv). The ASF primarily releases source; releases must include full source. I agree about the KEYS file. We should have uploaded it to the dist dir as well but at least we have it at some place so it should be easy to fix. regards, Karl On Thu, Nov 17, 2011 at 1:07 PM, sebb seb...@gmail.com wrote: On 17 November 2011 10:42, Marcel Offermans marcel.offerm...@luminis.nl wrote: In my opinion, ACE is ready to begin the process of graduating from the Apache Incubator to a Top Level Project. Since joining the incubator in in May 2009 we've added 4 new committers (12 in total now) from diverse organizations and did a release in May this year to demonstrate we follow the Apache guidelines. We've shown an ability to self-govern using accepted Apache practices and ACE continues to attract new contributors and users. The first step is to vote as a community, demonstrating that ACE is ready and willing to graduate. Once this vote is succesful we create a board resolution proposal or Charter and start a vote on the general incubator list. The full process is described at http://incubator.apache.org/guides/graduation.html#toplevel The vote is open for at least 72 hours. The last (and only) release was 0.8, as far as I can tell. There is no KEYS file in http://www.apache.org/dist/incubator/ace/, and there does not appear to be a full source archive of the project anywhere. The download page does not have a link to any source archives as far as I can tell. It does link to KEYS in SVN, but almost all other ASF projects have a copy of KEYS in the appropriate /dist directory. Normally releases are divided into binaries/ and source/ directories, with a KEYS file in the top-level, i.e. /dist/incubator/ace - KEYS - binaries/ace zip - sources/acezip Most of the files in the /dist/incubator/ace directory appear to be Maven artifacts; normally these are not stored in /dist but only in the Maven repo. Indeed most of the files are also in Maven Central. The only non-Maven files appear to be org.apache.ace.target.devgateway-0.8.0-incubator-distribution.zip org.apache.ace.target.devserver-0.8.0-incubator-distribution.zip neither of which contains the source. I would expect the above zips to be in /dist/incubator/ace/binaries with corresponding source files in /dist/incubator/ace/source The SVN layout [1] is also a bit unusual. There is no tags/ directory for release tags, although there is a releases/ directory containing individual entries for each release for each component. This is likely to become unmanageable very quickly, if every release adds another 63 directory entries under releases/ [1] https
Re: [VOTE] Graduate ACE from the Apache Incubator
On Thu, Nov 17, 2011 at 3:45 PM, Guillaume Nodet gno...@gmail.com wrote: On Thu, Nov 17, 2011 at 14:30, sebb seb...@gmail.com wrote: On 17 November 2011 12:29, Karl Pauls karlpa...@gmail.com wrote: I'm not sure what this has to do with the graduation vote. The release as such has been accepted by the incubator pmc and there only need to be one release. The source for each artifact is there, it is just per artifact in the -source.jar. AFAICT the full source (as in SVN trunk) is not actually present in the distribution directory. For example, where are the top-level files in SVN (BUILDING, README) ? And the etc/ directory? If I wanted to build any or all of the components, there does not appear to be a way to do this from the files in the distribution. The svn tree is not supposed to be a source distribution so looking at it as a buildable thing is not required. There might be different set-up then a lot of other projects have it but we release our stuff on a per artifact basis how it is done by for example Apache Felix as well and never has been an issue (and didn't become unmanageably either - also ymmv). The ASF primarily releases source; releases must include full source. I agree on the first part, but not the *full* source. @ace you should look at the felix way which always include a source distribution for each bundle. Yeah, we could have configured the source-release, i agree. However, i don't think that is a show-stopper (as much as it could be anyhow, as the release already happend) as we have the source and what is need to build. Another way to get this is to go to the tags at: http://svn.apache.org/repos/asf/incubator/ace/releases/$subproject regards, Karl I agree about the KEYS file. We should have uploaded it to the dist dir as well but at least we have it at some place so it should be easy to fix. regards, Karl On Thu, Nov 17, 2011 at 1:07 PM, sebb seb...@gmail.com wrote: On 17 November 2011 10:42, Marcel Offermans marcel.offerm...@luminis.nl wrote: In my opinion, ACE is ready to begin the process of graduating from the Apache Incubator to a Top Level Project. Since joining the incubator in in May 2009 we've added 4 new committers (12 in total now) from diverse organizations and did a release in May this year to demonstrate we follow the Apache guidelines. We've shown an ability to self-govern using accepted Apache practices and ACE continues to attract new contributors and users. The first step is to vote as a community, demonstrating that ACE is ready and willing to graduate. Once this vote is succesful we create a board resolution proposal or Charter and start a vote on the general incubator list. The full process is described at http://incubator.apache.org/guides/graduation.html#toplevel The vote is open for at least 72 hours. The last (and only) release was 0.8, as far as I can tell. There is no KEYS file in http://www.apache.org/dist/incubator/ace/, and there does not appear to be a full source archive of the project anywhere. The download page does not have a link to any source archives as far as I can tell. It does link to KEYS in SVN, but almost all other ASF projects have a copy of KEYS in the appropriate /dist directory. Normally releases are divided into binaries/ and source/ directories, with a KEYS file in the top-level, i.e. /dist/incubator/ace - KEYS - binaries/ace zip - sources/acezip Most of the files in the /dist/incubator/ace directory appear to be Maven artifacts; normally these are not stored in /dist but only in the Maven repo. Indeed most of the files are also in Maven Central. The only non-Maven files appear to be org.apache.ace.target.devgateway-0.8.0-incubator-distribution.zip org.apache.ace.target.devserver-0.8.0-incubator-distribution.zip neither of which contains the source. I would expect the above zips to be in /dist/incubator/ace/binaries with corresponding source files in /dist/incubator/ace/source The SVN layout [1] is also a bit unusual. There is no tags/ directory for release tags, although there is a releases/ directory containing individual entries for each release for each component. This is likely to become unmanageable very quickly, if every release adds another 63 directory entries under releases/ [1] https://svn.apache.org/repos/asf/incubator/ace/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
Re: [VOTE] Graduate ACE from the Apache Incubator
Again, I'm not against doing things differently for future release (and the reason this release looks like it does is because that is configured like this in the apache-parent iirc). However, I'm still confused what all of this has to do with the graduation proposal vote and why this has to be on general@. The release vote has passed a while ago and I don't see that the release is invalid because we don't use a certain svn layout or maven config. The source is in dist and the tags are in svn. I suggest we move discussion about future release layouts to the ace-dev list and into a separate thread unless you disagree. regards, Karl On Thu, Nov 17, 2011 at 4:09 PM, sebb seb...@gmail.com wrote: On 17 November 2011 14:07, Karl Pauls karlpa...@gmail.com wrote: $ mkdir org.apache.ace.client.automation-0.8.0-incubator $ cd org.apache.ace.client.automation-0.8.0-incubator/ $ wget http://www.apache.org/dist/incubator/ace/org.apache.ace.client.automation-0.8.0-incubator-source.jar s/source/sources/ $ jar -xf org.apache.ace.client.automation-0.8.0-incubator-sources.jar $ wget http://www.apache.org/dist/incubator/ace/org.apache.ace.client.automation-0.8.0-incubator.pom $ mv org.apache.ace.client.automation-0.8.0-incubator.pom pom.xml $ mvn clean install = Not exactly trivial compared with $ svn co http://svn.apache.org/repos/asf/incubator/ace/releases/org.apache.ace.client.automation-0.8.0-incubator -- or -- $ unzip org.apache.ace.client.automation-0.8.0-incubator-source.zip (if it existed) and then $ cd org.apache.ace.client.automation-0.8.0-incubator $ mvn clean install There's another (bigger) problem with the existing -sources.jar files. They don't contain any unit tests, as far as I can tell, yet there are some unit tests in SVN. Surely the unit tests should be distributed as part of the source release? == This is quite easy to fix, just (vote on and) release zip/tar.gz archives of the tags for each component. I would drop the -sources.jar files from /dist as they aren't all that useful for non-Maven downloads. == To make it easier to navigate the dist/ directory, may I suggest creating binaries/ and source/ folders? The source/ folder would contain all the current source zips/tgz archives The binaries folders would contain binary jars and javadoc jars The *.pom files would be removed, as the pom.xml files would be in the appropriate source/ archive. regards, Karl On Thu, Nov 17, 2011 at 2:54 PM, ant elder ant.el...@gmail.com wrote: To try that I just went to the ACE downloads page which has a bunch of jars and source jars to download, i downloaded the source of the first one, org.apache.ace.client.automation-0.8.0-incubator-sources.jar, and looking inside there is the source to some Java classes but no build scripts or pom.xml file, so how would I go about building this? ...ant On Thu, Nov 17, 2011 at 1:35 PM, Karl Pauls karlpa...@gmail.com wrote: Again, we had this discussion before namely, when the actual release vote happened. I'm still confused why we have to go through this again. You should be able to build all of the components by using the -source.jar's that are provided. They contain what is necessary i.e., the full source. regards, Karl On Thu, Nov 17, 2011 at 2:30 PM, sebb seb...@gmail.com wrote: On 17 November 2011 12:29, Karl Pauls karlpa...@gmail.com wrote: I'm not sure what this has to do with the graduation vote. The release as such has been accepted by the incubator pmc and there only need to be one release. The source for each artifact is there, it is just per artifact in the -source.jar. AFAICT the full source (as in SVN trunk) is not actually present in the distribution directory. For example, where are the top-level files in SVN (BUILDING, README) ? And the etc/ directory? If I wanted to build any or all of the components, there does not appear to be a way to do this from the files in the distribution. There might be different set-up then a lot of other projects have it but we release our stuff on a per artifact basis how it is done by for example Apache Felix as well and never has been an issue (and didn't become unmanageably either - also ymmv). The ASF primarily releases source; releases must include full source. I agree about the KEYS file. We should have uploaded it to the dist dir as well but at least we have it at some place so it should be easy to fix. regards, Karl On Thu, Nov 17, 2011 at 1:07 PM, sebb seb...@gmail.com wrote: On 17 November 2011 10:42, Marcel Offermans marcel.offerm...@luminis.nl wrote: In my opinion, ACE is ready to begin the process of graduating from the Apache Incubator to a Top Level Project. Since joining the incubator in in May 2009 we've added 4 new committers (12 in total now) from diverse organizations and did a release in May this year to demonstrate we follow the Apache guidelines. We've shown
Re: [VOTE] Graduate ACE from the Apache Incubator
JB, please, lets move this to the ace-dev list. regards, Karl On Thu, Nov 17, 2011 at 4:21 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Karl, we can simply need to revert the changes just before the 0.8.0-incubator release. When upgrading the ACE build to use Maven, firstly, we used the tags scm with Maven sub-modules. So I'm quite sure that reverting just before the 0.8.0-incubator, I can prepare that for the next ACE release. Regards JB On 11/17/2011 04:14 PM, Karl Pauls wrote: Again, I'm not against doing things differently for future release (and the reason this release looks like it does is because that is configured like this in the apache-parent iirc). However, I'm still confused what all of this has to do with the graduation proposal vote and why this has to be on general@. The release vote has passed a while ago and I don't see that the release is invalid because we don't use a certain svn layout or maven config. The source is in dist and the tags are in svn. I suggest we move discussion about future release layouts to the ace-dev list and into a separate thread unless you disagree. regards, Karl On Thu, Nov 17, 2011 at 4:09 PM, sebbseb...@gmail.com wrote: On 17 November 2011 14:07, Karl Paulskarlpa...@gmail.com wrote: $ mkdir org.apache.ace.client.automation-0.8.0-incubator $ cd org.apache.ace.client.automation-0.8.0-incubator/ $ wget http://www.apache.org/dist/incubator/ace/org.apache.ace.client.automation-0.8.0-incubator-source.jar s/source/sources/ $ jar -xf org.apache.ace.client.automation-0.8.0-incubator-sources.jar $ wget http://www.apache.org/dist/incubator/ace/org.apache.ace.client.automation-0.8.0-incubator.pom $ mv org.apache.ace.client.automation-0.8.0-incubator.pom pom.xml $ mvn clean install = Not exactly trivial compared with $ svn co http://svn.apache.org/repos/asf/incubator/ace/releases/org.apache.ace.client.automation-0.8.0-incubator -- or -- $ unzip org.apache.ace.client.automation-0.8.0-incubator-source.zip (if it existed) and then $ cd org.apache.ace.client.automation-0.8.0-incubator $ mvn clean install There's another (bigger) problem with the existing -sources.jar files. They don't contain any unit tests, as far as I can tell, yet there are some unit tests in SVN. Surely the unit tests should be distributed as part of the source release? == This is quite easy to fix, just (vote on and) release zip/tar.gz archives of the tags for each component. I would drop the -sources.jar files from /dist as they aren't all that useful for non-Maven downloads. == To make it easier to navigate the dist/ directory, may I suggest creating binaries/ and source/ folders? The source/ folder would contain all the current source zips/tgz archives The binaries folders would contain binary jars and javadoc jars The *.pom files would be removed, as the pom.xml files would be in the appropriate source/ archive. regards, Karl On Thu, Nov 17, 2011 at 2:54 PM, ant elderant.el...@gmail.com wrote: To try that I just went to the ACE downloads page which has a bunch of jars and source jars to download, i downloaded the source of the first one, org.apache.ace.client.automation-0.8.0-incubator-sources.jar, and looking inside there is the source to some Java classes but no build scripts or pom.xml file, so how would I go about building this? ...ant On Thu, Nov 17, 2011 at 1:35 PM, Karl Paulskarlpa...@gmail.com wrote: Again, we had this discussion before namely, when the actual release vote happened. I'm still confused why we have to go through this again. You should be able to build all of the components by using the -source.jar's that are provided. They contain what is necessary i.e., the full source. regards, Karl On Thu, Nov 17, 2011 at 2:30 PM, sebbseb...@gmail.com wrote: On 17 November 2011 12:29, Karl Paulskarlpa...@gmail.com wrote: I'm not sure what this has to do with the graduation vote. The release as such has been accepted by the incubator pmc and there only need to be one release. The source for each artifact is there, it is just per artifact in the -source.jar. AFAICT the full source (as in SVN trunk) is not actually present in the distribution directory. For example, where are the top-level files in SVN (BUILDING, README) ? And the etc/ directory? If I wanted to build any or all of the components, there does not appear to be a way to do this from the files in the distribution. There might be different set-up then a lot of other projects have it but we release our stuff on a per artifact basis how it is done by for example Apache Felix as well and never has been an issue (and didn't become unmanageably either - also ymmv). The ASF primarily releases source; releases must include full source. I agree about the KEYS file. We should have uploaded it to the dist dir as well but at least we have it at some place so
Re: [VOTE] Graduate ACE from the Apache Incubator
On Thu, Nov 17, 2011 at 4:38 PM, ant elder ant.el...@gmail.com wrote: On Thu, Nov 17, 2011 at 3:14 PM, Karl Pauls karlpa...@gmail.com wrote: Again, I'm not against doing things differently for future release (and the reason this release looks like it does is because that is configured like this in the apache-parent iirc). However, I'm still confused what all of this has to do with the graduation proposal vote and why this has to be on general@. I think why its come up here now is because part of judging if a poddling is ready to graduate is if they understand how to make and review ASF releases properly. And with whats be said here and how the source has to be built i'm wondering if anyone who voted +1 for the release would have actually tried to build any of the source. I guess the point is: are you arguing that the release should not haven been accepted by the incubator in the first place on the grounds that you find it hard to build and hence, you want to see a new one before the we can vote on approaching the incubator for a graduation? If yes, lets have that debate. If no, lets move this to a new thread on the ace-dev list. regards, Karl ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate ACE from the Apache Incubator
On Thu, Nov 17, 2011 at 4:56 PM, ant elder antel...@apache.org wrote: On Thu, Nov 17, 2011 at 3:47 PM, Karl Pauls karlpa...@gmail.com wrote: On Thu, Nov 17, 2011 at 4:38 PM, ant elder ant.el...@gmail.com wrote: On Thu, Nov 17, 2011 at 3:14 PM, Karl Pauls karlpa...@gmail.com wrote: Again, I'm not against doing things differently for future release (and the reason this release looks like it does is because that is configured like this in the apache-parent iirc). However, I'm still confused what all of this has to do with the graduation proposal vote and why this has to be on general@. I think why its come up here now is because part of judging if a poddling is ready to graduate is if they understand how to make and review ASF releases properly. And with whats be said here and how the source has to be built i'm wondering if anyone who voted +1 for the release would have actually tried to build any of the source. I guess the point is: are you arguing that the release should not haven been accepted by the incubator in the first place on the grounds that you find it hard to build and hence, you want to see a new one before the we can vote on approaching the incubator for a graduation? I'm not arguing anything yet. Some valid comments and questions were made in the vote thread, you asked why they were happening here and i tried to answer that. The Incubator people should have an opportunity to discuss a graduation, perhaps some of that might be better on a graduation discussion thread but there wasn't one of those before the vote. The release does look a bit dubious to me. Well, I understand that part and I agree that this is worthwhile to discuss. I'm just trying to get this sorted-out into something that we can discuss on the incubator level i.e., based on incubator requirements. In that sense, what are dubious points with the release that we as incubator pmc overlooked when voting on it? regards, Karl p.s.: Regarding the vote, let me make clear (in case it got missed): marcel did cc general@ on the community vote on whether we want to ask for graduation.This is not yet the actual incubator vote. Obviously, we better catch problems now so I think its good we have this discussion. ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept OpenOffice.org for incubation
://wiki.services.openoffice.org/wiki/User:DrewJensen|OpenOffice]] ||yes || ||Graham Lauder || yori...@openoffice.org ||!OpenOffice.org !MarCon [[http://marketing.openoffice.org/contacts.html|(Marketing Contact) New Zealand]] || || ||Florent André || flor...@apache.org ||individual ||yes || ||Allen Pulsifer ||pulsifer at openoffice.org ||individual || || ||Herbert Duerr || h...@openoffice.org ||individual || || ||Kazunari Hirano || khir...@openoffice.org ||individual || || ||Kent Åberg || kent.ab...@newformat.se ||[[http://www.newformat.se/newformat/eng/newformat-home-index.html|NewFormat]] || || ||Maho NAKATA || m...@openoffice.org ||ja/qa project lead, FBSD porting || || ||Miguel Á. Ríos ||mariosv@miguelangel dot mobi ||Individual || || ||Dave !McKay || thegur...@openoffice.org ||Individual || || ||Louis Suárez-Potts || lo...@openoffice.org ||individual || || ||Fernand Vanrie || s...@pmg.be ||individual || || ||Arthur Buijs || artie...@openoffice.org ||[[http://nl.openoffice.org/|Dutch Native Language Project]] ||Yes || ||Dave Barton || d...@tasit.net ||[[http://www.tutorialsforopenoffice.org|Tutorials For OpenOffice]] || || ||Jian Fang Zhang || zhan...@cn.ibm.com ||[[http://symphony.lotus.com|IBM, Symphony Chief Programmer, G11N, Security]] ||Yes || ||Zhe Wang || wangz...@cn.ibm.com ||[[http://symphony.lotus.com|IBM, Impress]] || || ||Don Harbison || donald_harbi...@us.ibm.com ||[[http://ibm.com/|IBM]] ||Yes || ||Jian Hong Cheng || chen...@cn.ibm.com ||[[http://symphony.lotus.com|IBM, Writer, Impress]] || || ||Chao Sun || sunc...@redoffice.com ||[[www.redoffice.com|RedOffice]] || || ||Heng Lee || lih...@redoffice.com ||[[www.redoffice.com|RedOffice]] || || ||Shu Wang Han || hanshuw...@redoffice.com ||[[www.redoffice.com|RedOffice]] || || ||Hong Yun An || anhong...@redoffice.com ||[[www.redoffice.com|RedOffice]] || || ||Jin Hua Chen || chenj...@cn.ibm.com ||IBM, Symphony Presentation || || ||Yegor Kozlov || ye...@apache.org ||individual ||yes || ||Juan C. Sanz || jucasac...@openoffice.org ||Spanish documentation || || ||Peter Junge || p...@openoffice.org ||Individual || || ||Cyril Beaussier ||oooforum at free dot fr ||[[http://user.services.openoffice.org/fr|French forum admin]],[[http://fr.openoffice.org/|French Project webmaster]] || || ||Damjan Jovanovic || dam...@apache.org ||individual ||yes || ||Fernando Cassia || fcas...@sdf.lonestar.org ||individual || || = Sponsors = == Champion == Sam Ruby, Apache Foundation == Nominated Mentors == Because of the scope and complexity of this proposed project, we believe that the incubation process would benefit from multiple mentors, especially ones willing to be the point person for each of the following disciplines: a. IP review a. infrastructure a. release management a. community development Mentors (these are all Members of the Foundation): * Jim Jagielski * Sam Ruby * Danese Cooper * Shane Curcuru * Nóirín Plunkett * Joe Schaefer * Christian Grobmeier * Ross Gardler == Sponsoring Entity == The Apache Incubator - 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 -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE][RESULT] Release ace version 0.8.0-incubator and related subprojects
The 72 hours lazy consensus for the IPMC are up and we did get one more +1 from Mohammad Nour El-Din** and no other votes. The vote is successful and approved. I will make the artifacts available asap. regards, Karl On Thu, May 26, 2011 at 10:48 PM, Karl Pauls karlpa...@gmail.com wrote: Time to call the vote on the ace version 0.8.0-incubator and subproject releases. * +1 votes from Jean-Baptiste Onofré*, Toni Menzel*, Angelo van der Sijpt*, Marcel Offermans***, Hadrain Zbarcea**, Carsten Ziegeler***, Clement Escoffier*, and Karl Pauls***. * No other votes The vote is successful. I will approach the Incubator PMC for approval. * == PPMC ** == IPMC *** == PPMC + IPMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release ace version 0.8.0-incubator and related subprojects
Hi, On Fri, May 27, 2011 at 4:58 PM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: Hi Karl... Most of things look OK, but I have some comments before giving my vote: Sure :-) 1- I can find the DISCLAIMER, LICENSE and NOTICE files *only* under these sub-projects: 1.1 - http://svn.apache.org/repos/asf/incubator/ace/releases/org.apache.ace.target.devgateway-0.8.0-incubator/ 1.2 - http://svn.apache.org/repos/asf/incubator/ace/releases/org.apache.ace.target.devserver-0.8.0-incubator/ They are included by maven when the artifact (as well as the source artifacts are build). Have a look at the staged artifacts (binaries and source). They should have the correct legal files. 2- I didn't find any e-mails sent to general@ indicating that there is a release under going in ace-dev@. There was none. Apologies if that is a requirement but as far as I understand the docs the idea was to have the release vote first and then approach the incubator. Now, given that we nevertheless already have 4 IPMC votes I'm just asking for lazy consensus - again, if any of this is against current policy please let me know (pointer to up to date documentation of the procedure would be much appreciated in that case). 3- The key used to sign the release is not trusted by anyone. Why not? You can get it from the ace svn: https://svn.apache.org/repos/asf/incubator/ace/trunk/KEYS furthermore, this key has been used by me to sign all apache felix framework releases ever made -- hence, is available from: https://svn.apache.org/repos/asf/felix/KEYS but also from: https://www.apache.org/dist/felix/KEYS Hope that helps? regards, Karl Looking forward to your reply. On Thu, May 26, 2011 at 11:06 PM, Karl Pauls karlpa...@gmail.com wrote: This is the first release of ace version 0.8.0-incubator and related subprojects We have already received 4 binding IPMC votes during the PPMC voting below, so I'm requesting a 72 hour lazy consensus before releasing the artifacts. The vote thread: http://mail-archives.apache.org/mod_mbox/incubator-ace-dev/201105.mbox/%3cbanlktimw_15axkojkwvsvtdhfopvb_f...@mail.gmail.com%3e regards, Karl -- Forwarded message -- From: Karl Pauls karlpa...@gmail.com Date: Thu, May 26, 2011 at 10:48 PM Subject: Re: [VOTE][RESULT] Release ace version 0.8.0-incubator and related subprojects To: ace-...@incubator.apache.org Time to call the vote on the ace version 0.8.0-incubator and subproject releases. * +1 votes from Jean-Baptiste Onofré*, Toni Menzel*, Angelo van der Sijpt*, Marcel Offermans***, Hadrain Zbarcea**, Carsten Ziegeler***, Clement Escoffier*, and Karl Pauls***. * No other votes The vote is successful. I will approach the Incubator PMC for approval. * == PPMC ** == IPMC *** == PPMC + IPMC -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Thanks - Mohammad Nour Author of (WebSphere Application Server Community Edition 2.0 User Guide) http://www.redbooks.ibm.com/abstracts/sg247585.html - LinkedIn: http://www.linkedin.com/in/mnour - Blog: http://tadabborat.blogspot.com Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best. - Clean Code: A Handbook of Agile Software Craftsmanship Stay hungry, stay foolish. - Steve Jobs - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Release ace version 0.8.0-incubator and related subprojects
This is the first release of ace version 0.8.0-incubator and related subprojects We have already received 4 binding IPMC votes during the PPMC voting below, so I'm requesting a 72 hour lazy consensus before releasing the artifacts. The vote thread: http://mail-archives.apache.org/mod_mbox/incubator-ace-dev/201105.mbox/%3cbanlktimw_15axkojkwvsvtdhfopvb_f...@mail.gmail.com%3e regards, Karl -- Forwarded message -- From: Karl Pauls karlpa...@gmail.com Date: Thu, May 26, 2011 at 10:48 PM Subject: Re: [VOTE][RESULT] Release ace version 0.8.0-incubator and related subprojects To: ace-...@incubator.apache.org Time to call the vote on the ace version 0.8.0-incubator and subproject releases. * +1 votes from Jean-Baptiste Onofré*, Toni Menzel*, Angelo van der Sijpt*, Marcel Offermans***, Hadrain Zbarcea**, Carsten Ziegeler***, Clement Escoffier*, and Karl Pauls***. * No other votes The vote is successful. I will approach the Incubator PMC for approval. * == PPMC ** == IPMC *** == PPMC + IPMC -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Boot strapping Android projects @ Apache
+1 regards, Karl On Tue, Nov 9, 2010 at 4:13 PM, Noel J. Bergman n...@devtech.com wrote: About a half dozen or so of us met up at ApacheCon after the lightning talks to talk briefly about Android @ the ASF. The proposal is to create an android-inter...@i.a.o (we also thought about @labs, but the general consenus seemed to be the Incubator due to some of the Labs' restrictions, which we think are good restrictions). We want to encourage others working on Android-related code to share experience and existence with their fellow Committers. For example, did you know that Felix Aries already work with Android? What else does? What else should? Etc. In other words, we want to provide a gathering point for all of the people working in isolation -- to provide a meeting place for those intersted in expanding Android-based activity at the ASF. It is not so much an umbrella as a vital nexus, and breeding ground for importing or creating projects, which would then stand on their own. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Celix for incubation
Felix. Since Apache Felix is an Apache project it makes sense to develop Celix under Apache. Also, Celix is a complex and large middleware project, it makes sense to have a supporting/developing community. Apache provides a solid base, with established processes and rules, to create such community. = Known Risks = == Orphaned Products == Celix will be used by Thales, and so there is no direct risk for this project to be orphaned. == Inexperience with Open Source == The committers have experience using and/or working on open source projects. The Apache process is new, but most likely not a problem. == Homogeneous Developers == Currently all committers are from the Netherlands, but they do work for different organizations. == Reliance on Salaried Developers == All committers working on Celix (currently) are paid developers. The expectation is that those developers will also start working on the project in their spare time. == Relationships with Other Apache Products == * Celix is based on Apache Felix * Using Apache ACE it probably is possible to provision Celix bundles * For remote services Apache CXF can be used (either SOAP or REST) * Possibly Apache ZooKeeper can be used for remote service discovery (Apache ZooKeeper vs SLP) * Possibly Apache Portable Runtime for platform abstraction == An Excessive Fascination with the Apache Brand == Celix itself will hopefully have benefits from Apache, in terms of attracting a community and establishing a solid group of developers, but also the relation with Apache Felix. These are the main reasons for us to send this proposal. We think that a good community is needed to build and maintain large middleware projects, such as Celix. However, even if Celix would not be accepted, development will continue. As such, there is no need to, or reason to, abuse the Apache Brand. = Documentation = Currently all documentation and information is stored on a private corporate wiki.. This has to be moved to a public place. (is this part of the process after acceptance, or should this be placed on (eg) the luminis open source server?) = Initial Source = Development of Celix started in the summer of 2010. The source currently is located on a private corporate SVN repository. All the source is available for Open Sourcing and can be found at http://opensource.luminis.net/wiki/display/SITE/Celix = Source and Intellectual Property Submission Plan = Celix is currently developed solely by Luminis employees. All source will be donated to Apache. = External Dependencies = * MiniZip source , zlib license This source can be included, according to http://www.apache.org/legal/3party.html = Required Resources = == Mailing Lists == * celix-dev * celix-private == Subversion Directory == https://svn.apache.org/repos/asf/incubator/celix == Issue Tracking == JIRA Celix == Other Resources == * CMake Celix uses Cmake as build environment. CMake generates Make files for building, bundling and deploying Celix. This build environment can also be used by project using Celix, it provides simple methods for creating and deploying bundles to a named target. * Confluence Wiki To be able to provide help, documentation, faq etc, a wiki is needed. = Initial Committers = Alexander Broekhuis a.broekh...@gmail.com = Sponsors = == Champion == Marcel Offermans == Nominated Mentors == * Marcel Offermans * Karl Pauls * Luciano Resende (lresende AT apache DOT org) == Sponsoring Entity == Celix is a new project and proposed is to release to code under the sponsorship of the Incubator. == Status == The proposal is now ready for a vote. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Interest in Android-based projects?
Sounds interesting. We did quite some stuff with OSGi on Android (felix does support running on android). What would be the focus (if any)? regards, Karl On Mon, Feb 15, 2010 at 9:56 PM, Noel J. Bergman n...@devtech.com wrote: Would there be interest in a project to develop Android-based apps? know that it sounds like an umbrella, and perhaps it would be until we developed some critical mass, but it would provide us with a place to collaborate. --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache Clerezza into the incubator
a publicly accessible JIRA instance for issues tracking. Clerezza is licensed since project begin under Apache License version 2.0. Some of the initial committers already have strong experiences with Open Source software development. Others, while not being totally inexperience, are willing to learn. The risk that Clerezza will be an orphaned product is considered small. Three main factors will avoid this to happen: * Trialox and its founder Getunik have a vital interest in continuos development in this open source foundation * Clerezza is used as foundation for research as well a student projects at the University of Zurich * There is a strong commitment by Reto Bachmann-Gmür to maintain Clerezza * WWF expressed their support to deploy Clerezza Documentation A small set of further documentation is available under the following links: * http://trialox.org/projects/org.clerezza.rdf.core/documentation/overview.xhtml * http://trialox.org/projects/org.clerezza.triaxrs.parent/org.clerezza.triaxrs/documentation/ Initial Source Clerezza has been in development since mid 2008. Public access to the source is provided through http://scm.trialox.org/. Source and Intellectual Property Submission Plan The current codebase is owned by trialox, and will be donated together with its documentation. We will get the paperwork out of the way as soon as possible. External Dependencies There are quite a few open source libraries already used. They have Apache compatible licenses, with one issue to solve around Jersey which is CDDL. The libraries, their sources and licenses are listed here: Apache Felix, ASL: * Framework * Framework Security * Configuration Admin * maven-scr-plugin * maven-bundle-plugin OSGi Alliance, ASL: * Core * Compendium Apache Maven, ASL: * apache-maven Eclipse, ASL: * Jetty OPS4J, ASL: * Pax Exam * Pax Logging * Pax protocol mvn-uri WYMIWYG, ASL: * wrhapi * wymiwyg-commons jQuery, MIT license: * jquery Hewlett-Packard Development Company, BSD License: * Jena (for the optional jena forntend adaptor, as well as for jena based serializer/parser) * Jena TDB (for the optional tdb backend adaptor) OpenRDF.org, BSD license (for the optional sesame backend adaptor): * Sesame Mulgara.org, Open Software License (OSL) v. 3.0 (for the optional mulgara backend adaptor): * mulgara XSite (http://xsite.codehaus.org/), BSD license: * xsite-maven-plugin Jersey (https://jersey.dev.java.net/), CDDL license The current code bases on code licensed under the CDDL, according to http://apache.org/legal/resolved.html we understand we have to get rid of these before making a release, or redistribute in binary form only. The following files are affected. * QualityFactor.java * HttpDateFormat.java * HttpHeaderReaderImpl.java * UriPattern.java * UriComponent.java * HttpHeaderListAdapter.java * MultivaluedMapImpl.java * HttpHeaderReader.java * ByteArrayProvider.java * SourceProvider.java * AbstractMessageReaderWriterProvider.java * StreamingOutputProvider.java * FormMultivaluedMapProvider.java * FileProvider.java * ReaderProvider.java * InputStreamProvider.java * MediaTypeProvider.java * EntityTagProvider.java * CacheControlProvider.java * NewCookieProvider.java * CookieProvider.java Required Resources Mailing lists: * clerezza-dev * clerezza-commits * clerezza-user (only after leaving the incubator) Subversion: * https://svn.apache.org/repos/asf/incubator/clerezza Issue Tracking: * JIRA: Apache Clerezza (Clerezza) Initial Committers These committers have either worked on the initial codebase (Reto, Immanuel, Tsuy, Hasan) or expressed an interest in extending the project: * Reto Bachmann-Gmür (trialox) * Manuel Innerhofen (trialox) * Tsuyoshi Ito (trialox) * Hasan Hasan (University of Zurich) * Bertrand Delacretaz (ASF member, Day Software) * Michael Marth (Day Software) * Tommaso Teofili (Apache UIMA committer) Affiliations Manuel Innerhofen, Tsuyoshi Ito and Reto Bachmann-Gmür work at trialox and might get paid to work on Clerezza. Hasan Hasan from University of Zurich is paid to work in a project that is based on Clerezza. Michael Marth and Bertrand Delacretaz work for Day Software. Sponsors We have approached both the champion and an initial list of mentors that have agreed to mentor this project. Champion: * Bertrand Delacretaz Mentors: * Gianugo Rabellino * Niclas Hedhman * Ross Gardler * Karl Pauls * Reinhard Pötz Sponsor: * Apache Incubator -- Reto Bachmann-Gmür trialox.org Tel: +41445005015 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org Craig L Russell
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
On Sat, Sep 5, 2009 at 6:35 AM, Niclas Hedhmannic...@hedhman.org wrote: On Sat, Sep 5, 2009 at 4:31 AM, Richard S. Hallhe...@ungoverned.org wrote: On 9/4/09 16:10, Davanum Srinivas wrote: Choices are 1) Podling - TLP 2) Podling - Felix Sub project 3) Podling - Felix Sub project - TLP 4) Felix Sub project 5) Felix Sub project - TLP So, why should we bypass incubator? No, AFAIK, that is not an option when a large bulk of the incoming community is new to ASF. Again, there was already a project incubated to educate incoming folks on how to create open source OSGi spec impls at Apache, so why do we need to repeat that process? Your phrasing of this question implies we are trying to somehow skirt the Apache way, but educating incoming people via contributions and meritocracy to an existing project is not some shortcut. Yes, if you are accepting a large number of people into a TLP on the basis they will create... or they donated..., then that PMC is skirting the Apache way. Where in the above but educating incoming people via contributions and meritocracy to an existing project is not some shortcut do you find anything that would imply that the idea is to just accept a large number of people into a TLP? I think that we at Felix never did just vote in people on the basis they will create Sometimes we do accept people new to the ASF on the basis they donated... but only if we are talking about individual (i.e., 1 or 2) contributors which either have been around for a while or had somebody on the PMC who did speak up for them personally. My stance has been that if a code donation include 1 or 2 new people, then that can be handled that way, but 9 people on that basis will/should probably not fly. Considering the large number of ASF members and committers on the rooster, this is perhaps a border case, but since it is said that not much code exist, then I also suspect that the rooster is 'rigged' with people in the organization that has a general interest and strong ASF affilliation and that the non-ASFers are those who are expected to do most of the work. That still wouldn't prevent them from contributing to other projects as you are probably well aware. Hence, the group's decision to come to Incubator is a correct one. And nobody has been questioning that as far as I can see. The question is about the scope and goals of Aries and more specifically about the part where it is about being an umbrella for OSGi EE spec implementations where it has been argued that this could/should be done at felix while the more general part of building an enterprise component model on top of OSGi could/should very well be a new incubator project. This is different from saying that the group's decision to come to Incubator is an incorrect one... Where it graduates to is a different story, and I can leave that question for later. And the Felix community is encouraged to follow and participate the Aries effort. As I'm sure at least some if not all of us will. The has never been a question either imo. The question in this regard was and is purely to what extend Felix people interested in the OSGi EE spec implementations only have to get involved in the (more general) Aries project and how quickly OSGi EE spec implementations can be released as none incubator artifacts. And one more time (just in case it was missed earlier): let me point out that nobody is talking about Aries as a Felix incubator project nor (at least at this point in time) about a possible subproject of Felix after graduation. We are only talking about the OSGi EE spec implementations that are part of the proposed Aries scope. regards, Karl I think this discussion is more or less over. Unless it was missed earlier; My +1 for incubation. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
On Sat, Sep 5, 2009 at 12:21 PM, Davanum Srinivasdava...@gmail.com wrote: Karl, There are *many* TLP(s) with overlapping scope as James Strachan pointed out earlier in the thread. I don't see the need to shoe horn a new community with new code into an existing TLP just because of scope. For all you know by the time they get out of the incubator their scope may change a bit (or more). I'm sorry if it looked like I wanted to shoe horn anything into felix. That wasn't my goal as for me it was a question of where I would like it to happen and as I said earlier already, not the end of the world if not. regards, Karl thanks, dims On 09/05/2009 04:31 AM, Karl Pauls wrote: The question is about the scope and goals of Aries and more specifically about the part where it is about being an umbrella for OSGi EE spec implementations where it has been argued that this could/should be done at felix - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
convention of just let us know before making changes in there and make sure you're following our dev list. I know such issues can be discussed during incubation, not necessarily before the podling is accepted, but the fact that (AFAIK) no contact was made with the Felix project before creating the Aries proposal is very disturbing - so IMHO we should rather clarify this before accepting the podling. Maybe simply saying modules that implement OSGi specs, or that are of general interest to OSGi users, will be moved to the Felix project, as much as possible in the Aries proposal would help. That should be true for any project doing OSGi at Apache anyway, and I think the other projects mentioned above are working like that, which is a Good Thing, I'm very happy to see Guillaume as a mentor for Aries, that will hopefully help in building bridges between Felix and Aries. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
implementations in the first. The only conclusions I see being drawn by people who have invested very little in Felix is that we should dismantle the Felix charter so that we can accommodate the fact that some people don't want to play with us. At that rate, I stand by my previous vote and otherwise people can do whatever they want in Aries. - richard On 9/3/09 13:23, Niclas Hedhman wrote: Kevan, Was a contact with Felix made prior to dropping the proposal here? I got the impression that wasn't the case, which I find surprising... If I am wrong, what was the meat of such? I'm also less happy with the rhetoric here repeated over and over, seemingly uninterested in discussion of reaching a solution everyone can accept. (From both camps, btw) -- Niclas On Sep 4, 2009 12:53 AM, Kevan Millerkevan.mil...@gmail.com wrote: On Sep 3, 2009, at 12:53 AM, Niclas Hedhman wrote: On Thu, Sep 3, 2009 at 3:19 AM, William A. Ro... Totally agree. Had certainly hoped that Felix committers would be interested in joining... --kevan - To unsubscribe, e-mail: gene... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - 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 -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
On Fri, Sep 4, 2009 at 10:31 PM, Richard S. Hallhe...@ungoverned.org wrote: On 9/4/09 16:10, Davanum Srinivas wrote: Richard, On 09/04/2009 03:49 PM, Richard S. Hall wrote: So, no, I am not saying everything should, but in general, it would be nice if the spec impls started there since we have a community of OSGi users and OSGi experts who are very active and receptive, many of whom also work in the EE space. Will the people mentioned not participate if Aries is a separate podling to start with? After all destination PMC can be determined during graduation process. Also the incubation process is to show new incoming team how Apache works etc..is that better done as a podling or as a felix sub project? If we continue the same thought process, will there every be any incubator podling with for any OSGi related activity? Yes, and I mentioned this, but that seems to get lost somehow. And as others have mentioned too there are already a couple like e.g., Sling (started in the incubator now a TLP) and Ace (recently accepted to the incubator). regards, Karl In short, it makes sense for spec impls tied to the Aries component model (for example), to be hosted there, but there is little need to create another project to incubate generic OSGi spec impls, since the Felix community was set up for that. The reality is, most OSGi specs are not huge projects so we likely wouldn't want TLPs for all of them, but nothing stops a subproject started at Felix from going TLP if it takes on a life of its own. Choices are 1) Podling - TLP 2) Podling - Felix Sub project 3) Podling - Felix Sub project - TLP 4) Felix Sub project 5) Felix Sub project - TLP The first 3 effectively uses incubator process(es) to educate the incoming folks and provides a strong grounding in ASF-land (at least that is what the intention is :) So, why should we bypass incubator? Again, there was already a project incubated to educate incoming folks on how to create open source OSGi spec impls at Apache, so why do we need to repeat that process? Your phrasing of this question implies we are trying to somehow skirt the Apache way, but educating incoming people via contributions and meritocracy to an existing project is not some shortcut. - richard thanks, dims - 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 -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
accepted as Felix committers and PMC members for the Karaf subproject) * +1 for the rest of the proposal to explore how to build an enterprise component model on OSGi and the other non-spec related topics. - richard On 9/1/09 22:53, Kevan Miller wrote: On Sep 1, 2009, at 2:08 PM, Richard S. Hall wrote: On 9/1/09 13:59, Martin Cooper wrote: On Tue, Sep 1, 2009 at 10:51 AM, Richard S. Hallhe...@ungoverned.org wrote: I'm not sure I understand the issue here. Whether Aries becomes its own TLP, or a sub-project of Felix or some other TLP, isn't relevant until the project is ready to exit incubation. Why does it warrant such apparently intense discussion before the project is even accepted We are actually discussing something else. We are discussing the scope of the proposal, which includes hosting OSGi standard service implementations, which is part of Felix' scope. If we are developing standard OSGi services within Apache, then Felix provides an enthusiastic community to do this and there is no need to start another incubator project for such a purpose. On the other hand, stuff like a set of pluggable Java components enabling an enterprise OSGi application programming model makes perfect sense to be incubated. Thanks for the clarification... So, your issue is mainly with It is a goal of the Aries project to provide a natural home for open source implementations of current and future OSGi EEG specifications...? Personally, I tend to think of Felix in terms of OSGi Core Platform. I certainly hadn't expected it to be the source for all OSGi standard implementations from Apache -- not for implementations of Enterprise Expert Group specs, anyway. I'm sure there are flaws with my perceptions... So, we have a group that is interested in working on an enterprise OSGi application programming model at Apache (including implementations of at least some EEG specifications). An incubator project would seem to be an excellent place for this work to start. Interested Felix community members would certainly be able to join this effort. It then becomes a question of, assuming successful incubation, where does the community graduate to? TLP, Felix subproject(s), or elsewhere. All successful outcomes, IMO. --kevan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE][RESULT] Accept Apache Ace into the Incubator
Time to call the vote on accepting Apache Ace for incubation. * +1 votes from (* indicates binding votes) Carsten Ziegeler*, Niclas Hedhman*, Richard S. Hall, Niall Pemberton*, Robert Burrell Donkin*, Bertrand Delacretaz*, Felix Meschberger, Francesco Furfari, and Karl Pauls. * No other votes. The vote is successful. Thanks to everyone involved. We will get the ball rolling asap. Please vote on accepting Apache Ace for incubation at the Apache Incubator. The full proposal is available at the end of this message and as a wiki page at http://wiki.apache.org/incubator/AceProposal. We ask the Incubator PMC to sponsor it, with Karl as the Champion, and Carsten, Niclas and Bertrand volunteering to be mentors. Please cast your votes: [ ] +1, bring Ace into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring Ace into Incubator, because... The vote is open for the next 72 hours and only votes from the Incubator PMC are binding. - - - - - - - - - - Abstract Apache Ace is a software distribution framework based on OSGi that allows you to manage and distribute artifacts, like e.g. software components. Proposal Apache Ace is a software distribution framework that allows you to centrally manage and distribute software components, configuration data and other artifacts to target systems. It is built using OSGi and can be deployed in different topologies. The target systems are usually also OSGi based, but don't have to be. Background When assembling software out of reusable components, the task of deploying software onto an ever increasing number of targets is not trivial to solve. This becomes even harder when these targets require different components based on who's using them. A key technology in the Java space for developing component based applications is OSGi. The OSGi speciï¬ cation, which has been around since 1999 and by now has matured into the de facto module system for Java, allows you to write components that can interact through services and that allows components to be updated individually, without disturbing the rest of the components. Although the OSGi speciï¬ cation describes how software distribution should be done, it does not actually prescribe any protocols or implementations. Apache Ace implements a software distribution system based on, but not limited to OSGi. It is setup so it can deal with different target types, using different protocols. Also, it can handle an extensible number of artifact types (bundles, configurations, resources, ...). Rationale When you start using OSGi to build reusable components, the task of managing those components and their use in various applications becomes non-trivial. Apache Ace allows you to group those components and assign them to a managed set of targets. This allows you to distribute updates and new components easily, while keeping a full history of what was installed where during what period. It also helps you setup an automated development, QA/testing, staging and production environment. Initial Goals The initial goals for Apache Ace are: * Donate the existing codebase and import it. * Setup the incubation infrastructure (svn repository, build system, website) so we can run continuous builds with automated tests and publish all available documentation. * Get people involved in advancing the code base in different directions, integrating it with other projects at Apache. * Prepare for an initial release that demonstrates the systems core capabilities. * Present the project to the community at ApacheCon 2009 US. Current Status The current codebase is developed and tested in various configurations. It was developed at luminis over the last couple of years using Scrum, so we have internally demonstrated we can release often and produce working code using a transparent process. Documentation for the project is now available on an internal wiki, which can be donated and converted to the Apache Ace website. We did not yet use mailing lists as the primary colaborative process, as the whole team met face to face on a daily basis. Meritocracy Some of the core developers are already committers and PMC members at Apache, so they understand what it means to have a process based on meritocracy. Community In the past, luminis has been talking to various interested users and developers about Apache Ace, and we believe there is an interest in this project. Feedback at ApacheCon EU 2009 and afterwards on the Apache Felix mailing list confirmed that. The problem that is being solved is one that many software developers run into, so it should appeal to them. Our list of initial committers already includes people from different backgrounds. Core Developers The core development team is a mix of people that work for luminis and have been involved in the project up til now and new committers, some of which have previous experience at Apache. Alignment The initial codebase makes use of Apache Felix as its core framework
Re: [VOTE] Accept Apache Ace into the Incubator
+1 regards, Karl On Mon, Apr 20, 2009 at 10:56 AM, francesco.furf...@isti.cnr.it wrote: +1 (non binding vote) francesco On 4/19/2009, Karl Pauls karlpa...@gmail.com wrote: Please vote on accepting Apache Ace for incubation at the Apache Incubator. The full proposal is available at the end of this message and as a wiki page at http://wiki.apache.org/incubator/AceProposal. We ask the Incubator PMC to sponsor it, with Karl as the Champion, and Carsten, Niclas and Bertrand volunteering to be mentors. Please cast your votes: [ ] +1, bring Ace into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring Ace into Incubator, because... The vote is open for the next 72 hours and only votes from the Incubator PMC are binding. - - - - - - - - - - Abstract Apache Ace is a software distribution framework based on OSGi that allows you to manage and distribute artifacts, like e.g. software components. Proposal Apache Ace is a software distribution framework that allows you to centrally manage and distribute software components, configuration data and other artifacts to target systems. It is built using OSGi and can be deployed in different topologies. The target systems are usually also OSGi based, but don't have to be. Background When assembling software out of reusable components, the task of deploying software onto an ever increasing number of targets is not trivial to solve. This becomes even harder when these targets require different components based on who's using them. A key technology in the Java space for developing component based applications is OSGi. The OSGi speciï¬ cation, which has been around since 1999 and by now has matured into the de facto module system for Java, allows you to write components that can interact through services and that allows components to be updated individually, without disturbing the rest of the components. Although the OSGi speciï¬ cation describes how software distribution should be done, it does not actually prescribe any protocols or implementations. Apache Ace implements a software distribution system based on, but not limited to OSGi. It is setup so it can deal with different target types, using different protocols. Also, it can handle an extensible number of artifact types (bundles, configurations, resources, ...). Rationale When you start using OSGi to build reusable components, the task of managing those components and their use in various applications becomes non-trivial. Apache Ace allows you to group those components and assign them to a managed set of targets. This allows you to distribute updates and new components easily, while keeping a full history of what was installed where during what period. It also helps you setup an automated development, QA/testing, staging and production environment. Initial Goals The initial goals for Apache Ace are: * Donate the existing codebase and import it. * Setup the incubation infrastructure (svn repository, build system, website) so we can run continuous builds with automated tests and publish all available documentation. * Get people involved in advancing the code base in different directions, integrating it with other projects at Apache. * Prepare for an initial release that demonstrates the systems core capabilities. * Present the project to the community at ApacheCon 2009 US. Current Status The current codebase is developed and tested in various configurations. It was developed at luminis over the last couple of years using Scrum, so we have internally demonstrated we can release often and produce working code using a transparent process. Documentation for the project is now available on an internal wiki, which can be donated and converted to the Apache Ace website. We did not yet use mailing lists as the primary colaborative process, as the whole team met face to face on a daily basis. Meritocracy Some of the core developers are already committers and PMC members at Apache, so they understand what it means to have a process based on meritocracy. Community In the past, luminis has been talking to various interested users and developers about Apache Ace, and we believe there is an interest in this project. Feedback at ApacheCon EU 2009 and afterwards on the Apache Felix mailing list confirmed that. The problem that is being solved is one that many software developers run into, so it should appeal to them. Our list of initial committers already includes people from different backgrounds. Core Developers The core development team is a mix of people that work for luminis and have been involved in the project up til now and new committers, some of which have previous experience at Apache. Alignment The initial codebase makes use of Apache Felix as its core framework. It also uses various other components of that project. As a project that builds on components we are constantly looking out for existing components that can accelerate our implementation and we want
[VOTE] Accept Apache Ace into the Incubator
informally a couple of projects at Apache have already expressed interest in a system that can help them do software provisioning. Known Risks Apache Ace uses Felix as its default OSGi implementation and some of its developers are also part of the Felix community. We are open to collaborate with other Apache projects, looking at candidates such as Commons, Sling, JackRabbit that could help us in certain parts of our infrastructure. An important reason for open sourcing this project at Apache is the strong community, as well as the Apache license. This will attract more users and developers so the project can be moved forward into new directions that we would otherwise not have been possible. Judging from the initial interest from some of the other projects at Apache, we certainly see ways in which to collaborate and advance the project, possibly in ways we would never have thought of. However, we have been able to support and develop this product outside of Apache quite well, so in no way are we trying to just dump the code there or merely trying to generate publicity. Initial Source Apache Ace has been in development within luminis since 2005. Source and Intellectual Property Submission Plan The current codebase is owned by luminis, and will be donated together with its documentation. We will get the paperwork out of the way as soon as possible. There should already be a CCLA on file for luminis and the people that are already involved with Apache obviously have ICLAs on file. External Dependencies There are quite a few open source libraries already used. The libraries, their sources and licenses are listed here: Apache Felix, ASL: * framework * shell * shell-tui * obr * http.jetty * config admin * event admin * deployment admin * dependency manager * prefs * upnp.basedriver * org.osgi.foundation * core * compendium * javax.servlet Apache Ant, ASL: * ant.jar * ant-contrib.jar Apache Velocity, ASL: * velocity KXML2 ( http://kxml.sourceforge.net/kxml2/), BSD license: * kxml2 (hmm, what was that issue we had with that in felix) Knopflerfish ( http://knopflerfish.org/), BSD style license: * log_all.jar, useradmin_all.jar Luminis Open Source Server ( https://opensource.luminis.net/), BSD license: * net.luminis.build.plugin.jar XStream ( http://xstream.codehaus.org/), BSD license: * various xstream jars Required Resources Mailing lists: * ace-private * ace-dev * ace-commits * ace-user (only after leaving the incubator) Subversion: * https://svn.apache.org/repos/asf/incubator/ace Issue Tracking: * JIRA: Apache Ace (ACE) Wiki: * Confluence: Apache Ace (ACE) Initial Committers These existing Apache committers have either worked on the initial codebase (Christian, Karl and Marcel) or expressed an interest in extending the project: * Marcel Offermans * Karl Pauls * Christian van Spaandonk * Clement Escoffier * Felix Meschberger * Carsten Ziegeler Community Members The following people have already expressed their interest in actively participating in this project: * Bram de Kruijff * Toni Menzel * Alin Dreghiciu * Dennis Geurts Affiliations For the record, Marcel Offermans, Christian van Spaandonk and Dennis Geurts work at luminis and might get paid to do certain work on Apache Ace. Sponsors We have approached both the champion and an initial list of mentors that have agreed to mentor this project. Champion: * Karl Pauls Mentors: * Carsten Ziegeler * Niclas Hedhman * Bertrand Delacretaz Sponsor: * Apache Incubator - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Ace
always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Karl Pauls karlpa...@gmail.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Ace
I'm not sure I understand what your problem with this proposal is exactly but I sure would like to. Let me try to get some things clear in order to be able to get to the bottom of this. Don't let any previous comments side-track you and lets try to focus on the proposal: I don't see where the proposal is mentioning OBR in the first place. Let alone where it would say anything about it being a standard or anything. Its only listed as an external dependency. There is no pointer to OBR (other then that it is a dependency) nor is there a pointer to p2. That is not suspicious as the project is not about any of the two other then it should be able to use obr and p2 repositories and infrastructure where it makes sense. I completely agree that it would be great if there would be an active and healthy collaboration between the projects but I'm not sure this has to be in the proposal. It certainly doesn't say anything to the opposite (unless I'm missing something?). Finally, the proposal already does say: When assembling software out of reusable components, the task of deploying software onto an ever increasing number of targets is not trivial to solve. This becomes even harder when these targets require different components based on who's using them. What else do you think is necessary to make it clear that provisioning is a hard problem as you say? From this point, would you say that what you like to see is a paragraph that mentions that the current luminis implementation uses OBR and that the project will look into using p2 as well? I'm sure that this can be arranged. regards, Karl I'm suggesting that you two groups figure out how to work together on a very hard problem. I'm also saying that you are unlikely to out do the 5 man years in p2 already. As I said in the previous email if you want to make a competing system that's fine. But don't couch the proposal as something that's new and hasn't been addressed elsewhere because it has. You might want to be more clear in the proposal about p2 being a competitor, also make it clear that OBR has gone back to specification, and what it is you're actually working from. So when a user or potential developer looks at this and says what specification are you working from they can see there isn't one yet, and if they ask what about p2?, then it's clear you decided not to collaborate with them. I think you can even point out that they didn't collaborate with you either. Give people all the information. When I walked into the OSGi BOF at Eclipse I was dumbfounded. The same dose of sniping and grin fucking as other groups I've worked with which was disappointing but I guess I'm not surprised. There were attacks abound at EclipseCon. The way p2 came into existence probably could have been handled better, no doubt. But I don't find guys like Hal very compelling with his melodrama (http://www.tensegrity.hellblazer.com/2009/03/osgi-rfp-122---the-osgi-bundle-repository.html). Make it clear to people looking at the proposal that provisioning is a hard problem. These arguments about the Eclipse way of p2 and non-focus on server side or other types of systems is nonsense. If you actually have a pointer to p2 in your proposal -- which is conspicuously absent -- siting them as a direct competitor users will have a clear point of reference. If people had the background story they will probably go WTF just like I did. Both sides of the p2/OBR seem to be equally obstinate and non-collaborative. I used p2 because from a technical level as an end user because it worked. There are nightly builds, lots of documentation and at least 5 people working on it full-time at any given point in time. If you look at the p2 code and the OBR spec they are 90% the same thing and any differences are easily compensated for with a little effort. Competition is fine, I would just be more open about that aspect of it in the proposal. On 5-Apr-09, at 8:47 AM, Karl Pauls wrote: On Sun, Apr 5, 2009 at 5:00 PM, Jason van Zyl jvan...@sonatype.com wrote: On 5-Apr-09, at 2:46 AM, Marcel Offermans wrote: Hello Jason, On Apr 5, 2009, at 1:09 , Jason van Zyl wrote: Equinox p2 was designed to replace the aging Update Manager in Eclipse. It focusses on installing Eclipse-based applications from scratch and updating them and can be extended to manage other types of artifacts. If you look at the agent part, it is geared towards desktop environments Not true. Jeff McAffer's demo at EclipseCon is a case in point. He provisioned an EC2 node using p2. [...] Jeff is very much focused on server side provisioning as am I. Let me rephrase that, it's geared more towards desktop and server environments, as compared to smaller (embedded, mobile) environments. That was the point I was trying to make here. Note though, I'm no Equinox p2 expert. :) Then why are you proposing this when you don't even know what p2 is capable of? We started working
Re: [DISCUSS] Re-election of podling committers before graduation
...Craig has a good point - maybe that 'pruning' process, to the extent it's appropriate, should happen before they start the actual graduation process? The question is how, and it's something no established project has ever figured out, nevermind our podlings :)... Hence the suggestion that some of us discussed in December: re-electing podling committers is a no-brainer for active people, and gives others a chance to step out. Not trying to take a side, what we did in Felix was to just ask everybody on our list if he would like to step out. Not all people which I would have expected to do so did at this point but some did. The reason I point this out is that quite a few of the more inactive people that stayed on board are by now very active while others are not as active anymore as they used to be during incubation... regards, Karl -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Karl Pauls [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] Re: [VOTE] Apache Felix 0.8.0 Incubator Release
This vote has been open for more than 72 hours, so we would like to call the vote on Felix-0.8.0-incubator so that we can move forward: * +1 votes from Robert Burrell Donkin, Upayavira, Enrique Rodriguez, Alex Karasulu * No 0 votes. * No -1 votes. With three +1 from IPMC members the vote is successful. We will make an official announcement and make the release available publicly. Thanks to the people who reviewed and/or voted. regards, Karl -- Karl Pauls [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: [VOTE] Apache Felix 0.8.0 Incubator Release
The asc and KEYS files are available on the page now. Please start reviewing our release again. The URL stays the same: http://people.apache.org/~rickhall/felix-0.8.0-incubator.html +1 -- minor (fix in HEAD) -- a number of package.html's are IMHO creative enough to be copyrightable. i think that they should have copyright headers. Well, the point is that this package.html's are from the OSGi alliance (licensed under ASL). We redistribute them but try not to modify them. We've been discussing adding a copyright but decided against it on the grounds of them being provided like this. - notes and comments (not requirements) - the public key does not seems to be available from the major keysigning networks (see http://www.apache.org/dev/release-signing.html if you haven't uploaded it yet) I'm going to upload the key. Thanks. good practice to produce both tar.gz and zip compressed artifacts. yes, i know that most major platforms can easily open either format but users associated tar.gz with *nix and zip with m$. producing both formats is good psychology. Right, we will look into it. release notes are an important form of guerilla advertising. the same content can be used in several different places: on the download page, on announcements, on grassroots media (eg freshmeat) and as plain text in the release. consider adding some next time. - robert We will. Due to this being our first release it wouldn't contain much this time around anyhow, but I agree, release notes are important. Thanks for pointing it out and for reviewing. regards, Karl -- Karl Pauls [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [VOTE] Apache Felix 0.8.0 Incubator Release
Not quite there yet. The incubator DISCLAIMER file is still missing from the jars. That would prevent them going into maven repositories. Is that just a recommendation or a requirement? Our NOTICE files contain the incubator disclaimer text. it's a requirement that the text is present but AIUI in the NOTICE is ok (though perhaps a separate DISCLAIMER is clear) We have a separate DISCLAIMER on top-level. The binaries (i.e., jar files) contain a NOTICE that includes the DISCLAIMER. I agree that a separate DISCLAIMER is more clear but I think for this release we'll go with the current set-up. please let me know whether you plan to cut another candidate or whether i should review the one above Yes, please review the one above. signing the releases is a requirement. having a well connected code signing key is definitely good but not mandatory - robert We will make the asc and KEYS files available on the page mentioned above asap (i.e., a couple of hours). regards, Karl -- Karl Pauls [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: [VOTE] Apache Felix 0.8.0 Incubator Release
The asc and KEYS files are available on the page now. Please start reviewing our release again. The URL stays the same: http://people.apache.org/~rickhall/felix-0.8.0-incubator.html regards, Karl On 12/12/06, Karl Pauls [EMAIL PROTECTED] wrote: Not quite there yet. The incubator DISCLAIMER file is still missing from the jars. That would prevent them going into maven repositories. Is that just a recommendation or a requirement? Our NOTICE files contain the incubator disclaimer text. it's a requirement that the text is present but AIUI in the NOTICE is ok (though perhaps a separate DISCLAIMER is clear) We have a separate DISCLAIMER on top-level. The binaries (i.e., jar files) contain a NOTICE that includes the DISCLAIMER. I agree that a separate DISCLAIMER is more clear but I think for this release we'll go with the current set-up. please let me know whether you plan to cut another candidate or whether i should review the one above Yes, please review the one above. signing the releases is a requirement. having a well connected code signing key is definitely good but not mandatory - robert We will make the asc and KEYS files available on the page mentioned above asap (i.e., a couple of hours). regards, Karl -- Karl Pauls [EMAIL PROTECTED] -- Karl Pauls [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
