Re: [DISCUSSION] BlueSky Proposal
Bertrand Delacretaz wrote: On Dec 19, 2007 12:43 AM, Bill Stoddard [EMAIL PROTECTED] wrote: ...I've updated the BlueSky project proposal. Ting Peng and Incubator PMC, please review/update as needed and report back any concerns I have two concerns about http://wiki.apache.org/incubator/BlueSky: ... Sorry if I sound negative, I agree that the goals of the project are important, but I also see a risk of creating a project that might live on its own island, with very little ties to the rest of the ASF. I'm not saying it's impossible, but IMHO we have to make sure that the necessary agreements are in place before going further. I agree with Bertrand here. This project would, potentially, be interesting to my day job. It is unlikely that I would personally contribute, but it is entirely possible some of the projects here in UK higher education would be interested in the tools in this proposal. Your proposal needs to make it clear that such interested parties can participate as effectively in BlueSky as they can in other similar projects. Your proposal does have Make more documentation available in English as a initial goal, however I don't feel that is enough to ensure community growth within the ASF. As bertrand says, the primary documentation and communication language would need to be English. It's not an ideal situation, but the reality of worldwide distributed development within the ASF requires us to use a single language. Some mature projects have local language support (as opposed to development) hosted by the ASF. Would the incubator PMC find it acceptable for this project to have a Chinese language support forum for existing users (12 primary/high schools in China). I also find it a little hard to pin down exactly what this software is. It is billed as an eLearning system, yet it is described as a distributed, collaborative environment. When I hear e-learning I think of a virtual learning environment such as Moodle. Perhaps a short comparison with features of typical VLE system would be helpful - what makes this different from existing VLEs? I did look at your project website for this, it does mention a feature list but I could not actually find it. Ross - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] [VOTE] Approve release Apache UIMA 2.2.1-incubating
This vote has been open for more than a 72 hours. We have 4 binding +1s, no 0s and 1 -1s. Votes were cast by: Ant Elder (+1) Matthieu Riou (+1) Jean Anderson (+1) Martijn Dashorst (+1) Kevan Millar (-1) We will modify the checksum representation for MD5 and SHA1 so that tools can easier verify the release. The vote passes. Thank you all for checking our release! --Michael Baessler Michael Baessler wrote: The Apache UIMA committers ask the Apache Incubator PMC for permission to publish a new bug fix release of Apache UIMA. This release contains bug fixes of the Apache UIMA 2.2.0 release published in August 2007. For details about the fixes, please have a look at the release notes. We had a vote on uima-dev that resulted in 6 binding +1s (all the committers) and no 0s or -1s. The vote thread is here: http://mail-archives.apache.org/mod_mbox/incubator-uima-dev/200712.mbox/[EMAIL PROTECTED] Please review the release candidate here: http://people.apache.org/~mbaessler/uimaj-2.2.1/06/ There are subdirectories like: /bin - that contains the binary distribution files /src - that contains the source distribution files /rat - that contains the RAT reports (using RAT 0.5.1) with some comments /eclipseUpdateSite - that contains the eclipse update site artifacts /maven - that contains the Maven artifacts we would like to release to the incubator repository The SVN tag for this release candidate is: https://svn.apache.org/repos/asf/incubator/uima/uimaj/tags/uimaj-2.2.1/uimaj-2.2.1-06 Please vote: [ ] +1 Accept to release Apache UIMA 2.2.1 [ ] -1 No, because Thanks! -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Approve release Apache UIMA 2.2.1-incubating
On Dec 19, 2007 10:52 AM, Michael Baessler [EMAIL PROTECTED] wrote: ...We have 4 binding +1s, no 0s and 1 -1s I did vote +0 earlier in this thread. Just for the record, as it doesn'n make much of a difference other than express support ;-) -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thrift + Apache
If you decide to move forward on this Mark, I would be glad to help. -Ted. http://husted.com/blog/ On Nov 28, 2007 5:12 PM, Mark Slee [EMAIL PROTECTED] wrote: Hi all, Just a quick note to announce Thrift's official intention to join the Apache Incubator and introduce ourselves to the Apache list. For those not familiar with Thrift, it's a lightweight system for cross-language programming using code-generation, RPC, and object serialization. It's designed first and foremost to provide high performance in real-time environments (i.e. Facebook's backend, no surprises there). All the information, source code, and a whitepaper are available at: http://developers.facebook.com/thrift/ We'll be working on putting together our formal proposal shortly, but the first thing we wanted to solicit the list for was interest in being a Champion/Mentor for the project. Paul Querna has already volunteered to take on either role (or both), but as I understand it we're not limited to having just one person... so please give us a shout if you'd be interested in joining the effort in either of those roles. I'll leave it at that for now. And of course any initial feedback is more than welcome. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Approve release Apache UIMA 2.2.1-incubating
We had two additional votes... Now we have 5 binding +1s, one 0s and one -1s. Votes were cast by: Ant Elder (+1) Matthieu Riou (+1) Jean Anderson (+1) Martijn Dashorst (+1) Paul Fremantle (+1) Bertrand Delacretaz(+0) Kevan Millar (-1) Thanks again for your support! -- Michael Baessler Paul Fremantle wrote: I know I'm late but I'd like to add a +1 to the vote. Paul On Dec 19, 2007 10:02 AM, Michael Baessler [EMAIL PROTECTED] wrote: Bertrand Delacretaz wrote: On Dec 19, 2007 10:52 AM, Michael Baessler [EMAIL PROTECTED] wrote: ...We have 4 binding +1s, no 0s and 1 -1s I did vote +0 earlier in this thread. Just for the record, as it doesn'n make much of a difference other than express support ;-) Sorry I missed that! Thanks ! -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GUIDANCE] When should we start to follow new incubator policy on where to post releases?
Apache UIMA just passed its release vote; where should we post the release? A recent change to the incubator policy resulted in the page http://incubator.apache.org/incubation/Incubation_Policy.html saying that distributions *must* be from www.a.o/dist/incubator/podling-name. The www.a.o/dist site on people.a.o doesn't have an incubator subdirectory. So it looks like we might be the first incubator project since this policy was enacted., unless implementation of this policy is being delayed. Can someone on the IPMC let us know if the implementation is being delayed? Assuming we should be following this new policy now, should we ask infra to establish the new dist/incubator directory and also ... /dist/incubator/uima (or do we have the karma to do this ourselves)? If we do this, because things posted here are mirrored, as I understand it, we need to update our download page to properly handle directing downloaders to the mirrors. Some of us have read the docs on how to do this, and we can give it a go - but we would appreciate some oversight by an experienced person :-). Any volunteers? The policy page doesn't say what, if anything, we need to do at this time for our previous releases - my preference would be to just leave things as they are, for now, for those. Is this OK? -Marshall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Bennu, a Router, Firewall Wi-Fi perimeter
Hi, would it be okay to add the Bennu proposal to the Apache wiki at: http://wiki.apache.org/incubator/ That way proposal changes could be tracked and other people may be able to contribute to the proposal. On Dec 3, 2007 8:01 AM, Noel J. Bergman [EMAIL PROTECTED] wrote: I spoke with Cliff Skolnick about http://people.apache.org/~dsh/bennu/BENNU_PROPOSAL.txt He is interested and has some comments. Hopefully, he'll have time to comment this week. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Bennu, a Router, Firewall Wi-Fi perimeter
Please do! Paul On Dec 19, 2007 4:18 PM, Daniel Stefan Haischt [EMAIL PROTECTED] wrote: Hi, would it be okay to add the Bennu proposal to the Apache wiki at: http://wiki.apache.org/incubator/ That way proposal changes could be tracked and other people may be able to contribute to the proposal. On Dec 3, 2007 8:01 AM, Noel J. Bergman [EMAIL PROTECTED] wrote: I spoke with Cliff Skolnick about http://people.apache.org/~dsh/bennu/BENNU_PROPOSAL.txt He is interested and has some comments. Hopefully, he'll have time to comment this week. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Bennu, a Router, Firewall Wi-Fi perimeter
done :) On Dec 19, 2007 5:35 PM, Paul Fremantle [EMAIL PROTECTED] wrote: Please do! Paul On Dec 19, 2007 4:18 PM, Daniel Stefan Haischt [EMAIL PROTECTED] wrote: Hi, would it be okay to add the Bennu proposal to the Apache wiki at: http://wiki.apache.org/incubator/ That way proposal changes could be tracked and other people may be able to contribute to the proposal. On Dec 3, 2007 8:01 AM, Noel J. Bergman [EMAIL PROTECTED] wrote: I spoke with Cliff Skolnick about http://people.apache.org/~dsh/bennu/BENNU_PROPOSAL.txt He is interested and has some comments. Hopefully, he'll have time to comment this week. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] Oxygenating the Web Service Platform, www.wso2.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: freedom to do sane release management (was: Approve release Apache UIMA...)
On Dec 18, 2007, at 11:50 PM, William A. Rowe, Jr. wrote: Noel J. Bergman wrote: I disagree. I agree with the statement that All releases should be built from a tag. Worst case, you should make the tag by copying from the right version. That'd be a different rule; it's a tiny bit less broken a rule. Bill initially said Your distribution must correspond to subversion, specifically objecting to a scenario where the distribution was in fact generated from a subversion tag, but a bit differently structured. It's still a bad rule, because you're taking a (questionable) version control convention and making a rule out of it. The rules you're looking for are something like All source code in a source distribution should arrive in that source distribution using a repeatable procedure with an acceptable source control system providing the master source, and both the repeatable procedure and source control itself must be auditable. SVN is an acceptable source control system. Creating a straighforward tarball directly from an svn export is acceptable as a repeatable release-building procedure, though the expectation is that this is automated using a script. The bottom line of release management in the ASF. All artifacts should be generated from the tagged SVN That just isn't the bottom line. It's only the bottom line in some projects. It isn't ASF-wide policy, and if it were policy, it would not be a good policy, and would also not be enforceable. Just a few use cases that invalidate such a potential rule: built from tag, plus svn:externals * I have many subprojects that need the same license files. I put the license files in a central place, and then use svn:externals to pull in the files during checkout, and they get copied during the tarball build built from tag, plus svn metadata * I generate my ChangeLog from `svn log --xml`, which is done by a the same script that produces the tarball. The ChangeLog itself never makes it into SVN as its derivative of svn data itself. built from tag, plus non-tag svn metadata * I generate my ChangeLog directly from my branch because '--stop-on-copy' will do the right thing built from tag, plus additional files from other information system * I fetch documentation directly from our wiki installation for inclusion into every source distribution. I don't want to put the 40 megabytes of documentation into SVN. documentation distribution * my project is a CMS. We eat our own dogfood and maintain all our documentation inside an instance of our own CMS. I fetch documentation directly from that CMS and generate a documentation distribution out of it, thus showcasing how great my CMS is every time I do a release. my project does not use tags * I understand how subversion works internally, think that the trunk/branches/tags structure is a silly convention which does not make sense to use for my project because we have historically been supportive of the development mode used for distributed VC, so we have a lot of branches and a lot of semi-independent tips my project doesn't like unresolveable URLs * I fetch the LICENSE at build-time from http://www.apache.org/licenses/LICENSE-2.0 (yes, of course I program defensively and ensure a 200 return code and check the content of the file is roughly what I expected) You can obviously argue against any particular one of these and invent what ifs that, unless addressed, make it a bad idea to do things that way. They're just examples. The point is that, on the whole, there are many many ways to do really good and really dilligent release management, including doing very good tracking of everything in version control, yet still do a lot of things very differently. The second point is that there's a frequent tendency among incubator PMC members (and, err, most other human beings) to take their own opinions and experience about what constitutes reasonable practice and turn that into policy, taking away key elements such as self- governance in the process. This is just the one example. Do everyone a favor, work a little harder, and find the *real* thing we need to see ensured, independently of your own habits or preferences. The third point is that making sweeping statements about what must and must not happen probably does not help anyone, not when you do it off-the-cuff, without having some reference to any documentation or e- mail thread or whatever to back up the statement. And especially note when you swept a little too far. ciao! /LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [GUIDANCE] When should we start to follow new incubator policy on where to post releases?
On Dec 19, 2007 1:57 PM, Marshall Schor [EMAIL PROTECTED] wrote: Apache UIMA just passed its release vote; where should we post the release? A recent change to the incubator policy resulted in the page http://incubator.apache.org/incubation/Incubation_Policy.html saying that distributions *must* be from www.a.o/dist/incubator/podling-name. The www.a.o/dist site on people.a.o doesn't have an incubator subdirectory. So it looks like we might be the first incubator project since this policy was enacted., unless implementation of this policy is being delayed. Can someone on the IPMC let us know if the implementation is being delayed? no - it's just that i hadn't managed to find the cycles. i take a look at this tonight. Assuming we should be following this new policy now, should we ask infra to establish the new dist/incubator directory and also ... /dist/incubator/uima (or do we have the karma to do this ourselves)? i have some concerns over permissions so i'd like to chat to the infrastructure team before jumping in on this one i'm going to head over to the infrastructure channel on IRC. anyone who's interested is welcome to join me. If we do this, because things posted here are mirrored, as I understand it, we need to update our download page to properly handle directing downloaders to the mirrors. Some of us have read the docs on how to do this, and we can give it a go - but we would appreciate some oversight by an experienced person :-). Any volunteers? i will. look out for a post on the UIMA dev list. The policy page doesn't say what, if anything, we need to do at this time for our previous releases - my preference would be to just leave things as they are, for now, for those. Is this OK? these need to be archived. apache has special arrangements that ensure that archived releases will remain available. i need to chat to infrastructure but my gut feeling is that it would be better to archive them straightaway and save the strain on the mirrors. again, probably best to discuss this on IRC. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: freedom to do sane release management (was: Approve release Apache UIMA...)
On Dec 19, 2007 5:43 PM, Leo Simons [EMAIL PROTECTED] wrote: snip The second point is that there's a frequent tendency among incubator PMC members (and, err, most other human beings) to take their own opinions and experience about what constitutes reasonable practice and turn that into policy, taking away key elements such as self- governance in the process. This is just the one example. Do everyone a favor, work a little harder, and find the *real* thing we need to see ensured, independently of your own habits or preferences. this is why i've been trying to increase guidance and reduce policy. i think that writing up opinions into guidance is useful. ideally it should provide a starting point for communities to develop their own process. in my own mind, i'd like a release guide which any podling can mine to create their own, personal release guide. it's tough to start from nothing and a waste of effort to learn the hard way. better to read, think then choose. (perhaps a guide guide is needed to explain that guides are not policy but just a starting point for podlings to develop their own best practices...) on that note: leo any objections to me mining your post for the release documentation...? - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: freedom to do sane release management (was: Approve release Apache UIMA...)
Leo Simons wrote: On Dec 18, 2007, at 11:50 PM, William A. Rowe, Jr. wrote: The bottom line of release management in the ASF. All artifacts should be generated from the tagged SVN That just isn't the bottom line. It's only the bottom line in some projects. The point is that, on the whole, there are many many ways to do really good and really dilligent release management, including doing very good tracking of everything in version control, yet still do a lot of things very differently. I don't think we disagree all that much, although my point of placing the LICENSE, COPYRIGHT, NOTICE out front no matter how an individual chooses to obtain ASF source code still stands :) Reproduceable as things stood at that time is certainly good enough for me, and you offer lots of illustrations. Not reproducible (by forgetting to tag externals, for example) is usually a bad idea. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
