Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator
It would be nice if everybody would started wearing their Apache hats and act as individuals that are interested in joining an exciting new project in the incubator. I would prefer it if everybody would assume good intentions here. We're all collaborating out in the open as a community, so let's all act in good faith until proven otherwise. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[IP CLEARANCE] [VOTE] Apache Celix shared memory remote service admin implementation
Apache Celix received the donation of a shared memory implementation of the remote service admin specification. The donation is tracked by CELIX-29 [1]. The IP clearance document is placed under: https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/celix-shared-memory-rsa.xml Please vote to approve this contribution. Lazy consensus applies. If no -1 votes are cast within the next 72 hours, the vote passes. Greetings, Marcel [1] https://issues.apache.org/jira/browse/CELIX-29
Re: [IP CLEARANCE] [VOTE] Apache Celix shared memory remote service admin implementation
Hello Dave, Thanks for spotting that one. My mistake, I completely overlooked that field. I will correct it and, after also resolving the issue Craig brought up, start a new vote. Greetings, Marcel On 18 Dec 2013, at 17:24 , Dave Brondsema wrote: > On 12/18/13 3:47 AM, Marcel Offermans wrote: >> Apache Celix received the donation of a shared memory implementation of the >> remote service admin specification. The donation is tracked by CELIX-29 [1]. >> >> The IP clearance document is placed under: >> https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/celix-shared-memory-rsa.xml >> >> Please vote to approve this contribution. Lazy consensus applies. If no -1 >> votes are cast within the next 72 hours, the vote passes. >> >> Greetings, Marcel >> >> >> [1] https://issues.apache.org/jira/browse/CELIX-29 >> >> > > > I'm no expert in the IP clearance form, but the "Corporations and individuals > holding existing distribution rights:" section seems like it needs to have > some > names entered. It looks like "For individuals, use the name as recorded > on > the committers page" is just a placeholder that should be updated. > > > -- > Dave Brondsema : d...@brondsema.net > http://www.brondsema.net : personal > http://www.splike.com : programming > <>< > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IP CLEARANCE] [VOTE] Apache Celix shared memory remote service admin implementation
Hello Craig, The reference to CELIX-29 is a mistake, CELIX-81 is the right issue. However, if I look at the SVN file containing a list of the grants, I do see the one related to this donation: Thales Nederland B.V. file: thales-nederland-celix-remote-services-admin-bundle.pdf for: A remote services admin bundle and a discovery bundle which uses shared memory for information interchange. See: CELIX-81 Anyway, to avoid further confusion, I will cancel this vote, correct my mistakes and start a new one with all this updated information. Thanks for the feedback, and sorry for my mistakes. Greetings, Marcel On 18 Dec 2013, at 17:08 , Craig L Russell wrote: > Is there a software grant for this donation? I didn't see any reference from > any of the below links (nor in CELIX-81 either). > > Craig > > On Dec 18, 2013, at 12:47 AM, Marcel Offermans wrote: > >> Apache Celix received the donation of a shared memory implementation of the >> remote service admin specification. The donation is tracked by CELIX-29 [1]. >> >> The IP clearance document is placed under: >> https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/celix-shared-memory-rsa.xml >> >> Please vote to approve this contribution. Lazy consensus applies. If no -1 >> votes are cast within the next 72 hours, the vote passes. >> >> Greetings, Marcel >> >> >> [1] https://issues.apache.org/jira/browse/CELIX-29 >> > > Craig L Russell > Secretary, Apache Software Foundation > c...@apache.org http://db.apache.org/jdo > > > > > > > > > > > > - > 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
[CANCELED] [IP CLEARANCE] [VOTE] Apache Celix shared memory remote service admin implementation
Given the issues raised by Craig and Dave, I am cancelling this vote. I will fix the mistakes and start a new vote. Greetings, Marcel On 18 Dec 2013, at 9:47 , Marcel Offermans wrote: > Apache Celix received the donation of a shared memory implementation of the > remote service admin specification. The donation is tracked by CELIX-29 [1]. > > The IP clearance document is placed under: > https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/celix-shared-memory-rsa.xml > > Please vote to approve this contribution. Lazy consensus applies. If no -1 > votes are cast within the next 72 hours, the vote passes. > > Greetings, Marcel > > > [1] https://issues.apache.org/jira/browse/CELIX-29 > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[IP CLEARANCE] [VOTE] Apache Celix shared memory Remote Service Admin implementation (2nd attempt)
Note that this is a new vote, after cancelling the previous one. Apache Celix received the donation of a shared memory implementation of the remote service admin specification. The donation is tracked by CELIX-81 [1]. The (updated) IP clearance document is placed under: https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/celix-shared-memory-rsa.xml The software grant can be found in the appropriate document in svn (I’ve included a few relevant lines to make it easier to locate it): Thales Nederland B.V. file: thales-nederland-celix-remote-services-admin-bundle.pdf for: A remote services admin bundle and a discovery bundle which uses shared memory for information interchange. See: CELIX-81 Please vote to approve this contribution. Lazy consensus applies. If no -1 votes are cast within the next 72 hours, the vote passes. Greetings, Marcel [1] https://issues.apache.org/jira/browse/CELIX-81
Re: [IP CLEARANCE] [VOTE] Apache Celix shared memory Remote Service Admin implementation (2nd attempt)
Hello Craig, As suggested, I updated the document to contain the location of the grant. Greetings, Marcel On 19 Dec 2013, at 17:29 pm, Craig L Russell wrote: > Hi Marcel, > > The ip looks good, but the ip clearance document is our historical record and > needs to be updated. No need to re-run the vote if the document is corrected. > > On Dec 18, 2013, at 2:28 PM, Marcel Offermans wrote: > >> Note that this is a new vote, after cancelling the previous one. >> >> Apache Celix received the donation of a shared memory implementation of the >> remote service admin specification. The donation is tracked by CELIX-81 [1]. >> >> The (updated) IP clearance document is placed under: >> https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/celix-shared-memory-rsa.xml > > The ip clearance document should provide "one stop shopping" to verify the > provenance of the ip and the grant. > > Can you please update the above document to include the location of the grant > from Thales Nederland B.V.? > https://svn.apache.org/repos/private/documents/grants/thales-nederland-celix-remote-services-admin-bundle.pdf > > Thanks, > > Craig > >> >> The software grant can be found in the appropriate document in svn (I’ve >> included a few relevant lines to make it easier to locate it): >> >> Thales Nederland B.V. >> file: thales-nederland-celix-remote-services-admin-bundle.pdf >> for: A remote services admin bundle and a discovery bundle which uses >> shared memory for information interchange. See: CELIX-81 >> >> Please vote to approve this contribution. Lazy consensus applies. If no -1 >> votes are cast within the next 72 hours, the vote passes. >> >> Greetings, Marcel >> >> >> [1] https://issues.apache.org/jira/browse/CELIX-81 >> > > Craig L Russell > Secretary, Apache Software Foundation > c...@apache.org http://db.apache.org/jdo > > > > > > > > > > > > - > 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
[RESULT] [IP CLEARANCE] [VOTE] Apache Celix shared memory Remote Service Admin implementation (2nd attempt)
Formally closing this vote now. There were no -1 votes, so the vote is a success and the IP can now be imported by the project. On 18 Dec 2013, at 23:28 , Marcel Offermans wrote: > Note that this is a new vote, after cancelling the previous one. > > Apache Celix received the donation of a shared memory implementation of the > remote service admin specification. The donation is tracked by CELIX-81 [1]. > > The (updated) IP clearance document is placed under: > https://svn.apache.org/repos/asf/incubator/public/trunk/content/ip-clearance/celix-shared-memory-rsa.xml > > The software grant can be found in the appropriate document in svn (I’ve > included a few relevant lines to make it easier to locate it): > > Thales Nederland B.V. >file: thales-nederland-celix-remote-services-admin-bundle.pdf >for: A remote services admin bundle and a discovery bundle which uses > shared memory for information interchange. See: CELIX-81 > > Please vote to approve this contribution. Lazy consensus applies. If no -1 > votes are cast within the next 72 hours, the vote passes. > > Greetings, Marcel > > > [1] https://issues.apache.org/jira/browse/CELIX-81 > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: ApacheCon Denver CFP
We have had many great talks about podlings in the past, so I see no reason why not. I would definitely encourage them to get the word out! Greetings, Marcel On 25 Jan 2014, at 17:36 pm, Alan Cabrera wrote: > There was a question on a podling as to whether developers on podlings could > submit proposals about their project. Can they or can’t they? > > > Regards, > Alan > > > On Jan 24, 2014, at 1:38 PM, Marvin Humphrey wrote: > >> Hi everyone, >> >>> ApacheCon Denver will take place April 7-9, 2014. The call-for-proposals >>> went out on Tuesday: >>> >>> http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp >> >> The CFP closes on February 1 -- one week from tomorrow -- so get those >> proposals in! >> >> Marvin Humphrey >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Celix version 1.0.0.incubating
I agree with sebb and David that it's a good idea to remove links to SVN from the download page and I propose that the Celix community changes this on their website. At the same time I think this should be a separate discussion, as this thread is about voting about the Celix release itself. Alexander has addressed some of the issues raised here, so I would like to ask everybody to focus on that. The Celix community has been working hard over the years to show that they get the Apache way, and you would really help them by reviewing and voting on the release. Greetings, Marcel On 16 Feb 2014, at 17:30 pm, David Nalley wrote: >>> There is a further issue with the download page. >>> It currently contains links for SVN. I think those don't belong on a >>> public download page. >>> SVN links should be restricted to pages intended for developers, not >>> the general public. >>> >> >> Is this common Apache policy? There are more projects who do this. Besides >> the website states that the SVN version is a development version, and >> explicitly mentions releases. >> > > What matters is how its advertised. By putting a link to SVN on a > 'Downloads' page (and both above the fold and above the releases that > have been voted on) you seem to be encouraging normal users to consume > from SVN. Your releases (that have been voted on and approved by the > IPMC) are what you should be pointing the public to. > > To quote http://apache.org/dev/release.html#what > > "In our case, that means any publication outside the group of people > on the product dev list. If the general public is being instructed to > download a package, then that package has been released." > > The entire release page is a good read and instructive. > > --David > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Brooklyn
Hello Chip, On 23 Apr 2014, at 16:28 , Chip Childers wrote: > This is the discussion thread for this proposal. We would also like to > solicit contributions from additional IPMC members willing to mentor the > potential podling. Anyone interested? Yes, I am interested in signing up as a mentor. I think this is a very interesting project as well, and I would be interested in exploring how Brooklyn could be used to deploy modular OSGi applications (using Apache ACE as a provisioning server and Felix as a container). Greetings, Marcel
Re: [VOTE] Accept Brooklyn into the Incubator
+1 Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Graduate Apache Celix as TLP
+1 from me on that as well (as one of the other mentors of the project). As I said already when this was discussed within the Celix community, I think that, although small, the community is slowly growing, they have demonstrated that they know how to do releases, discuss things on the mailing list, etc. So I agree it it time for a general vote. Greetings, Marcel On 13 Jun 2014, at 0:31 am, Roman Shaposhnik wrote: > I've been around Celix for some time. It is small but a very > robust community that is also slowly growing. > > Personally, I'd say its time to put this proposal for > a general@ vote. > > Thanks, > Roman. > > On Thu, Jun 12, 2014 at 1:02 AM, Alexander Broekhuis > wrote: >> Hello incubator folks, >> >> Can someone please take a look at this proposal? >> >> >> 2014-06-10 7:06 GMT+02:00 Alexander Broekhuis : >> >>> Hi All, >>> >>> Since entering Incubation in November 2010, the Celix podling been working >>> towards graduation. The community has grown, releases have been made and >>> new committers have been added. >>> Over the last couple of months all items on the checklist for graduation >>> have been ticked of [1]. >>> This resulted in a, positive, vote on te dev list of Celix itself [2]. >>> Also the namesearch has been performed [3]. >>> As far as we can tell the project status is up to date [4], and Celix is >>> ready for graduation. >>> >>> This thread is to start the IPMC discussion for the graduation of Apache >>> Celix. The proposed resolution can be found at the bottom of this email. >>> >>> Any feedback is appreciated, and where needed we will any remaining issues >>> as soon as possible. >>> >>> Thanks in advance >>> >>> Alexander Broekhuis >>> (PPMC member of Apache Celix) >>> >>> [1]: http://incubator.apache.org/guides/graduation.html#checklist >>> [2]: http://markmail.org/thread/7y3a2l6qqm56cvud >>> [3]: https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-50 >>> [4]: http://incubator.apache.org/projects/celix.html >>> >>> >>> === Board Resolution == >>> >>> X. Establish the Apache Celix Project >>> >>> WHEREAS, the Board of Directors deems it to be in the best >>> interests of the Foundation and consistent with the >>> Foundation's purpose to establish a Project Management >>> Committee charged with the creation and maintenance of >>> open-source software, for distribution at no charge to >>> the public, related to a native implementation of the OSGi >>> specification. >>> >>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management >>> Committee (PMC), to be known as the "Apache Celix Project", >>> be and hereby is established pursuant to Bylaws of the >>> Foundation; and be it further >>> >>> RESOLVED, that the Apache Celix Project be and hereby is >>> responsible for the creation and maintenance of software >>> related to a native implementation of the OSGi >>> specification; >>> and be it further >>> >>> RESOLVED, that the office of "Vice President, Apache Celix" 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 Celix Project, and to have primary responsibility >>> for management of the projects within the scope of >>> responsibility of the Apache Celix 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 Celix Project: >>> >>> * Alexander Broekhuis >>> * Pepijn Noltes >>> * Bjoern Petri >>> * Erik Jansman >>> >>> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Alexander Broekhuis >>> be appointed to the office of Vice President, Apache Celix, 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 Celix 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 Celix Project; and be it further >>> >>> RESOLVED, that the Apache Celix Project be and hereby >>> is tasked with the migration and rationalization of the Apache >>> Incubator Celix podling; and be it further >>> >>> RESOLVED, that all responsibilities pertaining to the Apache >>> Incubator Celix podling encumbered upon the Apache Incubator >>> Project are hereafter discharged. >>> >>> -- >>> Met vriendelijke groet, >>> >>> Alexander Broekhuis >>> >> >> >>
Re: [DISCUSS] Graduate Apache Celix as TLP
On 13 Jun 2014, at 17:32 pm, Marvin Humphrey wrote: RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Celix Project: * Alexander Broekhuis * Pepijn Noltes * Bjoern Petri * Erik Jansman > > Four is a very small number for a PMC. I've commonly heard people argue that > five should be the cutoff. If just two people move on, the project won't be > able to make releases. > > My personal feeling is that small PMCs are OK when at least one member has > been added during incubation (demonstrating openness) and when the project has > been around for years with stable core personnel who are unlikely to > disappear. But four is still really low, and it wouldn't surprise me if > the Board objected. Just for reference, so far these people have consistently contributed to the project over time. If the board simply considers the project too small, we will of course have to let the project stay in the incubator for some more time, but this is the first time I heard about such a requirement (PMC size >= 5). Greetings, Marcel
Re: [DISCUSS] Graduate Apache Celix as TLP
Hello Bertrand, On 16 Jun 2014, at 8:57 am, Bertrand Delacretaz wrote: > On Sat, Jun 14, 2014 at 9:32 PM, Marvin Humphrey > wrote: >> Here's current Board member Bertrand Delacretaz in 2012: > ... >> People come and go, so to be realistic I'd say you need at least five >> active PMC members at graduation time, so as to get three votes when >> needed, with some "spares". Mentors staying on board can of course >> count in those five > > Thanks Marvin for digging this up, and yes I still agree with myself ;-) > > The board might or might not object to graduation but regardless it > would IMO be much better to have at least one more PMC member, > otherwise the board might have to step in if the PMC becomes too > small, and it would most probably do so without much context about the > project which is far from ideal. > > A simple solution to that is for at least one of the mentors to stay > on the new PMC, would one of them agree to do that? It doesn't mean > you have to be very active, but at least stay there just in case. Since I regularly get involved in discussions (but hardly ever commit code) I would like to stay involved. So, Alexander, feel free to update the graduation proposal and add me. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
RE: [VOTE] Graduate Apache Celix as Top Level Project
+1 I've been mentoring the project since it entered the incubator and I truly feel they have demonstrated they know "the Apache way". Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[IP CLEARANCE] Felix UserAdmin contribution
Please review the following contribution for IP clearance: http://incubator.staging.apache.org/ip-clearance/felix-user-admin-2.html Thanks! Greetings, Marcel
Re: Openmeetings - A Shepherd's View
On Sep 14, 2012, at 10:24 AM, Mohammad Nour El-Din wrote: > On Fri, Sep 14, 2012 at 4:24 AM, Alexei Fedotov > wrote: >> 14.09.2012 3:46 пользователь "Mohammad Nour El-Din" >> написал: >>> One minor note: >>> - In [1] I noticed files related to Eclipse like .classpath and >>> .project, I am not sure that these files should be in a release tag. >>> Comments about that ? > > Well my concern was more like a question to raise here not actually > something to take on the project itself, to be honest I am not aware > about any rules that might prohibit that, but for at least most of the > projects I didn't see them committing IDE specific files into the > repository. Thats why I raised the question here to see what others > do. Since these are xml files and you can definitely edit them like other build files, I can't see any reason why they could not be part of a source release either. However, I do think they need a proper license header (the file I quickly checked [1] did not have that). I'm not aware of a way to tell Eclipse to add such headers automatically, so you might have to do that by hand or some script. Greetings, Marcel [1] https://svn.apache.org/repos/asf/incubator/openmeetings/tags/2.0/.project
[RESULT] [IP CLEARANCE] Felix UserAdmin contribution
Just to wrap it up, the 72 hour window has more than passed, so I'm calling this IP clearance complete. Thank you. Greetings, Marcel On Sep 4, 2012, at 9:57 AM, Marcel Offermans wrote: > Please review the following contribution for IP clearance: > > http://incubator.staging.apache.org/ip-clearance/felix-user-admin-2.html > > Thanks! > > Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release celix-0.0.1-incubating
On Oct 27, 2012, at 17:26 , Alexander Broekhuis wrote: > Hi all, > >> http://pgp.mit.edu/ is a go-to place for most of us. > > I've added the key to mit.edu as well. > > Concerning the download, I've changed the mime-type but that doesn't seem > to help. But since this is only the case when directly downloading from the > svn, and not the case when downloading from the actual staging areas later > on, I don't thinks this is a blocking problem. I had no problems downloading and verifying the release with "wget" (and similar issues when trying with Chrome) so I don't think it's a blocking issue with the release, but something infra can hopefully resolve. > Can someone please take another look at this? That would be nice, as people know, Celix only has two mentors at the moment (Karl and me) so we really need somebody else to review this release and/or sign up as an extra mentor. > Sebb: Can you please check it out again and if all looks good change your > vote? The mentioned problems aren't related to the artifact itself, and we > do like to get our first release out.. Sebb? Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Anticipating my reign of terror -- new idea for December
On Nov 4, 2012, at 23:29 PM, Benson Margulies wrote: > At the bottom of the template for each podling's report, I'd like to have a > space for each of the mentors, every month, to reaffirm his or her > involvement in the podling. Thus, instead of (at most) one mentor signing > off on the report, itself, we'd get a reading on how many mentors are in > the game. If the number were less than 3 -- and -- especially, if it were > less than one, we'd be alerted and could make it a priority to find > replacements. > > What do you think? I like that idea, and in fact I'm currently mentoring one project (Celix) which currently still needs one extra mentor. I don't want to hijack the thread by asking for one, I just want to confirm that this would be a good idea. Even something like a temporary extra mentor (which could be somewhat in between a shepherd and a permanent mentor) would be welcome to review and vote on releases, etc. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Formats of SHA/MD5 checksums
On Nov 30, 2012, at 3:03 AM, Roman Shaposhnik wrote: > On Thu, Nov 29, 2012 at 12:12 AM, Alexander Broekhuis > wrote: >> I am fine with a change of the format. But at the moment we (Celix) still >> have a pending release. Seeing that many other project use different >> formats, I personally don't see this as a show stopper for our current >> release.. >> >> Can we somehow reach a consensus that for a next release the format will be >> different? (ie the format used by md5sum). > > I think that would be a fine choice. I'm fine with releasing it as is for now > +1 (binding). Thanks. > That said -- I'd like to see the next release take into account the feedback > that has been provided to the project so far. Nothing there is blocking, > but not taking it into account would, in my opinion, make it more difficult > to review and thus diminish the chances of getting enough eyeballs to > look at it in time. +1 For a very first release attempt, I think the project did a good job, and it would definitely demonstrate "getting the Apache way" by taking all the suggestions and incorporating them in the next release. Yes, the "incubator rules" are not always written down well/correctly so releasing something will always trigger some amount of discussion. In that sense the incubator itself is also constantly improving. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Thinking about graduation?
On Dec 13, 2012, at 22:39 PM, Olivier Lamy wrote: > 2012/12/13 Benson Margulies : >> Reading your report, I don't see any barrier to graduation. This could >> be good, insofar as you all could discuss this, and move toward >> graduation. Or it could be less good, if you have barriers that you >> didn't report. >> >> What do you think? > For me, sounds good for next board (next month). > If we finish first release before :-). In september, Jukka noted that most commits were done by two committers (Jean-Baptiste and Olivier) and Jean-Baptiste then agreed that before graduation, the community needed to grow in terms of committers and users. I took a quick look at a report that Ohloh generates on Kalumet [1] and I still see 170 out of 178 commits coming from two committers. Am I somehow looking at wrong data? If not, I would like to see some growth before we vote on graduation. Of course, that's only my opinion, so feel free to disagree. Greetings, Marcel [1] http://www.ohloh.net/p/apache-kalumet/contributors/summary
Re: [VOTE] Release Apache Onami parent 1-incubating
On Dec 19, 2012, at 14:15 , Fabian Christ wrote: > 2012/12/19 Christian Grobmeier > >> Disclaimer and License is available in the source tag: >> http://svn.apache.org/repos/asf/incubator/onami/tags/parent-1-incubating/ >> >> I do not see a chance to put these files to Nexus. Or do you have an idea? >> > > The problem is that we do not vote on SVN tags. We vote on released source > packages. > > Just create a ZIP file that contains everything needed. This can be > automated using the "apache-release" profile when using Maven. This ZIP > file can be uploaded in Nexus or placed somewhere in the /dist/dev area. > > I do not have enough experience to tell if this is a blocker for now or > something that could be fixed with the next release. To me this is a blocker. Our release policy [1] clearly states: "Every ASF release must contain a source package […]". It goes on to mention that such a source package must also contain a copy of our LICENSE and a NOTICE. Greetings, Marcel [1] http://apache.org/dev/release.html
Mentor for Celix?
Hello Roman, Thanks for helping out with reviewing the Celix release over the last couple of weeks. After Luciano stepped down as a mentor some time ago, we are still one mentor short. Would you consider becoming one, so we have three again? Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Do all releases need to go to /dist?
Well, I don't think it's fine. As long as our release policy states that all releases must be archived on /dist we should do exactly that. Or change the policy. Greetings, Marcel On Dec 21, 2012, at 12:53 , Benson Margulies wrote: > The Maven PMC pushes no plugin releases nor parent poms to /dist. We > just leave them on repository.apache.org and of course on Maven > central. So, I think this is a pretty safe precedent. > > On Fri, Dec 21, 2012 at 5:58 AM, Christian Grobmeier > wrote: >> Hello fellows, >> >> with Onami we are currently working to release a parent pom (only). >> Its just related to maven and so our idea was to spread it via >> repository.a.o only. >> >> Now reading this: >> >> "All releases must be archived on http://archive.apache.org/dist/. >> >> An automated process adds releases to the archive about a day after >> they first appear on to http://www.apache.org/dist/. Once a release is >> placed underhttp://www.apache.org/dist/ it will automatically be >> copied over to http://archive.apache.org/dist/ and held there >> permanently, even after it is deleted from >> http://www.apache.org/dist/."; >> http://www.apache.org/dev/release.html#mirroring >> >> it seems we need to push it to /dist, even when its Maven only. Is >> that correct? I am asking because I could not find the Apache parent >> pom there (maybe I missed it) and it let me hope that we do not need >> to commit it to /dist. >> >> Thanks >> Christian >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Do all releases need to go to /dist?
On Dec 21, 2012, at 13:52 , Benson Margulies wrote: > On Fri, Dec 21, 2012 at 7:05 AM, Martijn Dashorst > wrote: >> On Fri, Dec 21, 2012 at 1:01 PM, Benson Margulies >> wrote: >>> Give me a URL where this policy is and I'll edit it. >> >> http://www.apache.org/dev/release.html > > While I agree that the page has a lot to say about putting releases on > /dist, I could not find any point in which it said, in so many words, > that /dist was required. I do, however, see how people would take that > implication. It does state that all releases must be archived on http://archive.apache.org/dist/ so I think that more or less implies that all releases must be put on /dist. I just feel that as soon as we start making exceptions, we will end up with many, and I really don't understand why this exception is necessary in the first place. In fact, I think it's a great benefit that all releases can be found in one single location, no exceptions. > So, I edited it to say the opposite for this case. I'm not pushing the > publish button; rather, I've started a thread on infra@ (which seems > to supervise this content) inviting people to tell me that I am wrong. > If I am still wearing my head tonight on the subject, I'll push the > publish button. I objected there as well, to me this is a big policy change, and one that I don't understand the reason of. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Onami Parent 1 RC2
-1 Because: The release now is a ZIP file, and contains the NOTICE and LICENSE files, but they must be located at the root of the archive [1], and not in a subfolder like they are now. A question about the contents of the NOTICE file, can you explain why you included the line: "Copyright 2010-2012 The 99 Software Foundation" ? Greetings, Marcel [1] http://www.apache.org/dev/release.html#full-copy-for-each-source-file On Dec 25, 2012, at 12:59 PM, Christian Grobmeier wrote: > Hi all, > > This is a call for a vote on releasing the following candidate as > Apache Onami parent 1-incubating. This will be our first release. > > Improvements over RC1: > * Created a source artifact including the pom + LICENSE and DISCLAIMER files > > Artifacts are on Nexus: > https://repository.apache.org/content/repositories/orgapacheonami-066 > > SVN Tag: > http://svn.apache.org/repos/asf/incubator/onami/tags/org.apache.onami.parent-1-incubating/ > > The vote is open for 72 at least hours and is closing ~ on December > 28th, 13:00pm GMT*. > > The Onami Podling has successfully voted with 7 +1 from: > > * Daniel Manzke > * Simone Tripodi > * Mohamma Nour El-Din (IPMC) > * Jordi Gerona > * Olivier Lamy (IPMC) > * Ioannis Canellos > * Christian Grobmeier (IPMC) > > We are aware that our artifact needs to go to /dist, even when it is > just useful for Maven. > > Please cast your votes: > > [ ] +1 release it > [ ] +0 go ahead, but ... > [ ] -0 uhm... > [ ] -1 don't release it, because... > > Thanks, > Christian > > -- > http://www.grobmeier.de > https://www.timeandbill.de > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > >
Re: [VOTE] Release Onami Parent 1 RC2
Hello Christian,
On Dec 26, 2012, at 11:05 AM, Christian Grobmeier wrote:
> Hi Marcel,
>
> On Wed, Dec 26, 2012 at 10:22 AM, Marcel Offermans
> wrote:
>> -1 Because: The release now is a ZIP file, and contains the NOTICE and
>> LICENSE files, but they must be located at the root of the archive [1], and
>> not in a subfolder like they are now.
>
> For me they are in the root folder. It looks exactly as the Apache Parent:
> https://repository.apache.org/content/repositories/releases/org/apache/apache/12/
>
> My package opens like this:
>
> $ tree .
> .
> ├── DEPENDENCIES
> ├── DISCLAIMER
> ├── LICENSE
> ├── NOTICE
> ├── pom.xml
> └── src
>└── site
>└── site.xml
>
> Can you please tell me what you are seeing? I really don't get what you mean.
This is what I am seeing:
Marcels-MacBook-Pro:Downloads marcel$ unzip -l
org.apache.onami.parent-1-incubating-source-release.zip
Archive: org.apache.onami.parent-1-incubating-source-release.zip
Length Date TimeName
0 12-21-12 05:29 org.apache.onami.parent-1-incubating/
0 12-21-12 05:29 org.apache.onami.parent-1-incubating/src/
0 12-21-12 05:29 org.apache.onami.parent-1-incubating/src/site/
531 12-21-12 05:29 org.apache.onami.parent-1-incubating/DISCLAIMER
11357 12-21-12 05:29 org.apache.onami.parent-1-incubating/LICENSE
208 12-21-12 05:29 org.apache.onami.parent-1-incubating/NOTICE
29715 12-21-12 05:29 org.apache.onami.parent-1-incubating/pom.xml
4193 12-21-12 05:29
org.apache.onami.parent-1-incubating/src/site/site.xml
262 12-21-12 05:29 org.apache.onami.parent-1-incubating/DEPENDENCIES
---
46266 9 files
Sorry for the crappy formatting. :)
Just to be sure it's not my "unzip" tool:
Marcels-MacBook-Pro:Downloads marcel$ jar tf
org.apache.onami.parent-1-incubating-source-release.zip
org.apache.onami.parent-1-incubating/
org.apache.onami.parent-1-incubating/src/
org.apache.onami.parent-1-incubating/src/site/
org.apache.onami.parent-1-incubating/DISCLAIMER
org.apache.onami.parent-1-incubating/LICENSE
org.apache.onami.parent-1-incubating/NOTICE
org.apache.onami.parent-1-incubating/pom.xml
org.apache.onami.parent-1-incubating/src/site/site.xml
org.apache.onami.parent-1-incubating/DEPENDENCIES
>> A question about the contents of the NOTICE file, can you explain why you
>> included the line:
>> "Copyright 2010-2012 The 99 Software Foundation" ?
>
> hm I think the original package maintainer left this in the NOTICE
> file. Before Onami came to the Incubator, it was maintained by "99
> Software Foundation" (which is not really a registered foundation).
> Most likely he thinks that the history should be kept in the NOTICE
> file like we do sometimes with attributing people who donated a few
> classes.
It should only be in the notice if Onami contains third-party software that
requires you mention it [1]. Since this is code that was donated to Apache, I
don't think that applies, so you should leave it out.
Greetings, Marcel
[1] http://apache.org/legal/resolved.html#required-third-party-notices
Re: [VOTE] Release Onami Parent 1 RC2
Hello Simone, In general I'm always sceptical when people point at old releases and say "this must be okay because X did it like this as well". However, in this case I agree that there are many packagers that put in an extra folder in their source archive and put those files there. So: +1 for me Regarding the extra copyright notice. I'm not a lawyer, I just think it does not belong there. No showstopper as far as I'm concerned, but I would remove it for the next release. Greetings, Marcel On Dec 27, 2012, at 11:06 , Simone Tripodi wrote: > Salut Marcel/all, > >> So either all of these packages are "wrong" or it seems it is >> acceptable usage. Actually I think it is fine: it is the only folder >> which becomes extracted for me everything inside this folder is >> "root". > > +1, and I'd invite you reconsidering to change the -1 vote to a +1: > inspecting the org.apache:apache:12 it clearly shows the same > structure of org.apache.onami:org.apache.onami.parent:1-incubating > > * with unzip: > > $ unzip -l apache-12-source-release.zip > Archive: apache-12-source-release.zip > Length Date TimeName > >0 11-01-12 22:57 apache-12/ >0 11-01-12 22:57 apache-12/src/ >0 11-01-12 22:57 apache-12/src/site-docs/ >0 11-01-12 22:57 apache-12/src/site-docs/apt/ >15519 11-01-12 22:57 apache-12/pom.xml > 2759 11-01-12 22:57 apache-12/site-pom.xml > 6265 11-01-12 22:57 apache-12/src/site-docs/apt/index.apt > 2233 11-01-12 22:57 apache-12/src/site-docs/site.xml > 280 11-01-12 22:57 apache-12/DEPENDENCIES >11358 11-01-12 22:57 apache-12/LICENSE > 182 11-01-12 22:57 apache-12/NOTICE > --- >38596 11 files > > * with jar: > > $ jar tf apache-12-source-release.zip > apache-12/ > apache-12/src/ > apache-12/src/site-docs/ > apache-12/src/site-docs/apt/ > apache-12/pom.xml > apache-12/site-pom.xml > apache-12/src/site-docs/apt/index.apt > apache-12/src/site-docs/site.xml > apache-12/DEPENDENCIES > apache-12/LICENSE > apache-12/NOTICE > > moreover, the org.apache.onami:org.apache.onami.parent:1-incubating > zip archive has built with the > org.apache.apache.resources:apache-source-release-assembly-descriptor:1.0.4 > :) > >>> It should only be in the notice if Onami contains third-party software that >>> requires you mention it [1]. Since this is code that was donated to Apache, >>> I don't think that applies, so you should leave it out. >> >> Makes sense to me too. Do you consider it a blocker? > > It is not a blocker and should be tolerable/acceptable, since previous > maintainers have already been mentioned in NOTICE file, see Any23's > NOTICE[1]. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Mentor for Celix?
On Dec 27, 2012, at 21:09 , Roman Shaposhnik wrote: > On Wed, Dec 19, 2012 at 2:43 PM, Marcel Offermans > wrote: >> Hello Roman, >> >> Thanks for helping out with reviewing the Celix release over the last couple >> of weeks. >> After Luciano stepped down as a mentor some time ago, we are still one >> mentor short. >> Would you consider becoming one, so we have three again? > > Sorry for the belated reply: yes I'd be happy to help you guys as a mentor. > Please sing me up as a replacement for Luciano. Thanks for helping out, Roman! I just confirmed your subscription to the private@ list. Welcome on board! Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate CloudStack from Incubator
+1 (binding) Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Looking for a Champion
I would never search for a generic job scheduling application in the Wicket project. I still don't know exactly what this new project is about, but the fact that it happens to use Wicket in itself is not enough to make it a Wicket subproject if you ask me. Greetings, Marcel On Jun 5, 2013, at 16:01 PM, Alexei Fedotov wrote: > Could it be a part of Apache Wicket? > -- > With best regards / с наилучшими пожеланиями, > Alexei Fedotov / Алексей Федотов, > http://dataved.ru/ > +7 916 562 8095 > > > On Wed, Jun 5, 2013 at 5:33 PM, Andy Van Den Heuvel > wrote: >> Hey Alexei, >> >> Yes, it does. >> >> On Wed, Jun 5, 2013 at 3:20 PM, Alexei Fedotov >> wrote: >> >>> Andy, >>> It uses Apache Wicket, doesn't it? >>> -- >>> With best regards / с наилучшими пожеланиями, >>> Alexei Fedotov / Алексей Федотов, >>> http://dataved.ru/ >>> +7 916 562 8095 >>> >>> >>> On Wed, Jun 5, 2013 at 4:42 PM, Andy Van Den Heuvel >>> wrote: Jenkins is a continuous integration server, it provides integration with SCM, Build Automation, Testing... This proposal is for a multi-purpose tool, providing support for Monitoring, Backup's,Process Automation, (also Continuous Integration though) The architecture is very different. The idea behind this has come up of using Hudson/Jenkins for several >>> years. On Wed, Jun 5, 2013 at 2:25 PM, Simon Lucy wrote: > Andy Van Den Heuvel wrote: > > I'm looking for a Champion to help me setup a proposal. >> The project is a pluggable all-round job scheduling application. >> > > > Not to be a killjoy but how is it different to Hudson/Jenkins? > > > S > > >> Can somebody help me? >> >> Thanks for your consideration. >> >> > > > >>> --**--**- > To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org< >>> general-unsubscr...@incubator.apache.org> > For additional commands, e-mail: general-help@incubator.apache.**org< >>> general-h...@incubator.apache.org> > > >>> >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache MetaModel into the Apache incubator
+1 (binding) Good luck guys! Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Spark for the Incubator
+1 (binding) Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Wave into the incubator
On 30 Nov 2010, at 7:52 , Dan Peterson wrote: > Please vote on the acceptance of Wave into the Apache incubator. +1 Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Please create android-inter...@incubator.apache.org
On 12 Dec 2010, at 15:50 , Noel J. Bergman wrote: > As per a the discussion and expressed interest in > general@incubator.apache.org, please create the > android-inter...@incubator.apache.org mailing list. > > Make me an initial moderator, but I'll request others to volunteer. Please add me as a moderator too. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] accept Easyant for incubation
Hello Antoine, For me it's non-controversial. I'd love to see something like this, but I'm probably not going to be able to spend a lot of time contributing to it. Maybe some OSGi specific parts, especially if we can somehow integrate them with Bnd and BndTools. Greetings, Marcel On Jan 17, 2011, at 22:25 , Antoine Levy-Lambert wrote: > Hi, > > We got no answer concerning Easyant. > > Does this mean that the proposal is non-controversial and that we should move > on to a vote ? > > Regards, > > Antoine > > > On 1/11/2011 12:28 PM, Antoine Levy-Lambert wrote: >> Hello all, >> >> We'd like to propose Easyant for entry into the ASF incubator. >> >> Easyant is providing a solution for projects who want to use Ant and Ivy >> with a lot of ready-made templates, with the option to customize. >> >> The draft proposal is available at : >> http://easyant.org/projects/easyant/wiki/ApacheProposal >> >> The Ant project has voted to sponsor the entry of Easyant at the Incubator >> [1]. >> >> For your convenience I have pasted this proposal below the email. >> >> Regards, >> >> Antoine >> >> [1] >> http://mail-archives.apache.org/mod_mbox/ant-dev/201101.mbox/%3c3a73c5da-e4a2-4cb6-8423-0a985246f...@hibnet.org%3E >> >> h1. EasyAnt Proposal >> >> The following presents the proposal for creating a new EasyAnt project >> within the Apache Software Foundation. >> >> h2. Abstract >> >> Easyant is a build system based on Apache Ant and Apache Ivy. >> >> h2. Proposal >> >> EasyAnt goals are : >> >>* to leverage popularity and flexibility of Ant. >>* to integrate Apache Ivy, such that the build system combines a >> ready-to-use dependency manager. >>* to simplify standard build types, such as building web applications, >> JARs etc, by providing ready to use builds. >>* to provide conventions and guidelines. >>* to make plugging-in of fresh functionalities easy as writing simple Ant >> scripts as Easyant plugins. >> >> To still remain adaptable, >> >>* Though Easyant comes with a lot of conventions, we never lock you in. >>* Easyant allows you to easily extend existing modules or create and use >> your own modules. >>* Easyant makes migration from Ant very simple. Your legacy Ant scripts >> could still be leveraged with Easyant. >> >> h2. Rationale >> >> On the Ivy and Ant mailing list, an often asked question is "Why Ivy is not >> shipped with Ant ?". Ant users (and some opponents) complains also about the >> bootstrapping of an Ant based build system: it is mainly about copying an >> existing one. EasyAnt is intended to response to both of these requirements: >> a prepackaged Ant + Ivy solution with standard build script ready to be used. >> >> Also taking inspiration from the success of Apache Maven, EasyAnt is >> adopting the "convention over configuration" principle. Then it could be >> easy to build standard project at least for all commons steps (no more need >> to reinvent the wheel between each projects). The "common" part should be >> easy enough to tune parameters without having deep ant knowledge (example >> changing the default directory of sources, force compilation to be java 1.4 >> compatible, etc...). >> >> Last but not least, EasyAnt is intended to provide a plugin based >> architecture to make it easy to contribute on a specific step of the build. >> Build plugins are pieces of functionality that can be plugged into or >> removed from a project. Plugins could actually perform a piece of your >> regular build, e.g. compile java classes during build of a complete war. Or, >> do a utility action, e.g. deploy your built web application onto a packaged >> Jetty server! >> >> h2. Current Status >> >> h3. Meritocracy >> >> Some of the core developers are already committers and members of the Apache >> Ant PMC, so they understand what it means to have a process based on >> meritocracy. >> >> h3. Community >> >> EasyAnt have a really small community (around 100 downloads per release). It >> is not a problem as the team is currently making restructuring changes. The >> team plans to make more promotion after those changes and strongly believe >> that community is the priority as the tool is designed to be easy to use. >> >> h3. Core Developers >> >> Xavier Hanin and Nicolas Lalev™ée are members of the PMC of Apache Ant. >> Jerome Benois is an Acceleo committer, he was a committer in Eclipse MDT >> Papyrus for two years and he's an active contributor in Eclipse Modeling and >> Model Driven community. He's a committer on Bushel project now contribute to >> the Ivy code base. He leads the EasyAnt for Eclipse plugin development. >> Jason Trump is leading Beet project on sourceforge >> (http://beet.sourceforge.net/). >> Jean-Louis Boudart is Hudson committer. >> >> h3. Alignment >> >> EasyAnt is based on Apache Ant and Ivy. Being part of Apache could help for >> a closer collaboration between projects. >> The team pl
Re: [VOTE][PROPOSAL] EasyAnt incubator
+1 Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Airavata into the Incubator
+1 Accept Airavata into the incubator - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Board Reports Due -- and missing
I removed it from the monthly section. On 19 May 2011, at 3:46 , David Crossley wrote: > Alex, same answer as for March 2011 report: > > Celix is listed in the Monthly section of ReportingSchedule. > Clutch gathers that data. > > If your project feels that it has finished their monthly > reporting cycles, then edit that schedule to go onto quarterly. > It is all in your control from here on in. > > You can report more often if you want. > > See the notes to projects at the top of ReportingSchedule. > > -David > > Noel J. Bergman wrote: >> Alex, >> >>> Celix is due in July according to >>> http://wiki.apache.org/incubator/ReportingSchedule >> >>> Is the automated system supposed to email every month? Or does it >>> follow the schedule and is there something wrong? >> >> I was going by what was on the May Wiki page. I just checked the reporting >> schedule, and also the April report, and see that Celix did report in April, >> as scheduled. >> >> --- Noel > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept OpenOffice.org for incubation
+1 (binding) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Searching volunteer
Hello Andrey, On 30 Jul 2011, at 10:07 , Andrey Kuznetsov wrote: > I am author of Imagero, JGUI, UIO and some other nice libraries. > I want to transfer my work to Apache. > However I don't have time and fortitude to do it by myself. > So I search for someone who could do it for (or with) me. If you want these projects to become part of Apache, the standard process is to write a proposal for them, and take them through incubation. During that process, we will determine if there is a community supporting the codebase and if you follow the ASF philosophy and guidelines for collaboration. The best place to start reading is the incubator website (http://incubator.apache.org/). I must be honest, if you state you're looking for someone else to take over, it does not sound like you have a community to support these projects and just transferring the code to Apache won't work. Greetings, Marcel
Re: AW: Searching volunteer
Hello Andrey, I'm sure those libraries are useful, I never stated otherwise! One other thing you could consider, if you don't want to go through incubation, is to see if the libraries could somehow enhance existing Apache projects. The first one that comes to mind is the Apache Commons project, which contains a lot of reusable components. Maybe somebody there is interested in helping you out? I took the liberty of cross posting this mail to their "dev" list to bring it to their attention. Greetings, Marcel On 30 Jul 2011, at 13:14 , Andrey Kuznetsov wrote: > Hello Marcel, > > Yes, I don't have community, so I hoped to find it here. > BTW missing community does not mean that libraries are useless. > > Imagero is still commercial library and is used by few big companies like > Agenzia Ansa. > I decided to make it open source now. > > I really don't have much time to go through incubator process etc. > So again, I hope find here someone who could help me. > > Andrey > > > > > -Ursprüngliche Nachricht- > Von: Marcel Offermans [mailto:marcel.offerm...@luminis.nl] > Gesendet: Samstag, 30. Juli 2011 12:17 > An: general@incubator.apache.org > Betreff: Re: Searching volunteer > > Hello Andrey, > > On 30 Jul 2011, at 10:07 , Andrey Kuznetsov wrote: > >> I am author of Imagero, JGUI, UIO and some other nice libraries. >> I want to transfer my work to Apache. >> However I don't have time and fortitude to do it by myself. >> So I search for someone who could do it for (or with) me. > > If you want these projects to become part of Apache, the standard process is > to write a proposal for them, and take them through incubation. During that > process, we will determine if there is a community supporting the codebase > and if you follow the ASF philosophy and guidelines for collaboration. The > best place to start reading is the incubator website > (http://incubator.apache.org/). > > I must be honest, if you state you're looking for someone else to take over, > it does not sound like you have a community to support these projects and > just transferring the code to Apache won't work. > > Greetings, Marcel > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Kalumet to join Incubator
+1 (binding) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Apache Callback for incubation
+1 (binding) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Making up policy on the fly
On Aug 20, 2009, at 10:12 , ant elder wrote: On Thu, Aug 20, 2009 at 8:15 AM, Bertrand Delacretaz wrote: I agree with Bill that it's a good thing for the Incubator to clarify best practices, and teach podlings to follow them even if older projects sometimes don't. We tend to do the same for our kids, don't we ? ;-) I don't have any issue with trying to teach poddlings best practices being a good idea, but i don't think the way we're handling poddling releases is doing that. [...] I think a big cause of frustration for poddlings and mentors is the unpredictable nature of release reviews with each vote for a release or RC respin getting a different set of best practice requirements depending on who is around to review. Bertrand's analogy about educating kids highlights the problem. No two parents raise their children in exactly the same way and if lots of them all give their interpretation about "values" and "best practices" the message can become quite confusing to these kids. So is there anything that can be done to streamline that? Like having just the mentors of the project vote on the release, instead of everybody? If the mentors do a bad job, hold them accountable directly without "confusing" the project. Does that make any sense? Greetings, Marcel
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
On Sep 1, 2009, at 17:45 , Guillaume Nodet wrote: ACE is another podling related to OSGi and AFAIK it implements the DeploymentAdmin OSGi spec. Just to clear up any misconceptions: ACE does not implement the DeploymentAdmin spec. That was donated to Felix and ACE uses it. ACE is an application that uses OSGi as its architecture and can provision components to OSGi targets, but it can distribute software and configuration to non-OSGi targets too. In other words, it uses the OSGi specification and some of the compendium services to build a modular application. Of course this type of application can very well be used together with OSGi applications, but I think there is a difference between implementing the enterprise parts of the OSGi spec and using bundles from Felix for another application. Greetings, Marcel - 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 Sep 1, 2009, at 16:38 , Jeremy Hughes wrote: It is a goal of the Aries project to provide a natural home for open source implementations of current and future OSGi EEG specifications, including the opportunity for the collaborative development of compliance tests, and an environment to demonstrate the composition of these technologies and to explore areas where EEG specifications lack coverage. A further goal of this project is to leverage experience gained from it to inform contributions to OSGi EEG requirements and specification documents. Just reading this paragraph my initial reaction is that this is very much aligned with the Felix project. Felix's goals are basically to provide a full OSGi implementation of both the framework and compendium services whilst also providing a home for extensions to the specification that make sense. In that sense Aries sounds like a subset of Felix's goal, targetting the enterprise specifications. The Aries project will deliver run-time componentry that supports applications [...] The project is not expected to deliver a complete application or integration server runtime but will instead deliver enterprise application componentry that can be integrated into such runtimes. This makes a lot of sense. Any project building on a component architecture should be setup in such a way that many of the individual components can be combined and reused in different deployment scenarios. There is currently no Apache project focussed on OSGi enterprise applications that is independent from both the OSGi framework This is a really interesting topic, and others have commented on this: the perception that bundles in the Felix project only run on Felix. Of course anybody who makes an effort to understand OSGi quickly learns that the whole purpose of the spec is to have bundles that can run on any implementation and from years of experience of doing OSGi projects, I must say that every project I did, did in fact use bundles from Felix, Knopflerfish, Eclipse, Pax, various other sources as well as project specific bundles. My view is that we should really try to fix this misconception instead of using it as a reason to start new projects. For this reason we believe Aries is a project whose community would be best served if it could leverage but be independent from the communities that provide underlying OSGi framework technology If you look at the OSGi specification as a whole, it consists of two parts: the framework and the compendium. In fact, with the different expert groups, you could say there is more than one compendium as each expert group usually adds a compendium of their own. Anyway, OSGi is more than just the framework alone, and Felix already supplies an implementation of the whole spec, so there currently is no community that provide just the OSGi framework (also look at Knopflerfish and Equinox, both of which also provide compendium implementations). Relationships with Other Apache Projects I know ACE is only in incubation, but is there a reason for not mentioning it in this list? To me it makes sense to also consider technology to deploy and update OSGi components and I think ACE could fit in there nicely. The incubator. Successful graduation from Incubator should result in Aries becoming a new TLP. As others mentioned, this is perhaps an issue that should be addressed when leaving the incubator. As I explained above, my personal view is that this would fit nicely within the Felix TLP, especially since there seems to be a lot of focus on implementing the OSGi Enterprise "compendium" which is part of the OSGi specifications. On the other hand, if you guys really want to work outside of Felix then of course that's an option too. I do think it's great that there is a group of people wanting to implement these enterprise specs and explore related options! Let's just try and leverage each others' work as much as possible! Greetings, Marcel
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
Hello Kevan, On Sep 4, 2009, at 6:48 , Kevan Miller wrote: On Sep 3, 2009, at 1:23 PM, Niclas Hedhman wrote: 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? No. There were some internal sensitivities to the timing of the proposal (given the code donation and other rigamarole). Contacting the Felix PMC prior to proposal submission would have required additional approval... Perhaps could have been handled differently. However, in the end, I much prefer holding a public discussion rather than over a private@ list. I agree with you that a private@ list discussion would not have been the best way, but I don't see why that discussion could not have happened on the dev@ list. Anyway, it's in the past now, we should look forward and look for ways help each other. Greetings, Marcel - 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
It probably got swamped in the discussion, but, on Sep 1, 2009, at 22:20 , Marcel Offermans wrote: On Sep 1, 2009, at 16:38 , Jeremy Hughes wrote: Relationships with Other Apache Projects I know ACE is only in incubation, but is there a reason for not mentioning it in this list? To me it makes sense to also consider technology to deploy and update OSGi components and I think ACE could fit in there nicely. Does anybody want to comment on this? I would definitely like to collaborate on making ACE work well with anything Aries produces (since you were hinting it's not a single project but more a series of components). Greetings, Marcel
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
Hello Graham, ACE only just started, so no problem! :) I'm looking forward to working with Aries on making this happen. I agree with your analysis so far. Greetings, Marcel On Sep 6, 2009, at 22:32 , Graham Charters wrote: Hi Marcel, Not mentioning ACE was an oversight. I think there are two potential roles for ACE in relation Aries: 1. To distribute and configure the runtime components (those implementing the enterprise OSGi application programming model). 2. To distribute and configure enterprise OSGi application components implemented to the enterprise OSGi application programming model. Regards, Graham. 2009/9/6 Davanum Srinivas : Marcel, I believe it was an oversight to have missed mentioning ACE. Hopefully one of the proposed committers will comment on this aspect. thanks, dims On 09/06/2009 08:29 AM, Marcel Offermans wrote: It probably got swamped in the discussion, but, on Sep 1, 2009, at 22:20 , Marcel Offermans wrote: On Sep 1, 2009, at 16:38 , Jeremy Hughes wrote: Relationships with Other Apache Projects I know ACE is only in incubation, but is there a reason for not mentioning it in this list? To me it makes sense to also consider technology to deploy and update OSGi components and I think ACE could fit in there nicely. Does anybody want to comment on this? I would definitely like to collaborate on making ACE work well with anything Aries produces (since you were hinting it's not a single project but more a series of components). Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi
Hello Jeremy, Thanks! I'm still considering if it makes sense to add my name to the list of initial committers to help out with this, but I will definitely be following what's going on at Aries. Greetings, Marcel On Sep 9, 2009, at 13:09 , Jeremy Hughes wrote: Hi Marcel, I agree it was an oversight. I added the following to the "Relationship with Other Apache Projects" section: Apache Ace - http://incubator.apache.org/ace 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. 1. As a mechanism to distribute and configure the runtime components (those implementing the enterprise OSGi application programming model). 2. To distribute and configure enterprise OSGi application components implemented to the enterprise OSGi application programming model. Thanks, Jeremy 2009/9/6 Marcel Offermans : It probably got swamped in the discussion, but, on Sep 1, 2009, at 22:20 , Marcel Offermans wrote: On Sep 1, 2009, at 16:38 , Jeremy Hughes wrote: Relationships with Other Apache Projects I know ACE is only in incubation, but is there a reason for not mentioning it in this list? To me it makes sense to also consider technology to deploy and update OSGi components and I think ACE could fit in there nicely. Does anybody want to comment on this? I would definitely like to collaborate on making ACE work well with anything Aries produces (since you were hinting it's not a single project but more a series of components). Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Libcloud proposal for incubation
+1 (non-binding) Looking forward to using such a unified API from within ACE. Greetings, Marcel - 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
+1 (non binding) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Incubate Lucene Connector Framework
+1. Accept LCF into the Incubator. (non binding) Sounds like a very useful project. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: New Confluence Auto Export Step-By-Step Guide
Hello Les, On May 23, 2010, at 19:21 , Les Hazlewood wrote: > To that end, I created such a guide that I hope will help people in the > future: > > http://incubator.apache.org/shiro/confluence-auto-export.html > > Please feel free to comment and make suggestions. Hopefully this is > one less thing a podling has to worry about. Great guide! Regarding chapter 2, about static resources, it is possible to serve those from Confluence too. What we did at Felix was create a page called "Media" and attach all static resources to that page, like this: https://cwiki.apache.org/confluence/display/FELIX/Media Those files will then end up in a folder called "media.data". We use those both for images and CSS. The results can be seen in: http://felix.apache.org/site/media.data/ Regarding chapter 7, if you want to more quickly preview the results of your actions, Confluence auto exports its pages to a folder named after your space in the root of the cwiki server, like this: https://cwiki.apache.org/FELIX/ Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: A few questions about a potential entry into the incubator
On 27 Jul 2010, at 12:11 , Ross Gardler wrote: > Are there any problems bringing these modules into the podling, managing them > under the same community but each having separate release cycles. Apache Felix is one example of a project that consists of many modules, each with their own release cycle, so I can't imagine that's a problem. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Celix to enter the Incubator
Hello Richard, On 24 Sep 2010, at 17:21 , Richard S. Hall wrote: > I think this is interesting. However, I'd like to point out that you may need > to take care in how you position this. I believe the OSGi specs allow for > compliant open source implementations, but it is unlikely this implementation > will ever be fully compliant. So, you'd probably be best to just position it > as a C-based module system that provides OSGi interoperability. Good point. I will get in touch with the OSGi Alliance to check with them how we should call this, but I'm fine rephrasing it according to your suggestion. In any case I will report back to the list when I get a response from them. > And definitely don't call the mailing lists cosgi anything. :-) That was a mistake, corrected now. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Celix to enter the Incubator
On 24 Sep 2010, at 17:28 , Marcel Offermans wrote: > On 24 Sep 2010, at 17:21 , Richard S. Hall wrote: > >> I think this is interesting. However, I'd like to point out that you may >> need to take care in how you position this. I believe the OSGi specs allow >> for compliant open source implementations, but it is unlikely this >> implementation will ever be fully compliant. So, you'd probably be best to >> just position it as a C-based module system that provides OSGi >> interoperability. > > Good point. I will get in touch with the OSGi Alliance to check with them how > we should call this, but I'm fine rephrasing it according to your suggestion. > In any case I will report back to the list when I get a response from them. Following up on this, I talked to Peter Kriens of the OSGi Alliance at last week's OSGi Community Event and his response was that it's basically not allowed to use OSGi in the name of a project if it's the first word of a title, but otherwise he did not see any problems here. In fact, there was talk during that event about maybe even extending the specification to allow implementations in other languages. In the past, there has been some talk about this which resulted in a whitepaper called "Universal OSGi". In other words, as far as I can see this is not going to be a problem. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Celix to enter the Incubator
On 5 Oct 2010, at 8:58 , David Bosschaert wrote: > Small correction: Universal OSGi is an RFP, not a whitepaper. In fact, > it's RFP 89. > I'm currently working to see if I can distribute this RFP to a wider audience. You are right and that would be nice! Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Celix to enter the Incubator
Over the last couple of days, we have seen some good suggestions and support for the initial proposal. For implementing the Remote Services, some candidates have been identified (Axis2/C and SCA bindings in Tuscany). Before starting a vote we need a couple of mentors to support the project while it's in incubation. As the champion, I'd be happy to be a mentor too. This would be my first time, so I probably need to formally join the Incubator PMC first? So, who else would like to volunteer to become a mentor? Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Celix to enter the Incubator
On 6 Oct 2010, at 9:52 , Bertrand Delacretaz wrote: > On Tue, Oct 5, 2010 at 8:56 PM, Marcel Offermans > wrote: >> ...As the champion, I'd be happy to be a mentor too. This would be my first >> time, so I probably >> need to formally join the Incubator PMC first?... > > Yes, as a member you just need to ask at priv...@incubator.apache.org . Ok, Karl Pauls volunteered to become a mentor, and I have now joined the incubator PMC. I updated the proposal on the wiki to reflect that. Anybody want to join us to make it three before we put up the proposal for a formal vote? Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Ready to Graduate?
On 18 Oct 2010, at 21:12 , Noel J. Bergman wrote: > Please evaluate the status of your project with respect to graduation. Why, > for example, are Thrift and JSPWiki not yet ready to fly? What about Ace? ACE is still working towards a release. We want to demonstrate we can do that first. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Accept Celix for incubation
ill 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
[RESULT] [VOTE] Accept Celix for incubation
The vote for Celix to enter the incubator is now closed and has been ACCEPTED. The results: +6 (binding): Davanum Srinivas, Karl Pauls, Luciano Resende, Felix Meschberger, Bertrand Delacretaz, Alan D. Cabrera +1 (non-binding): Richard S. Hall Thanks to everybody who joined in on the discussion and vote. The mentors will now work on getting this project up and running. Greetings, Marcel - 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
I was present at those discussions, and I very much like the idea. One other project that already works on Android is Apache ACE (deploying software components to an Android based application that uses Apache Felix plus the ACE management agent). Learning about more project that work on Android, and getting more Android projects at Apache would be nice. Greetings, Marcel On 9 Nov 2010, at 16:13 , Noel J. Bergman 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 > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Proposal] Accept Jena into the Incubator
+1 On 9 Nov 2010, at 0:36 , Ross Gardler wrote: > I am pleased to offer, for your consideration, the following proposal to > accept Jena, a semantic web framework into the incubator. The text of the > proposal is copied here for your convenience and can be found at > http://wiki.apache.org/incubator/JenaProposal [snip...] Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept OpenNLP for incubation
On 19 Nov 2010, at 10:48 , Jörn Kottmann wrote: > lets vote on the acceptance of the OpenNLP Project for incubation > at the Apache Incubator. +1 Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Jena into the incubator
On 17 Nov 2010, at 14:10 , Ross Gardler wrote: > Please vote on the acceptance of JENA into the incubator. The proposal can be > found at http://wiki.apache.org/incubator/JenaProposal and is copied below. +1 Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Aries Graduation to TLP
On 22 Nov 2010, at 12:51 , Jeremy Hughes wrote: > Please VOTE on the below resolution for promoting Aries to an Apache > TLP and graduating from the Incubator. The VOTE is open for 72 hours. +1 Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Accept Wave for incubation
On 24 Nov 2010, at 4:29 , Michael MacFadden wrote: > I agree, there are other wave implementations popping up, some of which > include "wave" in the name and some don't. "Lightwave" for example is one > such project. I think that Apache Wave and the Wave in a Box product should > be fine. Lightwave? http://www.newtek.com/lightwave/ Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][RFC] Fediz for the Apache Incubator
On Nov 1, 2011, at 10:22 AM, Jean-Baptiste Onofré wrote: > http://wiki.apache.org/incubator/FedizProposal Definitely an interesting proposal! Just a comment on the affiliations section: isn't it true that both Olivier Lamy and Colm O'hEigeartaigh are also working for Talend? Of course part of the incubation process will be to attract other developers, I just think it's fair to list affiliations for all initial committers. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Graduate ACE from the Apache Incubator
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. Greetings, Marcel
Re: [VOTE] Graduate ACE from the Apache Incubator
Hello Ant, On Nov 17, 2011, at 16:56 PM, ant elder wrote: > On Thu, Nov 17, 2011 at 3:47 PM, Karl Pauls wrote: >> On Thu, Nov 17, 2011 at 4:38 PM, ant elder wrote: >>> On Thu, Nov 17, 2011 at 3: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@. >>> >>> 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. Starting with that last remark, the vote that was started earlier today is the "Community Graduation Vote" where we as the ACE community vote to confirm that we are ready and willing to start the graduation process (as explained here http://incubator.apache.org/guides/graduation.html#tlp-community-vote). Before that, on the ACE list, and in the last board report, we already expressed that we feel we're ready to graduate. Whilst I don't mind adding a step before this one in the graduation guide, I am not aware of skipping a step in the process. > The release does look a bit dubious to me. Point taken, we appreciate all the feedback and will take that into account when doing the next release. Greetings, Marcel
Re: should podlings have informal chairs?
On Nov 21, 2011, at 9:59 AM, Ross Gardler wrote: > On 21 November 2011 08:42, Robert Burrell Donkin > wrote: >> On Sat, Nov 19, 2011 at 7:45 PM, Brett Porter wrote: >>> Hi, >>> >>> Some time back we moved to having 3 mentors, which had the positive of more >>> hands and enough binding votes, but the downside of no single person "on >>> the hook" for a podling's reporting and progress towards graduation. >>> >>> Should we appoint one of the mentors at the start to be the "chair" of the >>> PPMC, in the same way as a full project? I would see them as responsible >>> for ensuring the podling is reporting, and that all of the mentors are >>> engaged and signing off the reports. >>> >>> As the podling matures, this role could be transitioned to the person who >>> will be nominated as the chair of the project after it graduates, if they >>> are ready for that. >>> >>> What do others think? >> >> I think appointing a chair in the early stages is likely to work >> against building a community of peers. > > I agree, especially if that "chair" is also a mentor. Mentors are not > supposed to *do* only to *guide*. Agreed, there should be no need to appoint one of the three mentors to become responsible. They should all be. I'm fairly neutral on appointing one of the members of the project, with a slight preference to not do that and see if a natural leader emerges. The mentors could monitor this, and if nobody within the project "steps up" that could be a (soft) criterium for not yet letting the project graduate. > On the other hand, I do think the original point of none of the three > mentors being responsible is a problem. Shouldn't mentors, of all people, be able to figure this out amongst themselves and lead by example here (without too many rules)? >> I think that establishing a chair once community has self-organised >> would be a good idea. > > Not before graduation. I have seen, in a number of podlings, that the > obvious choice of a chair half way through graduation (for example) is > often not the same choice at the end of graduation. +1 for letting this evolve naturally and only choosing at graduation. Greetings, Marcel - 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 Nov 21, 2011, at 18:28 PM, William A. Rowe Jr. wrote: > On 11/21/2011 11:11 AM, Benson Margulies wrote: >> Speaking wearing a hat: >> >> There is no requirement for monolithic releases. The project can >> choose whatever units it likes to release, so long as each one of them >> is fully buildable from the materials voted on in the release. If they >> want to hold one vote on 400 of them, well, it casts some doubt on >> whether the voters actually tried them all, but then again many TLPs >> inspire doubt in my mind as to whether voters are actually testing all >> the source packages. > > If a project is creating 400 discrete "releases", this sounds to me > like an umbrella project. Consider the ability to "announce" that > a new release has occurred, and the frequency with which those would > be broadcast. > > There's nothing wrong with a release model which provides for updated > components within a much larger project, on a faster release cycle, > but clear documentation of which have been updated and which components > are still at their older revision that was previously approved. This last paragraph is an accurate description of how we setup ACE. It is built out of components that are assembled in different ways at runtime (using OSGi). The components themselves embed enough metadata to ensure that (even without access to the sourcecode or documentation) they can be assembled succesfully. Like other modular projects within Apache, it is setup so we can easily release individual components. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT] [VOTE] Graduate ACE from the Apache Incubator
It's time to call the vote on the "community graduation vote" for ACE. The results: +1: Bertrand Delacretaz (***), Karl Pauls (***), Carsten Ziegeler (***), Felix Meschberger (**), Toni Menzel, Brian Topping, Clement Escoffier (**), Angelo van der Sijpt, , Alexander Broekhuis, David Bosschaert, Benson Margulies (*), Chris A Mattmann (*), Alex Karasulu (*), Julien Vermillard (*), Alan D. Cabrera (*), Guillaume Nodet (*), Hadrian Zbarcea (*), Jean-Baptiste Onofré (*), Marcel Offermans (***) There were no other votes. * = IPMC ** = PPMC *** IPMC + PPMC The vote is succesful. Our next step will be to prepare a charter (see http://incubator.apache.org/guides/graduation.html#tlp-resolution). I will start writing a draft and post that on the list later today. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Heads up: ACE 0.8.1-incubator vote
As a heads up to the IPMC we wanted to announce that we just started a release vote[1] on the ace-dev mailing list about ACE 0.8.1-incubator. This release basically fixes a few issues that came up while running our community graduation vote [2]. As soon as the vote has been closed, we will call for an Incubator PMC vote. Greetings, Marcel [1] http://s.apache.org/6wn [2] http://s.apache.org/DgJ and http://s.apache.org/s4q - 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
repo? >>>>> >>>>> Yes. The only exception is the combining project as well, which is >>>>> part of the release (see previous mail) but not included in the >>>>> combined zip file it produces. >>>>> >>>>>> Or are there additional files that would need to be obtained from SVN? >>>>> >>>>> No. It is self-contained. >>>>> >>>>>> Just tried "mvn install" on the zip, and it failed with: >>>>>> >>>>>> [INFO] Building Apache ACE :: Log :: Listener >>>>>> [INFO]task-segment: [install] >>>>>> ... >>>>>> The system is out of resources. >>>>>> Consult the following stack trace for details. >>>>>> java.lang.OutOfMemoryError: PermGen space >>>>>> ... >>>>>> [INFO] Final Memory: 65M/314M >>>>>> >>>>>> What Maven settings are needed to build from source? >>>>> >>>>> Depends on your environment etc. For me, it builds out of the box but >>>>> just in case: >>>>> >>>>> export MAVEN_OPTS=-Xmx1024m >>>> >>>> That fixed it for me; perhaps should be added to README.txt. >>> >>> Yeah, that makes sense. >>> >>>> The NOTICE file seems to have gathered some unnecessary verbiage. >>>> >>>> For example: >>>> >>>>>>> >>>> This product includes software developed at >>>> The Apache Software Foundation (http://www.apache.org/). >>>> Licensed under the Apache License 2.0. >>>> <<< >>>> >>>> should be just >>>> >>>>>>> >>>> This product includes software developed at >>>> The Apache Software Foundation (http://www.apache.org/). >>>> <<< >>>> >>>> Similarly for all the other products - the license details belong in >>>> the LICENSE file, for example see the httpd versions: >>>> >>>> http://svn.apache.org/repos/asf/httpd/httpd/trunk/NOTICE >>>> http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE >>>> >>>> Httpd don't include 3rd party code using AL 2.0, but this can easily >>>> be documented by adding a list of products that use the AL 2.0 after >>>> the license text. >>>> >>>> It's a lot easier for end users if all the 3rd party products are >>>> listed in the LICENSE file. >>> >>> Yeah, that makes sense. >>> >>>> I could not find the CDDL license. >>> >>> Ups, yes, I see - the LICENSE contains the notice section of the code >>> under CDDL instead of the CDDL license itself (in the LICENSE see: >>> Jersey and JSR-250 License). Don't think this is a blocker as it is at >>> least saying it is licensed under CDDL this way but we need to fix >>> this to contain the actual CDDL license text for the next release. >> >> Sorry, but I think the problems with the NOTICE and LICENSE file go >> deeper than that. >> >> For example, for xstream, the license is at: >> >> http://xstream.codehaus.org/license.html >> >> This starts: >> >>>>> >> Copyright (c) 2003-2006, Joe Walnes >> Copyright (c) 2006-2009, XStream Committers >> All rights reserved. >> >> Redistribution and use in source and binary forms, with or without >> modification, are permitted provided that the following conditions are met: >> >> Redistributions of source code must retain the above copyright notice ... >> <<< >> >> However, the copy in the LICENSE file omits the first paragraph entirely. >> Which makes a nonsense of of the third (now second) paragraph as it >> references a non-existent copyright notice. > > Hm, but that copyright notice is inside the NOTICE. > >> The LICENSE file must contain the full license; the NOTICE file should >> contain whatever notice is required by the license. >> >> I think the same applies to at least one other entry in the license >> file (knoplerfish) > > Yeah, that seems to be the pattern. Again, the copyright notice is > there but in the NOTICE. The licenses in the LICENSE files are missing > the copyright header. Summarizing this, for both XStream and Knopflerfish we only redistribute them in binary form. It require
[DISCUSS] Proposed resolution: Establish the Apache ACE Project
In preparation [1] of a vote to propose that the IPMC recommends this
resolution to the board, I am posting the resolution that was drawn up by the
ACE community and its mentors. Please provide feedback so we can finalize its
wording.
[1]
http://incubator.apache.org/guides/graduation.html#ipmc-top-level-recommendation
Greetings, Marcel
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
* Brian Topping
* Clement Escoffier
* Carsten Ziegeler
* Jean-Baptiste Onofre
* Karl Pauls
* Marcel Offermans
* Toni Menzel
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.
[VOTE] Apache ACE as a TLP
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 * Brian Topping * Clement Escoffier * Carsten Ziegeler * Jean-Baptiste Onofre * Karl Pauls * Marcel Offermans * Toni Menzel 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.
Re: [VOTE] Gora Graduation Resolution
On Dec 18, 2011, at 6:54 AM, Mattmann, Chris A (388J) wrote: > On Dec 17, 2011, at 6:16 PM, Niclas Hedhman wrote: >> I think the Board might have an issue with the 'purpose' of the >> project (I would if I was in the Board). The formulation >> >> " a Project Management Committee charged with the creation and >> maintenance of open-source software related to persistence, storage, >> and retrieval middleware for relational and NoSQL databases" From reading the homepage of the project, I got the initial impression that (like stated below) Gora is an ORM framework for column stores (such as Cassandra). When reading on, this initial definition is extended, just like the formulation above, in a couple of ways: a) it implies also relational databases are targetted; b) it extends the scope to all NoSQL databases. The background of the project does state that it has "limited support for SQL databases" and that it "ignores complex SQL mappings" so just out of interest, when would you use Gora over for example JDO (or JPA or Hibernate) when using a SQL database? The discussion you might get into with b) is that NoSQL is a very broad term and the actual NoSQL implementations vary wildly. You do state you support column stores, key-value stores and flat files, so probably summarizing that as NoSQL is reasonable. A further question I have is that Gora has a "specific focus on Hadoop", the "main use case for Gora is to access/analyze big data using Hadoop" which seems to indicate at least some kind of relation to Hadoop and I would think that would be worth mentioning in the formulation above. >> Also the STATUS page says that Gora is an ORM for column-stores. So, >> one would ask why has that expanded here. > > ORM for column-stores is largely equivalent to persistence, storage, and > retrieval middleware since ORM just expands to "object relational mapping", > which is responsible for persistence, storage and retrieval. ORM to me is > more nebulous, so I formulated and expanded description. From my brief analysis above, I'd say the definition on the status page might be a bit too narrow (assuming the statements on the homepage do a better job of explaining Gora, I have not actually used it). My question about its relation to Hadoop remains. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Gora Graduation Resolution
On Dec 18, 2011, at 18:15 PM, Mattmann, Chris A (388J) wrote: > On Dec 18, 2011, at 3:28 AM, Marcel Offermans wrote: >> On Dec 18, 2011, at 6:54 AM, Mattmann, Chris A (388J) wrote: >>> On Dec 17, 2011, at 6:16 PM, Niclas Hedhman wrote: >>>> I think the Board might have an issue with the 'purpose' of the >>>> project (I would if I was in the Board). The formulation >>>> >>>> " a Project Management Committee charged with the creation and >>>> maintenance of open-source software related to persistence, storage, >>>> and retrieval middleware for relational and NoSQL databases" >> >> From reading the homepage of the project, I got the initial impression that >> (like stated below) Gora is an ORM framework for column stores (such as >> Cassandra). When reading on, this initial definition is extended, just like >> the formulation above, in a couple of ways: >> >> a) it implies also relational databases are targetted; >> b) it extends the scope to all NoSQL databases. > > I still don't see that definition being extended above. ORM is middleware, > and it > is focused on relational (traditional) DBs. I've added in NoSQL stores to > cover > non-relational (column oriented ones) and Hadoop stores that we are also > targeting. In my view, ORM is middeware, but not all middleware is ORM. That's why I see it as an extension. More precise, you do state it's not just middleware, but "persistence, storage and retrieval middleware", but even that in my view is not a synonym for ORM. Looking at this from another angle, even the term ORM is probably not that good: it implies a mapping between an object model (check, that applies) to a relational model (nope, that does not apply for most NoSQL stores, they're definitely not relational). >> The background of the project does state that it has "limited support for >> SQL databases" and that it "ignores complex SQL mappings" so just out of >> interest, when would you use Gora over for example JDO (or JPA or Hibernate) >> when using a SQL database? > > I think this might be a good thread over on gora-dev if you are interested. > We'd be happy > to answer it there. Good point, just did that. >> The discussion you might get into with b) is that NoSQL is a very broad term >> and the actual NoSQL implementations vary wildly. You do state you support >> column stores, key-value stores and flat files, so probably summarizing that >> as NoSQL is reasonable. > > Cool, yeah that's what I thought. > >> A further question I have is that Gora has a "specific focus on Hadoop", the >> "main use case for Gora is to access/analyze big data using Hadoop" which >> seems to indicate at least some kind of relation to Hadoop and I would think >> that would be worth mentioning in the formulation above. > > I debated doing that too, Marcel. How would you update the sentence above to > include Hadoop? > Please suggest one and we'll try and integrate. My question is, does Gora require Hadoop, or is it just that its main use case just happens to involve Hadoop for splitting up the large amounts of data? >>>> Also the STATUS page says that Gora is an ORM for column-stores. So, >>>> one would ask why has that expanded here. >>> >>> ORM for column-stores is largely equivalent to persistence, storage, and >>> retrieval middleware since ORM just expands to "object relational mapping", >>> which is responsible for persistence, storage and retrieval. ORM to me is >>> more nebulous, so I formulated and expanded description. >> >> From my brief analysis above, I'd say the definition on the status page >> might be a bit too narrow (assuming the statements on the homepage do a >> better job of explaining Gora, I have not actually used it). My question >> about its relation to Hadoop remains. > > Thanks, yeah like I said if you've got a better idea at a sentence to use in > the board > resolution, I'm all ears. What about: "open-source software for mapping objects to NoSQL databases" and, IF it somehow requires Hadoop (see question above) that definition should probably be extended with something like "for Hadoop". Greetings, Marcel - 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 (binding) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Flex for Apache Incubator
Hello Alex, On Dec 19, 2011, at 21:20 PM, Alex Harui wrote: > I would like to propose Flex to be an Apache Incubator project. > > Here's a link to the proposal: > http://wiki.apache.org/incubator/FlexProposal First of all, thanks for this proposal, it looks well thought out. I have a question about the list of third party dependencies (a list you're still compiling). Out of interest, could you please also include some indication of the licenses of those dependencies, and how easy or hard they would be to replace by open source equivalents (when appropriate)? Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULT] [VOTE] Apache ACE as a TLP
After 72 hours have gone by, this vote has passed with 11 binding IPMC +1 votes and no other votes: +1: Bertrand Delacretaz, Mark Struberg, Jean-Baptiste Onofré, Senaka Fernando, Chris A Mattmann, Olivier Lamy, Niclas Hedhman, Karl Pauls, Marcel Offermans, Tim Williams, Daniel Kulp I will send the resolution to the board for inclusion in their next board meeting (which formally will be the one in January as we missed the 72 hours in advance deadline for the one in December, but who knows ;) ). Thanks to everybody for their vote, support and feedback during incubation. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
+1 (binding) Good luck guys! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] DeviceMap to join the Apache incubator
+1 (binding) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
Whilst I agree there is value in demonstrating a starting podling what a good report should look like by doing it for them, I also strongly believe in learning by doing, so I would still propose that a podling has a go at it themselves, before having a mentor step in. In the end, this is also a question of "mentoring style" and I think we should leave that up to the mentors and podlings. A mentor should be actively involved in the discussion about the report though, ensuring that the end result is good. Greetings, Marcel On Jan 10, 2012, at 22:52 , Joe Schaefer wrote: > I don't know about you, but in the podlings I mentor I am subscribed > to most if not all of the mailing lists and try to read the bulk of > it all. I could easily write status reports for them if it was my > responsibility to do so, and for the initial 6 months would prefer > that mentors showed their podlings and their fellow mentors what can > be done with a properreport before passing that duty along to the PPMC. > > > > - Original Message - >> From: ant elder >> To: general@incubator.apache.org >> Cc: >> Sent: Tuesday, January 10, 2012 4:47 PM >> Subject: Re: Small but otherwise happy podlings >> >> I like the idea of mentors being expected to signoff on the wiki just >> to show that they are paying attention, but i also agree that it might >> be useful to have along with the poddling reports to have comments >> from the mentors. So how about doing both? Just extend the mentor >> signoff section to include comments so a poddling report is the >> poddling comments, mentor comments about whats going on and what >> they'd like to see the poddling doing in the next months and a signoff >> from all active mentors. >> >> Or Joe are you saying that we should scrap the poddling comments bit >> entirely? I think its useful to get a quick overview of whats going on >> and it gets them used to the TLP board report requirement. >> >> ...ant >> >> On Mon, Jan 9, 2012 at 6:27 PM, Joe Schaefer >> wrote: >>> Lame. I would actually like to see mentors WRITING the reports >>> at least for the first 6 months to a year, then going to sign-off >>> on the wiki. >>> >>> >>> >>> - Original Message - From: William A. Rowe Jr. To: general@incubator.apache.org Cc: Upayavira Sent: Monday, January 9, 2012 1:23 PM Subject: Re: Small but otherwise happy podlings On 1/9/2012 11:40 AM, Upayavira wrote: > Regarding attrition of mentors, it was discussed having mentors 'sign' > the board report for their podling. Could that be encouraged, and >> used > as a sign of minimum 'activity' for a mentor? How about simply sign off on podling-dev@? Even if it is "Thanks >> for drafting this! No edits from me." - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Small but otherwise happy podlings
I see your point. I still think that if you read a "bad" report it does not matter who wrote it, in the end you can still blame the mentors because it's their responsibility. Who wrote it is not that relevant to me. On Jan 10, 2012, at 23:10 , Joe Schaefer wrote: > The thing is there is no way to tell whether or not a mentor is > even CAPABLE of writing a status report for a podling if the podling > is immediately tasked with doing so themselves. We are in the boat > we are in now because we have for too long assumed any member who > offered to mentor a podling was ready, able, and willing to do a decent > job of it. Without putting any feedback loops into the system for > determining whether mentors are performing their job well we will > never be able to move to a system that's both providing proper oversight > organizationally and distributing trust to the mentors who are providing it. > > > > - Original Message - >> From: Marcel Offermans >> To: general@incubator.apache.org >> Cc: antel...@apache.org; Joe Schaefer >> Sent: Tuesday, January 10, 2012 5:03 PM >> Subject: Re: Small but otherwise happy podlings >> >> Whilst I agree there is value in demonstrating a starting podling what a >> good >> report should look like by doing it for them, I also strongly believe in >> learning by doing, so I would still propose that a podling has a go at it >> themselves, before having a mentor step in. In the end, this is also a >> question >> of "mentoring style" and I think we should leave that up to the >> mentors and podlings. >> >> A mentor should be actively involved in the discussion about the report >> though, >> ensuring that the end result is good. >> >> Greetings, Marcel >> >> On Jan 10, 2012, at 22:52 , Joe Schaefer wrote: >> >>> I don't know about you, but in the podlings I mentor I am subscribed >>> to most if not all of the mailing lists and try to read the bulk of >>> it all. I could easily write status reports for them if it was my >>> responsibility to do so, and for the initial 6 months would prefer >>> that mentors showed their podlings and their fellow mentors what can >>> be done with a properreport before passing that duty along to the PPMC. >>> >>> >>> >>> - Original Message - >>>> From: ant elder >>>> To: general@incubator.apache.org >>>> Cc: >>>> Sent: Tuesday, January 10, 2012 4:47 PM >>>> Subject: Re: Small but otherwise happy podlings >>>> >>>> I like the idea of mentors being expected to signoff on the wiki just >>>> to show that they are paying attention, but i also agree that it might >>>> be useful to have along with the poddling reports to have comments >>>> from the mentors. So how about doing both? Just extend the mentor >>>> signoff section to include comments so a poddling report is the >>>> poddling comments, mentor comments about whats going on and what >>>> they'd like to see the poddling doing in the next months and a >> signoff >>>> from all active mentors. >>>> >>>> Or Joe are you saying that we should scrap the poddling comments bit >>>> entirely? I think its useful to get a quick overview of whats going on >>>> and it gets them used to the TLP board report requirement. >>>> >>>>...ant >>>> >>>> On Mon, Jan 9, 2012 at 6:27 PM, Joe Schaefer >> >>>> wrote: >>>>> Lame. I would actually like to see mentors WRITING the reports >>>>> at least for the first 6 months to a year, then going to sign-off >>>>> on the wiki. >>>>> >>>>> >>>>> >>>>> - Original Message - >>>>>> From: William A. Rowe Jr. >>>>>> To: general@incubator.apache.org >>>>>> Cc: Upayavira >>>>>> Sent: Monday, January 9, 2012 1:23 PM >>>>>> Subject: Re: Small but otherwise happy podlings >>>>>> >>>>>> On 1/9/2012 11:40 AM, Upayavira wrote: >>>>>>> Regarding attrition of mentors, it was discussed having >> mentors >>>>>> 'sign' >>>>>>> the board report for their podling. Could that be >> encouraged, and >>>> used >>>>>>> as a sign of minimum 'activity' for a mentor? >>>>>> >>&
Re: Small but otherwise happy podlings
On Jan 11, 2012, at 4:10 AM, Joe Schaefer wrote: > UNSIGNED JANUARY REPORTS: > > Celix Celix is late reporting this month because of holidays. A report is being worked on, written by the PPMC and actively monitored by me. You can expect it later today. Greetings, Marcel
Re: -1 on this months board report (was: Small but otherwise happy podlings)
On Jan 11, 2012, at 23:49 PM, Sam Ruby wrote: > -1 for forwarding no the following reports from projects that are over > a year old and lacking crisp plan for graduatuation: > > Celix A plan is being discussed on the list, but did not make it into this month's report. I would kindly like to ask the board to accept delaying that plan until the next report. If that is too long, we can report about it next month? WDYT? Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: -1 on this months board report (was: Small but otherwise happy podlings)
On Jan 12, 2012, at 1:09 AM, Sam Ruby wrote: > On Wed, Jan 11, 2012 at 7:02 PM, Marcel Offermans > wrote: >> On Jan 11, 2012, at 23:49 PM, Sam Ruby wrote: >> >>> -1 for forwarding no the following reports from projects that are over >>> a year old and lacking crisp plan for graduatuation: >>> >>> Celix >> >> A plan is being discussed on the list, but did not make it into this month's >> report. I would kindly like to ask the board to accept delaying that plan >> until the next report. If that is too long, we can report about it next >> month? WDYT? > > I'm participating here as an Incubator PMC member. If the Incubator > portion of the Incbator report states that it was the lack of a crisp > plan for graduation was noted and discussed and will be addressed in > the next quarterly report, then I will gladly withdraw my -1 on this > report. Good point, I will explicitly add that so the board knows that a plan is being discussed, it was just not ready for inclusion in this report yet. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: -1 on this months board report (was: Small but otherwise happy podlings)
On Jan 12, 2012, at 1:11 AM, William A. Rowe Jr. wrote: > On 1/11/2012 6:02 PM, Marcel Offermans wrote: >> On Jan 11, 2012, at 23:49 PM, Sam Ruby wrote: >> >>> -1 for forwarding no the following reports from projects that are over >>> a year old and lacking crisp plan for graduatuation: >>> >>> Celix >> >> A plan is being discussed on the list, but did not make it into this month's >> report. I would kindly like to ask the board to accept delaying that plan >> until the next report. If that is too long, we can report about it next >> month? WDYT? > > That's exactly what Sam is describing. Pull the incomplete report (Noel > could choose to do so) and submit a more comprehensive report next month. > No harm no foul. Ok, so I will: a) wait to see if Noel pulls this months report completely; b) either report next month or when the next report is due in three months. The only point I was trying to make is that, as soon as discussions here were going in a direction where podlings over a year old should start coming up with a more concrete plan for graduation, I started this discussion on the Celix list as well. However, due to some vacations, that discussion has started attracting responses only this week. So it's just a timing issue, the community is aware and dealing with it. This board report just came a bit too soon. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Clarify the role of the Champion as an "incubation coordinator"
+1 Makes perfect sense to me! - 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)
On Feb 9, 2012, at 17:10 PM, Andrus Adamchik wrote: > On Feb 9, 2012, at 7:04 PM, Mattmann, Chris A (388J) wrote: > >> Hi Ross, >> >> Sorry, I didn't see a mail from Noel, but he's already the chair. >> If this VOTE isn't successful, then he'll remain the chair. If >> you want to explicitly call a VOTE for Noel, go ahead, but >> this is the VOTE I am interested in calling, thanks! >> >> Cheers, >> Chris > > > Well, if there's an election, the fair thing is to include all candidates and > see who gets the majority. A vote on just one candidate is odd. I agree with Ross and Andrus that this is a strange way to hold an election, and I would be in favor of doing this in a different way. Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)
+1 And thanks a lot Noel! Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
On Mar 29, 2012, at 15:07 , Bertrand Delacretaz wrote: > On Thu, Mar 29, 2012 at 2:41 PM, Jukka Zitting > wrote: >> ...It seems like Roy is much more categorical about this. Assuming I >> understand his point correctly, *no* binary dependencies are >> acceptable within a source tar ball. Let's see if I still correctly follow this discussion. So far we seem to have consensus about the fact that: a) the only official releases that Apache does are source releases, and b) source releases must not contain binaries (of any dependencies). So far so good, and the only suggestion I have in this area is that we should make a more clear distinction between what we officially release (and vote on) and anything else we might provide for convenience. Just taking a look at www.apache.org/dist/ reveals that it contains both, and a lot of the time not clearly separated, which is confusing. Furthermore, it seems that some projects have more than just their latest release there (which is another matter, not related to this discussion). I propose something like: * www.apache.org/dist/[project]/ for the latest source release that was voted on * www.apache.org/bin/[project]/ for "convenience" binaries, etc. >> What I don't quite (yet) understand is how a reference like >> "junit:junit:4.10" to a download service maintained by a third party >> is more acceptable than directly including the referenced bits... > > I think the difference is that by saying "get junit:junit:4.10 to > build this" we put the burden on our users to make sure they get the > right bits, either by building them themselves from the junit sources, > or trusting whoever provides them. > > By shipping those bits ourselves instead, we would take the > responsibility on our shoulders, which we don't want. Since we are allowed to somehow reference an artifact (as long as it has a license that is compatible with what we do) and have a build script download it, my question is, must this artifact come from a location *outside* of Apache, or are we also allowed to reference these binaries that were provided for convenience by our own projects? Related, how about binaries that are in a separate part of the SVN tree of a project (a part that is not released)? Can we reference and download (or checkout) those as part of a build script? Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] CloudStack for Apache Incubator
+1 (binding) Good luck! Greetings, Marcel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
