Re: [PROPOSAL] Libcloud Project
On Tue, Oct 27, 2009 at 6:59 AM, Paul Querna p...@querna.org wrote: I would like to propose incubating the existing Libcloud project to join the ASF Cool! I will try to make the time to help out a little; I'm interested in this space :) cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Wink 1.0
Yo. Looking pretty cool! Sorry, but, few tidbits inline... On Fri, Oct 23, 2009 at 3:53 PM, Nicholas L Gallardo nlgal...@us.ibm.com wrote: The Wink community voted on and approved the release of Apache Wink 1.0. We would now like to request the approval of the Incubator PMC for this release. Podling vote thread: http://www.mail-archive.com/wink-...@incubator.apache.org/msg02060.html The Maven staging area is at: https://repository.apache.org/content/repositories/wink-staging-002/ You're not going to get a +1 from me on all those artifacts - its way too much work for me to look through all of them [1]. I looked just at the distributions... The distributions are in: https://repository.apache.org/content/repositories/wink-staging-002/org/apache/wink/apache-wink/1.0-incubating/ The source release has a LICENSE and a NOTICE file that indicates it contains a bunch of stuff it does not actually contain. AFAICS it should simply have a LICENSE that is just the Apache License and a NOTICE file that has just our standard license header. The NOTICE file for the binary release should include only those notices that are actually required by the included library dependencies, and they should reproduce the exact text of those notices. For example, the slf4j notice line should not be there since slf4j does not require it. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Wink 1.0
On Tue, Oct 27, 2009 at 4:45 PM, Bryant Luk bryant@gmail.com wrote: The source release has a LICENSE and a NOTICE file that indicates it contains a bunch of stuff it does not actually contain. AFAICS it should simply have a LICENSE that is just the Apache License and a NOTICE file that has just our standard license header. I think you're suggesting a different LICENSE/NOTICE for source versus binary distributions. Yep, I see how it looks like thatthough maybe I'm _really_ suggesting a source-only distribution :-) Look, the general rule is quite simple: LICENSE files MUST contain all the license information that applies to an artifact, and SHOULD contain only the license information that applies to that artifact. Similarly, NOTICE files MUST contain all the notices that apply to an artifact, and SHOULD contain only the notice information that applies to that artifact. Whenever you violate that SHOULD, you are turning lazyness/sloppiness into a mess for your users. For example, with this current wink distribution, you are (appear to be?) passing on a lot of CDDL obligations down to wink users, which is annoying to users that care about such things. If all your user wants to do is copy/paste the glue code from GzipHandler, that's a rather heavy license to wade through. Similarly, that user of that GzipHandler code now has to copy/paste the entire contents of the NOTICE file. Do you really want to place a burden on your users like that? I did some random checking looking at some source versus binary Apache project distributions (incubator and non-incubator) and as far as I can tell, they kept their same LICENSE and NOTICE files even though they were not re-distributing the dependency binaries in the source archive. Don't mean to say we should just follow the crowd, but I don't think this is standard practice unless another thread has a viewpoint on this. Unfortunately, most apache projects are not as good at following policies as they should be, and most engineers (including me! :-) ) are not nearly as good at applying legal rules and guidelines as they should be. http://www.apache.org/dev/release.html#license What Are The Requirements To Distribute Other Artifacts In Addition To The Source Package? ... Nothing in this section is meant to supersede the requirements defined here and here that all releases be primarily based on a signed source package. The NOTICE file for the binary release should include only those notices that are actually required by the included library dependencies, and they should reproduce the exact text of those notices. For example, the slf4j notice line should not be there since slf4j does not require it. I see varying degrees of attribution to slf4j in other Apache (incubating and non-incubating) projects (some have none, some have a line). The slf4j line was kept from the Wink 0.1 release. IMHO, this is not a release blocker, but we can remove it in a future release if it is the right thing to do. Fortunately we have quite a clear rule on this topic these days, so no opinions are necessary: http://www.apache.org/dev/release.html#notice-content What Content Is Appropriate For The NOTICE File? ... Only mandatory information required by the product's software licenses. Not suitable for normal documentation. For background color, here's an earlier thread on this list (which is where I learned about the existence of that clear rule): http://mail-archives.apache.org/mod_mbox/incubator-general/200909.mbox/%3cf767f0600909090615t6582bfd1m36e4d8abe1392...@mail.gmail.com%3e cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Wink 1.0
On Tue, Oct 27, 2009 at 9:23 PM, Bryant Luk bryant@gmail.com wrote: Thanks for the links. One general comment I have is that I understand this is part of the incubation process (and no offense intended to Leo since obviously taking energy and time for this) but if I can't look and see if other Apache projects are doing things the right way, I think we should have more examples of what goes in the NOTICE and LICENSE files and points out licenses/situations/projects/wording that require that they be put in LICENSE/NOTICE files and not. It seems to be a common sticking point on this list for incubator projects. I would put up a patch for the website but obviously I am still learning. Yeah it's painful isn't it? How to get the legal stuff right remains surprisingly difficult after all these years. Help making it easier is always very welcome! [1] Look, the general rule is quite simple: LICENSE files MUST contain all the license information that applies to an artifact, and SHOULD contain only the license information that applies to that artifact. Similarly, NOTICE files MUST contain all the notices that apply to an artifact, and SHOULD contain only the notice information that applies to that artifact. ... just out of curiosity, how does this apply with Section 4.4 of the Apache license? Ooh, you're getting into this now, eh? Good :-) IANAL, I don't really know. I suspect the precise nitty-gritty legal case is actually a little more lenient than our policies. As in, even if legally all is sound whatever way, our release policies try to enforce some additional clarity and consistency to make things as easy as possible for the user. http://www.apache.org/dev/release.html#notice-content What Content Is Appropriate For The NOTICE File? ... Only mandatory information required by the product's software licenses. Not suitable for normal documentation. For background color, here's an earlier thread on this list (which is where I learned about the existence of that clear rule): http://mail-archives.apache.org/mod_mbox/incubator-general/200909.mbox/%3cf767f0600909090615t6582bfd1m36e4d8abe1392...@mail.gmail.com%3e Thanks for the link to the information. However, I would like to get a consensus to make sure that we should not be attributing SLF4J at all. In an artifact that does not contain SLF4J (like your source distro), do not attribute (at all). In an artifact that does contain SLF4J (like your binary distro), well, see https://issues.apache.org/jira/browse/LEGAL-59 to figure out that no-one is really that sure. If you look at HTTPD, it has the expat license (which is MIT) inside its LICENSE file: http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE but no mention about it in its NOTICE file: http://svn.apache.org/repos/asf/httpd/httpd/trunk/NOTICE Is that ok? Probably. Is that the *only* right way? Not so sure. My personal rule is that when in doubt do what Roy voted +1 on is not a bad strategy when it comes to licensing stuff [2]. which I believe have been used in recent release votes. I'm fine with deleting/re-wording the attributions (afterall, less for us to maintain) and hope not too troublesome but I would like some consensus to make sure that this and future releases are right (without quotes ;-) ). Please note, I didn't actually vote on the release, I just pointed out a few things that probably ought to change. I didn't vote because I don't want to go and review all those very many binaries (or the build process that creates them) and I'm not familiar enough with the codebase to somehow know that all those binaries are somehow ok. If I had thought these minor tidbits that I raise are enough to actually vote -1, I would've made that clear, sorry that it wasn't. Even if I _did_ vote, releases are majority votes, and 2 +1 beats a single -1. Its just you need 3 votes. In other words, all you need is one more +1 :) ciao, Leo [1] Oh, and for reference, my first encounter with apache licensing policy was when someone had imported the entire codebase of some non-apache project into apache CVS, stripped all the license headers including copyright info, and replaced them with apache ones. We got a polite note from the original projects' owners to fix that pretty please. We got spanked around pretty bad for that one at the following apachecon, and then we all had lots of beer :) [2] there is another rule, have whatever Greg is having, though less of it - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Fri, Nov 6, 2009 at 7:46 PM, Greg Stein gst...@gmail.com wrote: On Fri, Nov 6, 2009 at 14:44, Greg Stein gst...@gmail.com wrote: All of the existing tags/branches of svn use a tweaked Apache Software License, v1.1, and generally have a file header claims a copyright by CollabNet. trunk is licensed under Apache License, v2, and has a file header as defined by the Apache Legal Affairs Committee, though with SVNCorp rather than ASF as the rights-holder to the distribution. After we import the codebase, we intend to tweak all of the file headers on trunk with s/SVNCorp/ASF/. To clarify this further: I believe that a release from *trunk* matches a standard Apache release. Well, at the moment, probably not quite. In particular, the incubator PMC is (in)famous for being very nitpicky (err, careful) about licensing stuff, it's an enlightening experience to go through I would say. You might want to have some fun with RAT: http://incubator.apache.org/rat/ It finds things like this: * No license header (some examples): ./subversion/bindings/swig/ruby/svn/core.rb ./tools/bdb/svnfs.py ./tools/client-side/server-version.py * GPL license header (I understand why, but, ugh): ./build/config.guess (and some 600 other complaints most of which are readily ignorable). The various tools and scripts that say stuff like released under the same license as subversion could probably do with a little attention as well. AIUI it from reading dist.sh those files would go into the released tarball (I didn't attempt to actually run dist.sh, that'd take me too much time to try and do properly). Oh and according to what I read the other day on legal-disc...@a.o the reference to the license details about the python bindings probably ought to belong in the LICENSE file not in the NOTICE file. On Sat, Nov 7, 2009 at 12:07 AM, Greg Stein gst...@gmail.com wrote: We're not ready for an alpha, but we could do an internal experimental release. I seem to recall seeing that in the docs. How about that? Sure :) ciao, Leo PS: +1 to start incubation obviously. The record is 2 weeks set for MerlinDeveloper back in 2003...you have 9 days left to try and beat it :) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release cassandra 0.4.2
+1, nice work folks! cheers, Leo On Fri, Nov 6, 2009 at 5:37 PM, Eric Evans eev...@rackspace.com wrote: The Cassandra community voted on and approved the release of Apache Cassandra 0.4.2. We would now like to request the approval of the Incubator PMC for this release. Cassandra is a massively scalable, eventually consistent, distributed, structured key-value store. Podling vote thread: http://www.mail-archive.com/cassandra-...@incubator.apache.org/msg01036.html 0.4.2 artifacts: http://people.apache.org/~eevans SVN tag: https://svn.apache.org/repos/asf/incubator/cassandra/tags/cassandra-0.4.2 Project home: http://incubator.apache.org/cassandra/ Incubation status: http://incubator.apache.org/projects/cassandra.html Note: We've already received two binding +1s during the poddling release vote[1][2]. The vote will remain open for 72 hours (or longer if needed). Regards, [1] http://article.gmane.org/gmane.comp.db.cassandra.devel/505 [2] http://article.gmane.org/gmane.comp.db.cassandra.devel/501 -- Eric Evans eev...@rackspace.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Wink 1.0 (RC-5)
+1 from me! cheers, Leo On Thu, Nov 5, 2009 at 3:53 PM, Nicholas Gallardo nickgalla...@yahoo.com wrote: The Wink community has voted on and approved the release of Wink 1.0 (RC-5). We would now like to request the approval of the Incubator PMC for this release. Details of the Wink community vote can be found here: http://n2.nabble.com/VOTE-Release-Wink-1-0-RC-5-td3936613.html#a3936613 The Maven staging area is at: https://repository.apache.org/content/repositories/orgapachewink-011/ The distributions are in: https://repository.apache.org/content/repositories/orgapachewink-011/org/apache/wink/apache-wink/1.0-incubating/ This release is tagged at: https://svn.apache.org/repos/asf/incubator/wink/tags/wink-1.0-incubating/ (revision 832289) The vote will be open here for at least 72 hours. Regards, -Nick - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Mon, Nov 9, 2009 at 2:26 AM, Niclas Hedhman nic...@hedhman.org wrote: On Mon, Nov 9, 2009 at 7:39 AM, Leo Simons m...@leosimons.com wrote: PS: +1 to start incubation obviously. The record is 2 weeks set for MerlinDeveloper back in 2003...you have 9 days left to try and beat it Hey, you snipped the smiley! I'm going to stubbornly add it back in: :) Smileys matter :) Now, I intended to convey perhaps a few things: * I wouldn't mind at all seeing svn graduate a few weeks after it starts incubation * there is even reasonable precedent for that kind of speed * this is not really a very important topic, its a P.S. at most Obviously I have to work on my communication skills, since it seems like you read this as something completely different. snip rant/ I am ashamed of us... I have no idea what might be going on in your head, but from where I sit, it seems like you might be overreacting just a _bit_ to a tongue-in-cheek e-mail post script. Have some green tea. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
On Mon, Nov 9, 2009 at 1:25 AM, Greg Stein gst...@gmail.com wrote: The Apache Incubator is about EDUCATION. It is about TEACHING podlings how to work here at Apache. So what are you teaching with e-mails like this, Greg? When you disagree with someone, SHOUT a bit and write a long rant? Or perhaps that using an argument based on authority is a good strategy? Not very good lessons either. Please kindly step off the soap box... Thanks, Leo PS: For the record I do agree that its not really necessary for subversion to do an incubation release. I like to think that kind of stuff is a judgement call for the mentors. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Wink 1.0 (RC-5)
On Mon, Nov 9, 2009 at 2:23 PM, Nicholas L Gallardo nlgal...@us.ibm.com wrote: Thanks Leo, your input is much appreciated. In addition to this +1, we received a +1 from Kevan Miller in the Wink community vote. Is that vote transportable here? If so, then we just need one more +1 to release as the vote has already been open for 72 hours. Yeah that's fine, basically you need: * at least 3 binding +1s (i.e. binding = from PMC members) * more binding +1s than -1s * enough time for people to evaluate the release and vote (72 hours is just a custom rather than a hard rule, i.e. its nice to take into account weekends and holidays) I see Ant just voted, so you're done. cheers! Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)
On Mon, Nov 9, 2009 at 2:15 PM, Justin Erenkrantz jus...@erenkrantz.com wrote: To be clear, it's on the mentors to decide what is applicable and necessary for graduation - not the IPMC as a whole. The IPMC as a whole has only two roles: approving a proposal and recommending graduation Also, to be clear, as an IPMC member I spend quite a bit of time with projects where I am not a mentor, casting (binding) votes on things like their releases. I will continue to do that, inline with procedure and policy and common sense. I'm pretty sure you're not really meaning to question that :) I believe it's reasonable to ask for the trust that goes with ensuring that we'll be sure to keep Subversion in line with Apache practices and procedures - and we will continue to do so long after the Incubator has recommended Subversion for graduation. =) You have it! cheers, Leo PS: Just make sure to keep close tabs on the bearded Slovenian ;-) PPS: for clarity, that was yet another attempt at a bad joke in a post script - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
On Mon, Nov 9, 2009 at 3:24 PM, Justin Erenkrantz jus...@erenkrantz.com wrote: On Mon, Nov 9, 2009 at 4:03 PM, Leo Simons m...@leosimons.com wrote: Also, to be clear, as an IPMC member I spend quite a bit of time with projects where I am not a mentor, casting (binding) votes on things like their releases. I will continue to do that, inline with procedure and policy and common sense. I'm pretty sure you're not really meaning to question that :) This is where I think the Incubator has gone awry: the claim that you are an IPMC member implies that you have merit on a project (in the form of a binding vote) is false. Not merit, just binding vote. I agree that it sucks, but it is not something where the incubator has gone awry, it has _always_ been messed up like this. Here's what I understand: 1) Apache rule: all apache releases must be made by PMCs 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s 3) from #1 and #2 it follows that all incubator releases must be made by the incubator PMC 4) a lot of incubating projects have difficulty getting enough +1s, or even any qualified help sorting out releases 5) from #3 and #4 it follows that a lot of incubating projects get stuck 6) since #5 sucks rather badly, I and many others try and fill this gap so projects can do some releases, attract some attention, gain critical mass, and get out of here 7) we have further optimized by making the incubator PMC very very large and by making it really easy (for ASF members) to get on the incubator PMC, creating a large pool of potential voters. If you see a way to fix this mess, please do. I suspect rule #1 is the whopper that is just quite hard to get around and from it follows a lot of other mess. I don't know exactly where that rule comes from, but it is very old and it has always seemed very solid, too. IANAL. ciao, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
On Mon, Nov 9, 2009 at 4:48 PM, Greg Stein gst...@gmail.com wrote: On Mon, Nov 9, 2009 at 11:16, Leo Simons m...@leosimons.com wrote: ... Not merit, just binding vote. I agree that it sucks, but it is not something where the incubator has gone awry, it has _always_ been messed up like this. Here's what I understand: 1) Apache rule: all apache releases must be made by PMCs 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s I think those -1s are more where Justin in concerned, rather than a bunch of IPMC people jumping in with *support*, providing a +1 where a podling doesn't have enough active IPMC members. It's the *negative* support -- the hurdles and process and checklists, some of which make zero sense for the particular podling. These can be just as bad as a bunch of people jumping in with -1 votes. Yes, it is really bad. But in some cases, what is the alternative? Given this situation: *) project has rolled a release and voted on it (+1s everywhere, yay, cool stuff!) *) one mentor has voted +1 (well done folks) *) wait for other mentors, no response *) the project comes to the general@ list to ask for additional votes *) I look at the release candidate, and I find a reasonably serious problem (usually legal crap, for example, let's say it ships LGPL code) What would you expect me to do at that point? This is a pretty common situation, and it sucks to be in it, for everyone. Some options: 1) don't say anything, let someone else deal with it 2) explain the problem, don't vote. This typically results in the vote stalling (because no-one else is going to vote +1 after I've pointed out the problem). 3) explain the problem, vote -1. This typically is enough to kill the vote (because no-one else is going to vote +1 after I voted -1). 4) don't say anything, vote +1, claim ignorance later if someone points out the problems. 5) explain the problem, vote +1, ask that the project fixes it later (but can't claim ignorance...). a) one of the above, and also go poke the AWOL mentors for not doing their part (usually followed by mentor resigning, or staying AWOL) I would like to have option #5 be a realistic option, but it requires that I have some ability to do a legal risk assessment (and a brief to take those risks), which I don't. So usually I go for #2 or #3. That's not me being a pencil-licking process-loving bureaucrat, it is me trying to make the best of a messed-up situation. I can try very hard to write my e-mails nicely (and I do), but usually at this point in the time the EDUCATION is just not well-received because it is tied to NOT ALLOWING THE RELEASE. There is no carrot, just a stick. I don't know what Justin was talking about, but I will bet you that a significant part of the friction that incubating projects experience is due to some variant of the above scenario [1]. Can you think of a way to fix the mess? cheers, Leo [1] That, and AWOL mentors - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Side Discussion; Mentorship [PROPOSAL][VOTE] Subversion
On Tue, Nov 10, 2009 at 8:23 AM, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Greg Stein wrote: Sponsors * Champion: Greg Stein Cool * Nominated Mentors: Justin Erenkrantz, Greg Stein, Sander Striker, Daniel Rall Once again, caution against committers == mentors (== 'project leads'). It puts certain committers above others, an inequitable situation. But it has the huge advantage of making sure that the mentors are actively engaged all the time, know quite a lot about the podling's situation, and are already well-known and trusted by the project's community. I would say the very clear benefits far outweigh the potential problems, and I prefer the model like that. Most communities have situations where certain people have more power than others whether officially or in practice, and communities that can't deal with that have other issues. In any case, a good way to offset any perceived risk is probably to have some lively discussion between the mentors and the rest of the incubator. So, risk mitigated, I say :) ciao, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity (of the release process)
On Tue, Nov 10, 2009 at 4:05 PM, Greg Stein gst...@gmail.com wrote: On Tue, Nov 10, 2009 at 04:07, William A. Rowe, Jr. wr...@rowe-clan.net wrote: Leo Simons wrote: Here's what I understand: 1) Apache rule: all apache releases must be made by PMCs 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s 3) from #1 and #2 it follows that all incubator releases must be made by the incubator PMC If you see a way to fix this mess, please do. I suspect rule #1 is the whopper that is just quite hard to get around and from it follows a lot of other mess. I don't know exactly where that rule comes from, but it is very old and it has always seemed very solid, too. IANAL. Mechanically, it's possible to recharter Incubator PMC as a board committee which has the authority to assemble and dissolve fully empowered PPMCs so they could begin binding votes from the outset. The 'P' would change from 'pre' to 'provisional'. I don't know if this is what we want to do, or not. The Board is trying to move away from Board committees. The IPMC is in charge of its operation. It can redefine the rules of releases as it pleases. The three +1 rule was developed to show that the PMC is in charge of the release, and is therefore legally liable for it. The IPMC can do whatever it likes around releases, as long as that process specifically claims or disclaims liability. Ok, that is interesting (and probably more workable than a big reorg). I still think we should claim liability. Could we, for example, have a release process that is lazy-by-default from the IPMC side and still claim that the ASF gets liability? for example, to release: 1) PPMC must vote for the release according to their rules (which should at least match the 3 +1 / majority rule requirements) 2) at least one PMC member must vote +1 (usually the mentor) 3) if there are no -1 votes, the PPMC sends the general@ list a request for a release ACK, after they get that ACK from a PMC member, they wait for 72 hours, and if there are still no -1s, the release is approved. 4) if there are any -1 votes, then the rule becomes the normal 3 +1s from PMC members / majority Downside: * more complex * increased dependency on single person to teach the basics Upside: * better reflects relationship between incubator and PPMC * more responsibility for project * hopefully fewer stalled releases thoughts? Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Wed, Nov 11, 2009 at 5:20 PM, Matthieu Riou matth...@offthelip.org wrote: On Wed, Nov 11, 2009 at 8:31 AM, Daniel Kulp dk...@apache.org wrote: As Martijn alluded to, I think we'd need some more context as to why and how they use RTC. Yes, sorry for the lack of details. The context is Cassandra and they're doing RTC by community choice. They all seem to agree that RTC is the best for their own codebase given that some parts of it can be pretty tricky. And even committers who aren't too big on RTC generally speaking seem to agree that it's working well for them (see [1] for the whole thread, including Paul's objection). So it really seems to be community driven. Thank for the inputs. Cassandra does about the same thing as hadoop right, where patches go into jira for an explicit +1? While I think that's rather painful (if *I* were to do RTC I would definitely want to manage it within SVN perhaps with the aid of svnmerge.py), I don't think it is _wrong_. If the community really wants to do it that way, I say let them. Sorry Paul :) cheers, Leo PS: for the record I've followed cassandra on and off and I would most likely +1 on a graduation vote. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Two other issues to discuss for Subversion
On Tue, Nov 10, 2009 at 7:27 PM, Greg Stein gst...@gmail.com wrote: There are two other issues to discuss for the Subversion podling: * moving the mailing lists directly to @subversion.apache.org * placing the source code at /subversion/ rather than /incubator/subversion/ We are hoping to minimize overall disruption to the community with a move to incubator space, then a move to apache space. I think a good thing we started here is to dig back in memory to find the core reasons why the process is what it is and make sure we stick to what's important. I think we have two main reasons to have the incubator name in most those places normally: 1) make clear to users what the status of a project is, i.e. where incubation is implying that a project may not become an apache project or that it may not be quite safe legally yet or it may not have a healthy community behind it or we don't have the trademarks yet or whatever 2) protect the apache brand (you know...if an incubating project goes up in flames, well, that's ok, we told you that might happen) 3) make it easier to keep a tight leash on PR I would argue we are not very worried about subversion being unsafe for use by the general public :-). Similarly, the main thing that would hurt our brand is if the subversion community would decide to cancel the incubation process (because apache really sucks, you know...). The most important thing these days is probably clear messaging on the relevant website(s). So, as long as y'all make sure to do that good stuff (be clear to users and protect the involved brands), I think what infrastructure goes where exactly, can be up to infra@, in this case. And y'all are talking to PRC anyway about any press stuff. I see no real risks. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Discussion] Graduation of Pivot Podling
Hey hey, I've checked in on Pivot now and again and reviewing recent activities, I think its definitely ready to leave the nest! I will be happy to vote +1 when it comes to a vote. cheers, Leo On Mon, Nov 16, 2009 at 3:10 AM, Todd Volkert tvolk...@gmail.com wrote: The feeling among the members of the Pivot podling (mentors included) is that it is ready for graduation. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduation of Apache Pivot
On Tue, Nov 17, 2009 at 5:47 PM, Todd Volkert tvolk...@gmail.com wrote: The Apache Pivot community feels that it is ready to graduate into the Apache Pivot top-level project. +1 from me! cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
On Wed, Nov 18, 2009 at 4:40 AM, Niclas Hedhman nic...@hedhman.org wrote: On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz jus...@erenkrantz.com wrote: As Hyrum suggests, we can use org.apache.subversion.* if we want to create a new (better) Java interface within our versioning rules - but that isn't necessary nor should it be a pre-req for graduation. IMNSHO, either Subversion address this issue pre-graduation, OR we remove the package name change requirement for ALL incubating projects, leaving it up to the project post-graduation to address it. Any reference to this being a requirement? I looked for it the other day but didn't find anything. If its not documented rule it is not a rule. It has been a contentious issue in the past, and will be so in the future, and I am not going to defend ASF's position if it doesn't apply to everyone. I would actually like to hear from more Java-centric developers of Board and IPMC what they think about this... I wouldn't say I'm java-centric but I do a lot of it :) I think package renaming is in many cases required for branding or trademark reasons (which goes both ways -- org.apache.java.framework was an issue once, com.google.httpd would be today, but on the upside import org.apache may make people feel nice and cosy, too). I think sf.net.foo or org.tigris.foo is not that big an issue to keep (for a while), if there's good enough reasons (like api compatibility for an established codebase). Beyond that, I personally think the java standards for package naming are really a mixed blessing, and if a project wanted to break them (say subversion decided to go with subversion.stuff instead of org.apache.subversion.stuff), fine, good luck to them. Regardless of the stupidity of the rules (or the stupidity of breaking the rules), we as incubator should really not even try to enforce these kinds of standards; projects should make their own decisions about that. ciao, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] release Apache VCL 2.1
Hey hey, On Wed, Nov 18, 2009 at 8:42 PM, Josh Thompson josh_thomp...@ncsu.edu wrote: The Apache VCL community voted on and approved a proposal to release Apache VCL 2.1. We would like to request the endorsement of the Incubator PMC to publish this release. The release artifact, sums, and GPG signature can be found here: http://people.apache.org/~jfthomps/apache-VCL-2.1-RC2-incubating/ 1) Basic package looks good to me, though I didn't try to install or run it. I checked RAT and checksums and read the various instructions. 2) The licensing situation looks 'interesting' - you have a few GPLed dependencies like MySQL and mcrypt and Nmap without which I imagine the product doesn't work. I would like to see VCL run on a non-GPL database and be ensured that it can function without other viral-licensed components as hard dependencies, some time before graduation (I think its ok to release, as long as some kind of plan is in place). 3) There is no website yet? You really have to do a basic homepage over at http://incubator.apache.org/vcl/, for example so that you can point people at mirrors (see http://www.apache.org/dev/#mirror about the mirroring system). 4) Since this is PHP code I did a cursory code review for SQL injection / XSS / etc. It seems like that's had some attention, but at a glance maybe its not quite perfect? For example checkAccess() in utils.php: $xmlpass = $_SERVER['HTTP_X_PASS']; if(get_magic_quotes_gpc()) $xmlpass = stripslashes($xmlpass); where $xmlpass is used moments later to execute SQL: $query = SELECT x.id . FROM xmlrpcKey x, . user u . WHERE x.ownerid = u.id AND . u.unityid = '$xmluser' AND . x.key = '$xmlpass' AND . x.active = 1; Another piece of suspect code would be in submitLogin() in authentication.php which does not appear to validate the $_POST['password']. I'm by no means a PHP expert so I might be making a fool of myself here, but better safe than sorry. So, can you explain (preferably on, err, your website) what measures are in place to guard against things like SQL injection and XSS? thanks, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question for mentors: crediting the original project?
On Tue, Dec 1, 2009 at 11:02 AM, Ross Gardler ross.gard...@googlemail.com wrote: 2009/12/1 Scott Wilson scott.bradley.wil...@gmail.com: On http://incubator.apache.org/wookie/ is it possible to add somewhere that the original development was funded by the European Commission through the TENCompetence Project? I see no reason why this should not be allowed. Agreed! If the project feels its appropriate to do something like that, it's quite ok. One particularly relevant example I can think of is HTTPD crediting NCSA [1], so we have in fact a lng tradition of doing this kind of thing :) please add the link as a nofollow to avoid upsetting any sponsors (who only have nofollow links). Yep. Other kinds of foreign branding like an external project logo are probably also best avoided. One reason why others don't credit the original source of the code is that it might give an impression that company X owns the code and thus impacts the impartiality of the project. However, given that, in this case, we are talking about public funding in the EU I don't see that as an issue here. Hmm, I would actually not be that worried either if it was a company credit. As long as such statements are (a) true and (b) they don't interfere with sponsoring efforts. I think what's most important is to stick to facts and provide relevant information to users and (potential) contributors. I think a project's origin is relevant (though it probably becomes less relevant over time). cheers, Leo [1] http://svn.apache.org/repos/asf/httpd/httpd/trunk/ABOUT_APACHE - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
How documentation != code, and how to do policy (was: Re: Publishing api docs for Subversion)
Hey hey, I wasn't going to say anything but since this is dragging on... On Sat, Dec 5, 2009 at 1:08 AM, Doug Cutting cutt...@apache.org wrote: Would we permit someone to mirror other files from trunk on the website? Yes, definitely. Most projects publish their websites by pushing files into SVN. Many projects automate this - commit an xml file, its turned into html and published online. That is in fact the encouraged process, though we do allow other mechanisms (like a plugin which takes confluence content and pushes that out automatically). What's special about documentation? Less legal risk, less risk that anyone puts a bug in docs that crashes a users computer or corrupts their data or takes down the internet, generally not subject to patent concern, less desire for the general public to fork and redistribute, and much more. Like, barriers to working on it have to be as low as possible or no-one will do it, people inclined to work on docs are often less technical, etc etc. Perhaps it helps to flip the question around: what is special about (source) code? And the answer is: lots :) its changes are subject to vetos, etc. Not on most of the projects I work on! Most projects use lazy consensus for documentation. I don't think I have *ever* seen someone veto a documentation patch. snip/ It's otherwise treated just like code. Well, in some ways (that you pointed out) docs are treated a lot like code, and in many other ways they aren't. Publication release are two different things - thats the point. I don't see that yet. Can you tell me more about the difference? I use publish, distribute and release more or less synonymously when referring to project content. I'd say we don't really have precise definitions that will provide you with a model explaining exactly what is and isn't ok in the general case, and I think it won't help to look for it either. Instead, judgement should be applied to the specific case. Subversion contains only working drafts. And stable branches and release tags and documentation and websites and quickbooks and contact info and meeting minutes and ... We use subversion for nearly everything that needs to be auditable and be backed up and be collaboratively edited. We don't always particularly care about the versioning bit :) But, for the sake of illustration, let's do a mental exercise. The ASF does creation and distribution of software to the general public. When we say software we mostly mean source code (and some binaries for convenience). Pretty much everything around here is structured to support this creation and distribution of software. There's a variety of supporting things, like websites, incubators, an org structure, various committees, conferences, etc. All of it supports creation and distribution of our software. What constitutes the software that a project releases to the public depends on that project. Subversion is one project, it has a website and it creates software which it distributes. Subversion releases a single tarball of (mostly C) source code with some build scripts and whatnot. Running the build produces an apache module, a server program, a client program and some utilities. Subversion's users then install this software on their system and use it. Most subversion users probably get a pre-built binary from a third party. The subversion project provides a manual for how to install and use svn on its website, but I suspect most users will actually use the svn book. There is a relatively small side activity for subversion which involves using its libraries and APIs to build custom client software that interacts with a subversion server (or perhaps even extend the server though I think very few people do that). For this activity, you need the API docs we're talking about here. Of course, the subversion developers themselves need those API docs too. It's a fair assumption that the expert developer people using these API docs know *quite a lot* about subversion already, including about its versioning and compatibility policies, how to download releases and code out of svn, etc etc. It's also a fair assumption that the most important API to develop against is in fact the SVN trunk API. So, subversion publishes their trunk API docs nightly, for the convenience of their own developers and the surrounding tool developer community. All those people mostly want trunk API docs, and they want them mostly so they don't have to run doxygen themselves. There's really no need to protect the normal users of the subversion website from bad API docs, they won't be using those docs at all. Now, the point of this long story: subversion as a community has thought about all this and are evidently doing a pretty good job at keeping users and wider developer community (well perhaps not the java dev community who are afraid of native code :-D ) happy. Within all this context, one of the subversion developers (or this I assume) asked a
Re: OSS Java AAC Decoder?
On Mon, Dec 7, 2009 at 3:41 PM, Branko Čibej br...@xbc.nu wrote: Todd Volkert wrote: Does anyone on this list know of an existing open source pure-Java Advanced Audio Coding (AAC) library? If not, are there any audiophiles on this list that would be interested in incubating such a project with me? :) Do you know of any barriers to such a project (like performance of a pure-Java library being a problem given the complexity of the encoding)? I wouldn't know about the performance of Java in general, but certainly AAC(+) encoding isn't trivial. Decoding is somewhat easier, as usual. However, the whole idea is probably quite a bit problematic, because AAC coding, streaming and playback are subject to a ton of patents and MPEG-LA licensing. I wouldn't know how that fits withtin the ASF, but I'd imagine it's edge-case at best. Yup, I'm pretty sure it won't fit well at all with our (C)CLA -- to learn a bit more about the problems of AAC and such as combined with open source, try and look for google chrome (which, IIRC, includes a version of ffmpeg) topics on the subject -- (again) IIRC google pretty specifically (sub)licenses or will sublicense a bunch of those patents to chrome users and re-distributors which I imagine was a rather huge can of worms for them to accomplish. I can't find it now, but I could swear Chris DiBona actually did a bunch of e-mails about such a topic together with one of google's laywers. It might be worth getting in touch with them... ...also it seems like java is actually quite fine for encoding/decoding of low-level high-bandwidth things like audio and video, as long as you stay away from java.util.* and other high-level stuff like that and you tune your GC appropriately :) ciao, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: How documentation != code, and how to do policy (was: Re: Publishing api docs for Subversion)
On Tue, Dec 8, 2009 at 5:16 AM, Niclas Hedhman nic...@hedhman.org wrote: this is also the case for Nightly Builds, accessible by the public; Legally they are publishing to the public (i.e. opposite of 'for private use') and bound by licenses and agreements. And finally, from Copyright law perspective, you are right that code and text is effectively the same thing, but that code has a common tendency to be depending on other work, introducing licensing into the legal mix. I think it was Leo who also pointed out that Trademarks is an additional legal aspect of it. I have no idea what it you mean exactly, but I'm pretty sure I said nothing about nightly builds and I said nothing about trademarks. Here's some of what was said just a few e-mails back: Doug: What's special about documentation? Leo: (...) Less legal risk (...), generally not subject to patent concern which I probably should not have said since I didn't back it up with a reasonable reference. Sorry about that. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation
On 12/11/09 1:14 AM, Donald Woods wrote: I would like to present an incubator proposal for a new Validation podling, which would be a JSR-303 Bean Validation follow-on to the existing Apache Commons Validation 1.x project, but based on a new incoming codebase with a software grant from Agimatec GmbH. The proposal is available on the wiki at: http://wiki.apache.org/incubator/ValidationProposal The proposal looks fine on paper, but I'll agree with some of the other comments that it seems a bit silly to incubate this as a disjoint project. If you have 3 capable and able mentors *and* a whole bunch of people that are already committers, why can't they mentor your one or two new committers while those people are constrained to their specific sandbox, and avoid tons of bureaucracy and overhead? I have no real idea why anyone would think that doing incubation looks like it'll have a better chance of success in this case. Put another way - what does doing incubation buy you, and why is it seen as a better option? Can you please reconsider and see if you can do this as an ip clearance only? If it helps I can hop on a mailing list and object to some objections? :-D ciao... - Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)
Heya OpenCMIS folks, Since it looks like you aren't currently supported by a champion or mentor [1], I thought I'd fill in a small part and inject some warm fuzzies... *Thanks* for open sourcing your project and *thanks* for considering doing it at apache. Its always a lot of effort to go through this kind of public vetting and I'm sure the wider CMIS community will somehow benefit from you taking the time. Though it may look like you're not really receiving the warm welcome you perhaps expected, this kind of discussion is quite normal when people (engineery types especially!) are excited about a topic...in some ways the only warm welcome we do is the hot welcome :) So even if it doesn't feel that way, having this boatload of discussion is actually sort of good news -- you have sparked lots of interest and people are looking carefully at your proposal, Jukka's even looking at all the code in detail, that doesn't always happen ;) It looks like you're doing a good job keeping it cool and answering questions. I'm sure there's a couple of days more work ahead to sort out what looks like a pretty complex discussion about the relationship between OpenCMIS and Chemistry. Keep at it! cheers, Leo [1] no, you really don't want me as a mentor [2], so don't ask :) [2] because I would offer you an opinion or two about CMIS and it'd all end in tears... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
The incubator is here to help projects
Hey folks, The incubator is here to help. It is about education. It is about teaching podlings how to work here at apache, about showing people what to be aware of. The incubator is *not* here to assess or judge or dictate or lecture or draft policy or go on long rants about The One True Way To Do X or to have a Long Argument About Whether Anyone Did Anything Wrong. What not to do is important: the best way to learn is to learn by doing, and by doing something fun, and all this other stuff really gets in the way. When addressing a (potential) project or discussing it here on general@, please do take care to always get off your soap box first, and please always remember you are here to help them. If what you're going to say about a project won't help anyone, please do reconsider sending that e-mail. Just a friendly reminder... thanks for reading! Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Apache Shindig as an Apache Top Level Project
On 1/14/10 11:41 AM, Vincent Siveton wrote: I would like to start an official vote to recommend the graduation of Apache Shindig as a Top Level Project to the Board. +1! - Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Discussion: graduating Subversion
On 1/26/10 6:00 AM, Niclas Hedhman wrote: On Tue, Jan 26, 2010 at 4:49 AM, Greg Steingst...@gmail.com wrote: Before calling for a vote to graduate Subversion, I figured it prudent to have a discussion first. I believe Subversion is quite ready (and has been, but the holidays and whatnot kept me from sending this earlier). Any thoughts on why Subversion should NOT graduate now? I want to see a graduation. Motivation; Incubator is about fostering the community, and I don't think that the Incubator can provide anything additional from the Apache folks already present in the Subversion community. Anything else sounds like bureaucracy for the sake of it, to me... Talking about bureaucracy, comparing http://incubator.apache.org/projects/subversion.html and http://wiki.apache.org/incubator/January2010 looks like the status file is not quite up to date. I'm assuming the question of graduation being asked means that all 'em boxes should in fact have been ticked by now. If so I say tick 'em and vote :) cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Subversion podling for graduation
+1 - Leo On 2/12/10 4:08 AM, Greg Stein wrote: Hello all, I started a discussion thread a week-ish ago to seek out issues for Subversion's graduation. The couple bits that were raised[1] have been handled, I believe. So with that said, I am unaware of any potential showstoppers, and would like to request a vote for graduating the Subversion podling. Should this result in a successful vote, I will put a resolution before the Board (for its Feb 17 mtg) to construct a new Subversion PMC. Please vote: [ ] +1 Graduation [ ] -1 Hold, and continue incubating Thanks! Cheers, -g [1] incubator status page, and java bindings package name - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Zeta Components - Further comments?
On 4/22/10 10:21 AM, Tobias Schlitt wrote: I updated the proposal to reflect the objections regarding the infrastructure. Our questions regarding the import of our SVN history has been cleared. Are there further comments, suggestions, objections? Very nicely written proposal, well done! Looks like an interesting project to bring into the apache fold - some more PHP sounds like a good idea :) It looks like you now need to sign up some mentors after which your proposal would be ready for a vote. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Whirr Project
On 4/15/10 10:42 PM, Tom White wrote: I would like to propose Whirr as an incubator proposal. Whirr will be a set of libraries for running cloud services, such as Hadoop or Cassandra. The initial code (for Hadoop) is hosted as a Hadoop contrib module, but I believe it would flourish as its own project with its own community. The proposal is on the incubator wiki at http://wiki.apache.org/incubator/WhirrProposal. ...and pasted inline below (as is customary). The proposal looks fine to me. Like you mention your initial group of committers is a bit small which is a risk but hey, cloud is hot, go build community :) You do know any ASF member can sign up to be an incubator mentor, right? If I count correctly you have two on your list :) cheers, Leo -- = Whirr, a library of cloud services = == Abstract == Whirr will be a set of libraries for running cloud services. == Proposal == Whirr will provide code for running a variety of software services on cloud infrastructure. It will provide bindings in several languages (e.g. Python and Java) for popular cloud providers to make it easy to start and stop services like Hadoop clusters. The project will not be limited to a particular set of services, rather it will be expected that a range of services are developed, as determined by the project contributors. Possible services include Hadoop, HBase, !ZooKeeper, Cassandra. == Background == The ability to run services on cloud providers is very useful, particularly for proofs of concept, testing, and also ad hoc production work. Bringing up clusters in the cloud is non-trivial, since careful choreography is required. (Designing an interface that is convenient as well as secure is also a challenge in a cloud context.) Making services that runs on a variety of cloud providers is harder, even with the availability of libraries like libcloud and jclouds, since each platform's quirks and extra features must be considered (and either worked around, or possibly taken advantage of, as appropriate) . Whirr will facilitate sharing of best practices, both for a particular service (such as Hadoop configuration on a particular provider), and for common cloud operations (such as installation of dependencies across cloud providers). It will provide a space to share good configurations and will encode service-specific knowledge. == Rationale == There are already scripts in the Hadoop project that allow users to run Hadoop clusters on Amazon EC2 and other cloud providers. While users have found these scripts useful, their current home as a Hadoop Common contrib project has the following limitations: * Tying the scripts' release cycle to Hadoop's means that it is difficult to distribute updates to the scripts which are changing fast (new features and bugfixes). * The scripts support multiple versions of Hadoop, so it makes more sense to distribute them separately from Hadoop itself. * They are general: people want to contribute code for non-Hadoop services like Cassandra (for example: http://github.com/johanoskarsson/cassandra-ec2). * Having a uniform approach to running services in the cloud, hosted in one project, makes launching sets of complementary services easier for the user. Today, the scripts and libraries hosted within each project (e.g. in Hadoop, HBase, Cassandra) have slightly different conventions and semantics, and are likely to diverge over time. Building a community around cloud infrastructure services will help enforce a common approach to running services in the cloud. == Initial Goals == * Provide a new home for the existing Hadoop cloud scripts. * Add more services (e.g. HBase) * Develop Java libraries for Hadoop clusters * Add new cloud providers by taking advantage of libcloud and jclouds. * (Future) Run on own hardware, so users can take advantage of the same interface to control services running locally or in the cloud. == Current Status == === Meritocracy === The Hadoop scripts were originally created by Tom White, and have had a substantial number of contributions from members of the Hadoop community. By becoming its own project, significant contributors to Whirr would become committers, and allow the project to grow. === Community === The community interested in cloud service infrastructure is currently spread across many smaller projects, and one of the main goals of this project is to build a vibrant community to share best practices and build common infrastructure. For example, this project would provide a home to facilitate collaboration between the groups of Hadoop and HBase developers who are building cloud services. === Core developers === Tom White wrote most of the original code and is familiar with open source and Apache-style development, being a Hadoop committer and an ASF member. There have been a number of contributors who have provided patches to these scripts over time. Andrew Purtell who created the HBase cloud
Re: [VOTE] Accept Jena into the incubator
+1 obviously! - Leo On Sun, Nov 21, 2010 at 5:49 PM, Benson Margulies bimargul...@gmail.com wrote: +1 binding On Fri, Nov 19, 2010 at 10:17 PM, Niclas Hedhman nic...@hedhman.org wrote: Lacking a lot of binding votes... +1 binding On Wed, Nov 17, 2010 at 9:10 PM, Ross Gardler rgard...@apache.org 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 Accept Jena for incubation [ ] +0 Don't care [ ] -1 Reject for the following reason: The vote is open for at least 72 hours. Thanks, Ross - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Clarification about SGA versus CCLA
Hey folks, On Sat, Nov 27, 2010 at 4:34 AM, Craig L Russell craig.russ...@oracle.com wrote: I think of a CCLA as a combination of an SGA to cover the software grant plus an acknowledgement that people in the company are going to work on Apache projects, whether on their own time or company time. So, if a CCLA is filed naming the software, a separate SGA is *not* necessary. I always worry when we short-circuit the details like this: the opportunity for misunderstandings is there :) If and only if you fill out schedule B of a CCLA, then the CCLA also is a software grant as well as an agreement for ongoing contributions. Corollary - if as part of incubation a company sends in a CCLA *without* actually filling out schedule B, then importing a large body of existing code on which that company claims rights could be a bad idea. I don't think we should spend too much time over-documenting how to actually use these documents -- in the end the documents themselves are pretty clear. cheerio! Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: I think individuals need SGAs
Hey hey, I definitely understand the reasoning. Hmm. I think the way to look at it is, it depends, but do whatever is needed to allow apache liberal rights to sublicense all the IP to it's users. The second way to look at it is that logic and legal stuff are not always as closely connected as you might think...so I think this really is something to run by legal-discuss / whoever designed the process (Roy?), people like me just regurgitate what they learned before :) cheerio, Leo On Dec 1, 2010, at 10:15 PM, Benson Margulies bimargul...@gmail.com wrote: I've been thinking about Leo's email of the other day, and I think that my edit to the mentor page is not right and some guidance I've delivered to podlings is not right. I'd like to float my logic here and see how it gets shot at. As Leo pointed out, the CCLA has a specific section for granting rights to pre-existing IP. The ICLA does not. It has no schedule. It talks about contributions. When we import pre-existing code for a podling, it seems to me that it is dubious to characterize this as an act of 'contribution' by the historical authors, even if they are eagerly anticipating further contributions to the code in the incubator. Therefore, I think that I should edit my edit, and send new advice, to the effect that all historical contributors need to be covered by SGAs. Those could be in the form of SGA schedules or in the form of individual SGAs. --benson - 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: Setting up the Jena podling
On Thu, Dec 2, 2010 at 12:12 PM, Benson Margulies bimargul...@gmail.com wrote: I'm a bit up to my eyes in OpenNLP. Can one of you get the initial status page going? On it. - Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: OpenOffice.org Apache Incubator Proposal: Splitting the Community?
On Fri, Jun 3, 2011 at 7:17 PM, Jim Jagielski j...@jagunet.com wrote: Just remember, we haven't yet even voted on whether or not to accept the podling. These are decisions the podling should be making. Are you ready to call for a vote? :) Whoah! Please don't call for a vote -- I would much rather we first arrive at a situation where I can comfortably vote +1! :) I recognize that all important smiley (note I'm adding smileys too!! (^_^) ), but let's pretend I'm ignoring that, in which case for me the actual answer is something like... * The, err, awkward language in the proposal that was pointed out [1] should be fixed first. * Arguably you need _at least_ 3 mentors first. * There is a ton of information/opinions/plans/background on blogs/twitter/press releases/etc (for example from IBM folks like Rob) that is not quite reflected yet in the proposal, which should change: the proposal should be complete so that you can read it from start to end, have a good idea about everything going on, and cast a vote. * There is a ton of stuff at OpenOffice.org (infrastructure, docs, ...) for which it is unclear what ASF its relation is going to be to it, the proposal is not quite reflecting the reality of what OOo is yet. * You reached out to a bunch of organisations and existing communities and asked them to provide feedback and/or sign up as committers, and we have mostly not seen the response yet. I'm sure many people are still trying to get to grips with what is happening. * There are some conversations going on that seem a bit heated now but also seem pretty resolvable. It seems a good idea to get rid of most of that heat before voting on the next step. * In general I see a couple of very excited people generating a lot of e-mail traffic which means a not so great signal-to-noise ratio (which is normal and fine and such, this is _huge_ for a lot of people :-) ), making it very hard for people that have to vote on a proposal to get a clear hold of the signal. Making having a very clear and complete proposal (perhaps even with FAQ) even more important. (...) I'm not much of a process junkie, but I think the whole idea of OOo coming here also includes following normal apache due diligence processes, which tends to involve slowing things down a bit when they get heated up. I personally completely fail to get excited about office applications (but welcome on board guys! Good luck! :-) ) but you're pretty obviously not done with some of the basics yet. The responsible vote AFAICS right now would be something like -1, seems like a good idea, but the proposal is not finished, so please fix it. cheers! Leo [1] Oracle and ASF agree [broad statement]... IBM as Sponsor ... etc - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
OOo mirroring (was: Re: A little OOo history)
On Tue, Jun 7, 2011 at 6:35 PM, Christian Grobmeier grobme...@gmail.com wrote: 30 downloads per day or per month? 52TB per month is still a lot... per day. Look at this chart: http://marketing.openoffice.org/marketing_bouncer.html TL;DR: these bandwidth numbers are not actually that scary or important -- the OOo infrastructure does not serve up all that traffic, the many mirrors do, and traffic from the OOo infrastructure to the mirrors is very efficient since it efficiently pushes out new releases (with rsync). The big work in mirroring is setting up the process and shepherding the mirroring community. OOo has 118 mirrors. Apache has 294 mirrors. There is significant overlap -- a lot of sites that mirror apache downloads already mirror OOo downloads and vice versa. http://download.services.openoffice.org/mirrors/all.html http://www.apache.org/mirrors/ Note that many of the mirrors of OOo and of apache also mirror large amounts of other open source software. OOo uses mirrorbrain [1]. Apache uses some CGI scripts to accomplish a lot but not all of the same functionality. The set of data ASF pushes to its mirrors is somewhere downwards of 50GB [4]. The set of data OOo pushes is somewhere downwards of 300 GB [2]. It doesn't seem like a good idea to push an additional 300GB to all existing apache mirrors: that isn't quite what they signed up for. As I understand it Oracle wants to transition out of maintaining the OOo infrastructure eventually. So if OOo gets accepted into the incubator, it seems like the smart approach would be to duplicate the existing OOo mirrorbrain installation onto some apache hardware, with the people that look after the OOo and apache mirrors figuring out the specific details. Will be a fair bit of work I imagine so definitely needs volunteers to step up and all that, but nothing particularly scary I think, assuming the existing OOo mirror maintainers [3] help out. Without their help it will be much harder to figure out how to do things! If most of the people that worked on mirroring at OOo are now at TDF (and looking at mail archives it seems that might be true [7]), better be extra nice to them TDF folks :-) Long term, if there's people to do the work, one could imagine updating the custom ASF mirror infrastructure to use mirrorbrain which seems like a cool tool...but that is a _lot_ of work because the existing CGI scripts integrate into the download pages of every apache project. cheers, Leo PS: LibreOffice also uses mirrorbrain [5], having about 65 mirrors. They required only 15GB for a mirror though [6], not the OOo footprint 200GB. Sounds much more reasonable... [1] http://mirrorbrain.org/ [2] http://wiki.services.openoffice.org/wiki/New_OOo_Mirror_Structure http://distribution.openoffice.org/files.html http://wiki.services.openoffice.org/wiki/Mirrors_Project [3] http://openoffice.org/projects/distribution/lists [4] http://www.apache.org/info/how-to-mirror.html [5] http://download.documentfoundation.org/mirrors/all.html http://wiki.documentfoundation.org/Mirrors [6] http://download.documentfoundation.org/mirroring.html [7] http://blog.gmane.org/gmane.comp.documentfoundation.mirrors - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: A little OOo history
On Tue, Jun 7, 2011 at 6:58 PM, robert_w...@us.ibm.com wrote: Since this is a large download, I wonder whether the quoted numbers are impacted at all by timeouts, abandoned downloads attempts, etc. In other words, is it counting the HTTP GET's? Or the successful downloads? That may influence the load by quite a bit. It may even make it worse. It is most likely the number of redirects that the MirrorBrain software makes to download servers. You should take a look at what MirrorBrain does, it's open source, err, free software :) And let's not even get started on the burst traffic when a major new release is announced. Of course, this is not necessarily a problem for Apache. Think of it this way. It would be perfectly possible, and actually quite easy for someone to host the files with a scalable cloud storage provider, e.g., Amazon, and charge $0.99 for the download, the cost of an iPhone app. That is over $30 million/year. Heck, I might just do that myself and retire! In any case, you can see how this problem solves itself given the Apache 2.0 license. You know, there is this large and interesting community of maintainers of mirrors of open source software. A fair share of them are your typical beard stroking [1] uber experienced unix [2] system administrators who maintain a local mirror for their company / campus / ISP mostly so that their local users are served from their local infrastructure, saving on the bandwidth bill of their uplink and keeping their users happy. The art of software mirroring is mostly in making friends with these folks and then staying friendly to them and keeping them happy and well-fed and rsynced. Putting things in the cloud is probably a pretty decent way to piss these people off :-D Incidentally, apache has decent mirroring mostly because it has its own share of beard stroking [1] uber experienced unix [2] administrators. They are typically referred to as the infra team, and they must also be kept happy and well-fed at all times! [3] cheerio, Leo [1] amount of beard on administrator may vary. Beard may contain traces of nuts. [2] mistakenly referring to unix as linux often not advisable. [3] I think it doesn't say this clearly enough in the incubator docs, but, feed infra team a selection of their favorite beverage at apachecon should probably be on the incubation checklist! - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Flume to join the Incubator.
+1 and welcome on board. cheers, Leo On Wed, Jun 8, 2011 at 5:38 AM, Jonathan Hsieh j...@cloudera.com wrote: [ ] +1 Accept Flume for incubation [ ] +0 Indifferent to Flume incubation [ ] -1 Reject Flume for incubation ... = Flume - A Distributed Log Collection System = == Abstract == Flume is a distributed, reliable, and available system for efficiently collecting, aggregating, and moving large amounts of log data to scalable data storage systems such as Apache Hadoop's HDFS. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Sqoop for Incubation
+1! cheers, Leo On Wed, Jun 8, 2011 at 4:39 AM, arv...@cloudera.com arv...@cloudera.com wrote: As there are no active discussions on the [PROPOSAL] thread for a few days now, I will like to initiate the vote to accept Sqoop as an Apache Incubator project. The proposal discussion thread and full text of the proposal can be found at the following locations: Discussion Thread: http://www.mail-archive.com/general@incubator.apache.org/msg27726.html Proposal: http://wiki.apache.org/incubator/SqoopProposal Please cast your votes: [ ] +1 Accept Sqoop for incubation [ ] +0 Indifferent to Sqoop incubation [ ] -1 Reject Sqoop for incubation Pasting wiki page below for archival/reference: = Sqoop - A Data Transfer Tool for Hadoop = == Abstract == Sqoop is a tool designed for efficiently transferring bulk data between Apache Hadoop and structured datastores such as relational databases. You can use Sqoop to import data from external structured datastores into Hadoop Distributed File System or related systems like Hive and HBase. Conversely, Sqoop can be used to extract data from Hadoop and export it to external structured datastores such as relational databases and enterprise data warehouses. == Proposal == Hadoop and related systems operate on large volumes of data. Typically this data originates from outside of Hadoop infrastructure and must be provisioned for consumption by Hadoop and related systems for analysis and processing. Sqoop allows fast provisioning of data into Hadoop and related systems by providing a bulk import and export mechanism that enables consumers to effectively use Hadoop for data analysis and processing. == Background == Sqoop was initially developed by Cloudera to enable the import and export of data between various databases and Hadoop Distributed File System (HDFS). It was provided as a patch to Hadoop project via the issue [[https://issues.apache.org/jira/browse/HADOOP-5815|HADOOP-5815]] and was maintained as a contrib module to Hadoop between May 2009 to April 2010. In April 2010, Sqoop was removed from Hadoop contrib via [[https://issues.apache.org/jira/browse/MAPREDUCE-1644|MAPREDUCE-1644]] and was made available by Cloudera on [[http://github.com/cloudera/sqoop|GitHub]]. Since then Sqoop has been maintained by Cloudera as an open source project on GitHub. All code available in Sqoop is open source and made publicaly available under the Apache 2 license. During this time Sqoop has been formally released three times as versions 1.0, 1.1 and 1.2. == Rationale == Hadoop is often used to process data that originated or is later served by structured data stores such as relational databases, spreadsheets or enterprise data warehouses. Unfortunately, current methods of transferring data are inefficient and ad hoc, often consisting of manual steps specific to the external system. These steps are necessary to help provision this data for consumption by Map-Reduce jobs, or by systems that build on top of Hadoop such as Hive and Pig. The transfer of this data can take substantial amount of time depending upon its size. An optimal transfer approach that works well with one particular datastore will typically not work as optimally with another datastore due to inherent architectural differences between different datastore implementations. Sqoop addresses this problem by providing connectivity of Hadoop with external systems via pluggable connectors. Specialized connectors are developed for optimal performance for data transfer between Hadoop and target systems. Analyzed and processed data from Hadoop and related systems may also require to be provisioned outside of Hadoop for consumption by business applications. Sqoop allows the export of data from Hadoop to external systems to facilitate its use in other systems. This too, like the import scenario, is implemented via specialized connectors that are built for the purposes of optimal integration between Hadoop and external systems. Connectors can be built for systems that Sqoop does not yet integrate with and thus can be easily incorporated into Sqoop. Connectors allow Sqoop to interface with external systems of different types, ensuring that newer systems can integrate with Hadoop with relative ease and in a consistent manner. Besides allowing integration with other external systems, Sqoop provides tight integration with systems that build on to of Hadoop such as Hive, HBase etc - thus providing data integration between Hadoop based systems and external systems in a single step manner. == Initial Goals == Sqoop is currently in its first major release with a considerable number of enhancement requests, tasks, and issues logged towards its future development. The initial goal of this project will be to address the highly requested features and bug-fixes towards its next dot release. The key features of interest are the following: * Support for bulk import into Apache HBase. * Allow user to supply password in
Re: [VOTE] Accept OpenOffice.org for incubation
On Fri, Jun 10, 2011 at 5:02 PM, Sam Ruby ru...@intertwingly.net wrote: As the discussions on the OpenOfficeProposal threads seem to be winding down, I would like to initiate the vote to accept OpenOffice.org as an Apache Incubator project. +1 from me (binding). cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[DISCUSS] how to add many committers to a new project (was: Re: [VOTE] Accept OpenOffice.org for incubation)
Hey hey, On Sun, Jun 12, 2011 at 7:04 PM, Joe Schaefer joe_schae...@yahoo.com wrote: +1 binding. Given the sheer number of committers involved in this podling there will be some work to do trying to gel a coherent development community out of the group. While I am optimistic, I am reminded of Roy's cautions about piling on [1] to a prospective podling, and am not entirely convinced that it's necessarily a good thing that we promote the idea of getting in on the ground floor wrt new podlings. [1]- http://s.apache.org/VT5 Perhaps one approach the podling could take at the guidance of its mentors is to create accounts on demand. I.e. first order of business is getting basic infrastructure up (I think everyone is looking forward to having traffic on general@incubator back to normal -:) ), next up is getting the initial code import. Next after that you start adding in the people that have sent in CLAs and are wanting to touch the code/website/etc. That's what harmony did. It helped the project get into a mode of voting in new people frequently, and it also helped make visible to the project that it was ok if you didn't show up on day 0. cheers... Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)
Yupyup. I thought I'd add a little background rant here, that I wrote for the jena podling a bit ago. Purely optional reading but maybe illuminating for some. cheerio, - Leo On Tue, Nov 8, 2011 at 9:44 PM, Leo Simons m...@leosimons.com wrote: On Fri, Nov 4, 2011 at 3:54 PM, Benson Margulies bimargul...@gmail.com wrote: snip/ Release votes are about universally 72 hours. Benson is of course right, but I like pointing out reasons behind such conventions, so I'm going to give you a belated, long answer anyway, reading it is optional :-) I'm always a little annoyed when I see people say something like sorry your vote doesn't count it was too late, or you can't do that yet you have to wait 3 more hours someone might still vote -1 :-) The underlying point is to make sure to give everyone a reasonable chance to make up their minds and then vote (in the broadest everyone sense, and even if they may not have a binding vote). Religiously sticking to numbers is silly. Use your judgement. The duty of PMC members in the end is to act in the best interests of the apache foundation (which acts in the best interest of the general public), not to follow (or force onto others) particular rules. Some examples to illustrate, probably unneeded, but... If you consider people might be a day behind on their e-mail, and they might be on the other side of the globe, that's 36 hours absolute worst-case. If you add a weekend in the middle from friday 5pm to monday 9pm that's a total of 36 + 7 + 9 + 48 = 100 hours. If you consider that it may take a day, say, to verify a release and regression test it (say across your, err, 1000 node hadoop cluster, whatever), that's 124 hours. So you could have a long argument that 72 hours is not enough, and decide as a project you will use a 124 hour minimum. You're allowed to do that, if that's what you think is best for your community. On the one extreme you can imagine a project with all the people on the mailing list being on UTC time or close to it where a vote is almost pro forma since consensus was clear anyway, where you start the vote at 9am in the morning and everyone subscribed to the mailing list has voted by 11am. Do you then want to wait 122 additional hours because that's a rule? Not really. On the other extreme, for something like here's a proposal to bring geronimo / harmony / openoffice into apache that impacts loads and loads of people and might cause corporations to move mountains, it's considered normal to allow reasonable amounts of time for discussion, where reasonable could be over a month. 72 hours turns out from experience to be a nice standard number for release votes and other such important milestones, because it gives a very reasonable amount of time allowing for the broadest possible participation, without becoming a super-annoying super-long wait. It avoids people holding a project hostage and stalling, yet also avoids the temptation to rush through contentious changes when the majority (but not all) people are co-located at a hackathon, etc. But, use your own judgement. If one of the companies one of you works at would really really like an extra day to regression test a new version of jena at a large customer deployment, and that is delayed a bit because someone tied up all the jenkins instances with their hadoop stuff, it'll probably be a good idea to wait for the results rather than push through with a vote, since that means the general public gets to benefit from a better-tested release. This kind of balancing thing is, incidentally, why the how to do apache stuff docs don't have that many hard rules. Stubborn people like me keep editing them out :) cheers, Leo - 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
On Mon, Dec 19, 2011 at 9:20 PM, Alex Harui aha...@adobe.com 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 Pasted inline: = Apache Flex Proposal = == Abstract == Apache Flex is an application framework for easily building Flash-based applications for mobile devices, the browser and desktop. == Proposal == Apache Flex allows developers to target a variety of platforms, initially Apple iOS, Google Android, RIM !BlackBerry, Microsoft Windows, and Mac OS X with a single codebase. Flex provides a compiler, skinnable user-interface components and managers to handle styling, skinning, layout, localization, animation, module-loading and user interaction management. == Background == Apache Flex is the software evolution of the popular Adobe Flex SDK project. Adobe Flex SDK evolved from the need to provide developers with an easy programming model for creating rich Internet applications that can run in the browser, on the desktop or on mobile devices. Adobe Flex SDK has always focused on a single goal: to provide application developers with all of the constructs needed to boost their productivity while building large-scale, visually expressive applications. This meant that Flex provided all the traditional UI components in a way that designers and developers could interact with them along with a dynamic scripting language, !ActionScript, and a declarative markup language, MXML. Adobe will donate the Flex trademark to the Apache Software Foundation as part of the incubation process. The source code, documentation and related assets will all be contributed to the Apache Foundation as Flex. == Rationale == Content developers need to target multiple screens and the cost of creating applications native to every target platform is high. Additionally, the dominant window to the web is quickly becoming devices, mostly phones, and delivering consistent experiences is key. The Apache Flex project exists to bring the focus back to a consistent development model, one where a single application can run the exact same way across the web, desktop and mobile devices. == Initial Goals == * Donate all Adobe Flex SDK source code and documentation to the Apache Software Foundation. * Setup and standardize the open governance of the Apache Flex project. * Rename all assets from Adobe Flex SDK to Apache Flex in project source code, docs, tests and related infrastructure. == Current Status == Flex is a mature software project. 1.0 was shipped in March of 2004 with 7 major releases having shipped since. The most recent release was the 4.6 version which shipped on November 29th, 2011. == Meritocracy == The Adobe Flex source code is available to the community on the Adobe opensource site: http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK. Currently, while the community has been invited to contribute patches to the codebase, only Adobe employees decided on which patches to commit. There were no external committers and this caused frustration in the community. Going forward, both Adobe and our community are eager to become one single merit-based community working together. To that end, Adobe will only have minority representation on the initial committers list. Adobe is working to educate our community with meetings and blog posts on how the Apache model makes this possible for them. We have made it clear to our community that going forward, the community, rather than Adobe, will determine the future of Flex. == Community == The community surrounding Flex is vast, diverse, distributed globally, and with all levels of proficiency in software development. The common thread of application development binds all Flex developers together. It is estimated that there is between 350,000 and 500,000 Flex developers worldwide. Precise numbers are impossible for us to know due to the open nature of Flex. A blog post calling for initial committers received over 60 responses in two days. The !FlexCoders mailing list, a general-purpose mailing list for anyone working with Flex, has over 9000 members. A quick look on the Adobe Forums or Twitter’s #!AdobeFlex hashtag usually shows activity within minutes. The community is engaged and active daily and incredibly excited by Adobe’s move to contribute Adobe Flex SDK to Apache. The community is responsive, inclusive and honestly emphatic when it comes to bettering Flex for application development. == Alignment == The only way the Apache Flex project can work is if it is an open, transparent and collaborative effort. The project has now grown in mind-share and community enough that we believe it is time we work with a foundation to see the code mature in a fashion consistent with our values. == Known Risks == Moving from a corporate-led project to the Apache model of collaboration is a challenge, and Adobe is committed to help making the transition as smooth as
Re: [VOTE] Release jena-2.7.0-incubating (RC1)
*bump*. We have 2 +1s from mentors already, so at a minimum we need just one more binding vote to do this release. Anyone have time to do the review? thanks! Leo On Mon, Dec 19, 2011 at 10:16 AM, Andy Seaborne a...@apache.org wrote: Please vote on releasing the following as Apache Jena version 2.7.0-incubating This will be the first incubator release for Jena at Apache. == Overview Jena is a Java framework for building Semantic Web applications. Jena provides a collection of tools and Java libraries to help to develop semantic web and linked-data apps, tools and servers. Jena is composed of a number of modules. Historically, they have been released semi-independently, sort of flying in formation. We intend to switch to a more integrated build process and we want to create the time to do that by making this first Apache release now. For this first release, we need to release several modules at once as none have been released at Apache before. Our apologies for the extra checking work this results in. It also makes building everything from scratch involve more steps than an integrated build would do. Jena is delivered as maven artifacts for the jar for each module. It is also delivered as zip file containing all the jars and their dependencies so users have a download and unpack option. The version number of the release aligns with the main artifact and the packaged download. Different modules have different version numbers. Detailed version numbers: jena-top 0-incubating Parent POM jena-iri 0.9.0-incubating IRI parsing library jena-core 2.7.0-incubating Main Jena APIs for RDF and OWL. jena-arq 2.9.0-incubating SPARQL query engine. apache-jena 2.7.0-incubating Download, with all dependencies. == Project vote Apache archives: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201112.mbox/%3C4EEDE5F6.1070409%40apache.org%3E Markmail: http://markmail.org/message/dob5hsk46ldqkqt4 == Maven staging repository https://repository.apache.org/content/repositories/orgapachejena-334/ == Proposed dist/ area: http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/ == Keys https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS == SVN tags Each module is currently tagged with the version and -RC-1 to denote the first release candidate for this release cycle. If voted on successfully, the tag will be changed (svn mv) to the same but minus the -RC-1. https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaTop/tags/jena-top-0-incubating-RC-1/ https://svn.apache.org/repos/asf/incubator/jena/Jena2/IRI/tags/jena-iri-0.9.0-incubating-RC-1/ https://svn.apache.org/repos/asf/incubator/jena/Jena2/jena/tags/jena-core-2.7.0-incubating-RC-1/ https://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/tags/jena-arq-2.9.0-incubating-RC-1/ https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaZip/tags/apache-jena-2.7.0-incubating-RC-1/ == Website Including details of this proposed release: http://jena.staging.apache.org/jena/ Please vote on this release: [ ] +1 Approve the release of Apache Jena 2.7.0-incubating [ ] -1 Don't release, because ... This vote will be open until: Thursday 22/December 23:59 UTC (72 hours from the same hour tonight). As well as the vote, we'd also appreciate any feedback for improving our release process and project generally. Andy - 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] Flex for Apache Incubator
Hey folks, I had to think about this a bunch. We don't have anything like this at apache today. On Tue, Dec 20, 2011 at 9:37 PM, Greg Stein gst...@gmail.com wrote: On Tue, Dec 20, 2011 at 15:30, Raju Bitter rajubit...@googlemail.com wrote: (..) Adobe Flex is quite different from most Apache projects (...) it looks like the output of the compiler can only be used with Adobe-owned proprietary software at the moment. (...) As I mentioned above, I don't see this as a problem whatsoever. (...) Just to pick this apart... * Flex helps you make apps that target the flash player (or the AIR runtime...) * There is effectively one implementation of flash player (supporting the v10 SWFs that come out of flex...) ** which you get from adobe or someone that has an agreement with adobe ** which comes with very restrictive licenses [3] *** basically you probably can't even *use* it if you want to implement a flash player yourself [4]. * This flash player plays SWF files (and FLVs..). ** SWF has an open spec that isn't very open at all [1,2]. * Flex does not produce SWF files all by itself. It uses the Flash SDK and the AIR SDK (and some other bits) ** which you have to get from adobe and which come with very restrictive licenses. * Adobe could unilaterally change the license for the flash player, the SWF format, and/or the prerequisite SDKs, and flex would become essentially useless. Analogies to .Net or Java (or oracle databases) don't make much sense to me. Instead if I had to come up with an analogy, it would be something like having an apache http server that you could only install on windows, and run only if you already had IIS, and that would then host websites that you could only view if you had internet explorer. I don't understand why it's useful to have such a project at apache. But, apparently, a lot of people do want to work on it, and flex is obviously useful to a lot of people. So is there a problem? I guess not. As long as the Apache Flex website makes all this clear enough and no-one makes a PR mess out of it or anything like that, I don't see any actual problem with the proposal. I can't say I'm enthusiastic about it, but I don't have to be. cheerio, Leo [1] http://en.wikipedia.org/wiki/SWF#Licensing [2] http://www.adobe.com/devnet/swf.html [3] http://labs.adobe.com/technologies/eula/flashplayer10.html [4] http://en.wikipedia.org/wiki/Gnash#Adobe_Flash_Player_End_User_License_Agreement - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Forks without concensus?
Hey hey, (Pff. I like replying in-line but this is a hard e-mail to reply to in-line so I will top post.) If I understand your policy question: will apache allow an incubating community to show up and start a project when they are forking another project? I'd say, in general, yes, probably, if all the other criteria we have are satisfied. But, well, what if that other project is open source already, and some people don't want the fork to exist at apache? Well, then probably something is wrong in the first place, and it needs to be investigated. Why, otherwise would a group of people show up that want to fork at all? I think it quickly becomes a judgement call. On the one hand, should apache try and avoid getting tangled up into a complex mess just because it is complex and messy? No, I don't think so. If anything, apache is supposed to be good at helping people sort out their complex messes. If we have mentors willing and able to help, let's try and help. On the other hand, should apache make sure that it's considerable weight is not mistakenly thrown behind an initiative that somehow goes against our core values (an open, collaborative, consensus-based process)? Absolutely. Etc. So the generic policy is there is no generic policy, and instead there is appropriate application of judgement to specific cases. cheerio, Leo On Tue, Jan 3, 2012 at 6:35 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/3/2012 11:14 AM, Greg Stein wrote: On Jan 3, 2012 11:48 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: ... A PMC I am on had this exact conversation with board members several months ago regarding a code base the project is dependent on that is housed outside the ASF which we were considering bringing in as a subproject. We were told that under no circumstances could we fork the code without the owner's blessing, regardless of what the license allowed us to do. To me, this answer is black and white. Not to me. :-) Which is the problem, isn't it? Note; hat switch, you are now speaking with the authority of a Director. Euh, nope. Offering my personal opinions. A Director hat would (and does) mean nothing since I could not speak for the Board. So this is a question that should be put to bed once and for all, you have both been swinging pretty wildly at diametrically opposed answers to this question. If we read that the Board has charged this committee with acceptance criteria for submitted or proposed products... then the question above should be resolved. Essentially, we have several choices... [ ] Forks are accepted without judgement [Greg] [1] [ ] [something more nuanced here] [ ] Hostile forks are never acceptable [Roy] [2] If the answer lies somewhere in the middle, it would help potential contributors/forkers to know approximately where that middle sits. [1] I don't see it as our place to *judge* communities. If it is a fork, or a corporate spin-out, or a move, or brand new... All Good. [2] At Apache, all contributions are voluntary. We do not accept code from copyright owners who don't want us to have it, even if we have the legal right to adopt it for other reasons. - 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
Hey folks, I felt I had to take a look at this. Like Ralph I was very concerned when I saw Ethan's e-mail. Thanks a lot for writing it Ethan, and thanks for writing it with so much detail. I just read all the e-mail about bloodhound I could find (that I had pretty much ignored when I saw other people I trust were looking at it) and then I read the last year of trac e-mail traffic (fwiw, the relevant/interesting e-mail concerning the bloodhound proposal is all in the last 2 months, older relevant e-mail is not on publicly archived lists). I have to say I'm a lot less concerned now. First impression: the trac community is full of really nice people and it's mailing lists are full of gentle and carefully considered communication. Very nice to see :-). I wish all open source communities were like that! I really recommend anyone else trying to form an opinion goes and looks at trac-dev. In particular you may want to read the overview one of the core devs from trac wrote for our benefit: https://groups.google.com/d/msg/trac-dev/kMVFq9pkfus/eYMCVfqyUwkJ The bloodhound proposal and communication around it probably could've been handled better over the last 9 months or so, but it also could've been handled much worse. It's a typical example of the difficulty that exists where a company wants to engage an open source community and there isn't a strong legal/commercial story yet. All the parties seem to be trying hard to come up with the best approach for everyone, and the apache approach seems like it should be able to help produce a healthy kind of collaboration. The bloodhound proposers look like they're doing pretty well now in communicating intent and approach clearly on the trac mailing list, and the trac folks in turn seem pretty clear on what is and isn't going on. Bloodhound at apache will probably be better for all, than bloodhound not at apache. If things continue on their current path, apache rules and processes should help minimize negative impact on trac so that the effect on trac will be a definitive net positive. I remember a bit about trac internals from years ago and ISTR it's pretty cleanly split into lots of little bits...so I imagine bloodhound can (and should) take a careful licensing path contributing patches to core upstream as BSD while making new/rewritten plugins available upstream as ALv2. That seems to be the intent, too. Proof will be in the pudding :-D I do think it would be nice and appropriate if someone updates the proposal page along the lines that Ethan mentioned, probably by simply removing the somewhat unfair depictions of the trac community. (perhaps edit the current page, but keep a link there to the version that was voted on, for clarity). All in all I think bloodhound should continue on, and the incubator PMC should trust the mentors to keep things on their current track (hehe) of collaboration-where-possible, rather than turn this into an overheated debate. cheers, Leo On Fri, Dec 30, 2011 at 9:30 PM, Ethan Jucovy ethan.juc...@gmail.com wrote: -1 The Bloodhound proposal is to build an issue tracker by first importing the Trac core code into the Apache Subversion repository. As currently planned, this project has potential to be detrimental to the existing Trac brand and community, and it seems that the Bloodhound project's goals could equally be achieved without taking the heavy-handed first step of forking the Trac codebase. I hope that the Bloodhound team will consider building Bloodhound as a set of plugins and configurations and an installer that distributes them with an upstream Trac version, rather than forking Trac as a first resort. My concerns fall into three categories: a) The Bloodhound proposal contains substantial allegations about the health of the Trac community and the competence of its maintainers, as motivating factors for the fork and rebuild community approach proposed. No documented evidence has been provided to support these claims, and many of the claims are directly contradicted by the publicly available records in the Trac community's issue tracker, mailing list archives and commit logs. b) Neither the Bloodhound proposal nor the ensuing discussions have demonstrated any compelling legal, procedural, technical or strategic reason why Bloodhound should be based on a fork of Trac rather than an upstream distribution of Trac. c) Although the people involved have been friendly and expressed a desire to keep the two projects in cooperation, the actions taken so far and the intentions announced are characteristic of a hostile fork. -- (a) The Bloodhound proposal contains substantial allegations, without evidence, about the health of the Trac community and the competence of its maintainers. These allegations are largely contradicted by publicly available records of the Trac community. * The Bloodhound proposal claims, Private efforts to engage the existing developers in implementing features have
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Sat, Jan 7, 2012 at 10:24 PM, Roy T. Fielding field...@gbiv.com wrote: If there is a community and that community doesn't want Apache to fork the code that they created, then we will not fork that code at Apache. If the original developers of the code do not want their license changed, then we will not fork the code at Apache. We only accept voluntary contributions (contributions == the stuff we take on as change-controller and managed as such by one of our collaborative projects). We use other open source code and include that other code in our own releases, but we don't take change-control over it without the blessing of the original authors. [Citation Needed] While I agree with the general idea, the closest I can find to it being written down is http://incubator.apache.org/guides/proposal.html#template-community which is not very close at all. Did the subject actually come up before or is this the first time you wrote this down? Also, we should consider that the modus operandi of open source is changing. The default behavior on github for example is to put a fork me on github button on your project website, which doesn't mean a community fork, but for the healthier projects it does mean community chaos as forks and pull requests simply happen all over the place. So the relationship between take change-control and community fork is a bit different in those instances. You could say that the fork me on github (or just using github) is in fact inviting everyone to take as much change control as they want. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RT] Community over policy, and similar thoughts
Hey folks, I started writing this e-mail in November or so. My normal approach with stuff like this is wait for a non-contentious quiet period before starting a new thread, to maximize the chance the words will be read for what they say rather than interpreted in the context of some heated debate. Unfortunately, heated debates have been happening here for a long time, with little break, and though I have something here that is not hot, it still needs contributing. So, sorry about the timing, but I'm posting it anyway Mwuhahah. Hah? cheers, Leo TL;DR [10][12] == There ought to be more gentle, humble, consensus-building conversations. And, hugging. TOC === * TL;DR * TOC [11] * Preface * Community over policy * Consensus-building * Poldermodel * Community-building * Focus and feelings * Lack of a call to action * References Preface [0] === [RT] are Random Thoughts. This is a tradition in the Cocoon community. RTs are basically long and thought-provoking mails with new project propositions, that are discussed and scrutinized at length. One distinguishing characteristic about RTs is the complete and utter lack of consistency with respect to quality: some are pure crap, others are pure genius. Even the original author of a RT is not sure which category any given posting falls into at the time it is issued. This posting is no exception. Community over policy = We have this shorthand saying of community over code: at apache, while we value code, when given the choice, we value community more. Of course there is a lot of complexity and nuance that you lose in the summary, but, once you understand the meaning, the shorthand is useful. I would like to add community over policy: at apache, while we accept some policy is needed, when given the choice, we value community more. Note the words I would like, because I don't think that's where we are today and I also don't think we have consensus on it. A partial corollary would be that the incubator policy documentation is done not when there is nothing left to add, but when there is nothing left to take away. I think everyone agrees with that in principle, but it may not get the focus it deserves in practice. Unfortunately bureaucracies have the tendency to grow more bureaucratic over time. Beyond a certain threshold, those bureaucracies then ever so gently shun away a certain class of people, then another, until only bureaucrats remain. Consensus-building == The most important new communication skill to learn for people when they get into apache-style open source is probably the nitty gritty of how to build consensus. I've never quite seen how to do that online written down. It involves something like * write for a global audience, [2] * use principled negotiation, and [3] * speak softly, be humble. [4] It is quite difficult to lose ambiguity, to remove localized colloquialisms without sounding too formal, to avoid using hard words like colloquialism, and still convey the message you want to convey. This is hard to teach and harder to master. Once you figure out how to write, you then need to figure out how to write it concisely. And when you know how to do that, you still need to figure out the right things to write. That is, you need to actively restructure your thoughts, plans and ideas to be easy enough (as easy as possible?) to get consensus on. If you're a rigid thinker (perhaps because you're a software developer?) the natural form of your thoughts probably is not the easiest-agreeable form. Unfortunately most of the messages to general@incubator from people that have been around apache a while don't use this style at all. I've seen the prevalence of an authoritative, declarative and confrontational style increase further and further over the years here (and elsewhere at apache). It's unfortunate, but the incubator does not set a good example these days when it comes to how to build consensus [9]. A big part of the reason for that is that the incubator is solving hard problems, but another part of the reason is the way that communication happens. It's especially difficult for me to see this and harder to correct. That's partly because I learned a lot of how to do this from the same people I know see dive into confrontation after confrontation, but mostly because I want to avoid even a hint of censorship. Poldermodel === As an aside. To provide some missing cultural context. I'm Dutch. According to Wikipedia [1], The polder model is a term with uncertain origin that was first used to describe the internationally acclaimed Dutch version of consensus policy in economics, specifically in the 1980s and 1990s.[citation needed] However, the term was quickly adopted for a much wider meaning, for similar cases of consensus decision-making, which are supposedly typically Dutch. It is described with phrases like 'a pragmatic recognition of pluriformity' and
Re: [RT] Community over policy, and similar thoughts
Hey Don, Thanks for your reply. You are quite right, of course. I hope I am also right at the same time :-). Maybe I can clarify... On Mon, Jan 16, 2012 at 4:48 PM, Donald Whytock dwhyt...@gmail.com wrote: Like Apache, But Sexier...LABS? I can totally see that. Anyone want to start an Apache LABS podling? I am assuming you know but I will nevertheless redundantly point out for those that don't that there is actually a http://labs.apache.org/ . It is pretty cool and has a relatively sexy web site :) But while community can be flexible in a lot of ways, policy generally can't be. The rules are there; exceptions can be made, but in terms of law it's generally safer to assume they won't be. So, as much as I hate to say it, I don't think community over policy can actually work. Indeed, some of the rules apache has are rules that it has to have because of the law. Some others come from its tax status -- apache could ignore those rules, but then it would lose a financially beneficial tax status. Others rules apache has written down in its bylaws [1], and the apache members could jump through a bunch of hoops to change some of those. But, then, a lot of the rules that apache has are there because apache wants to have them. I will write you out an example. Once upon a time the incubator had said that incubating projects should not do binary releases, for a couple of reasons: * to avoid users downloading incubating software: apache was concerned that end users would not understand the tentative status of incubating projects; * to give projects yet another incentive to do their incubation process quickly: incubation should be as short as possible. Back then I think we thought 3-6 months would be the norm; * legal umbrella: apache the Foundation appoints Officers who have Committees who make Decisions on behalf of the Foundation. Releasing software is such a Decision and it's reserved for PMCs. Podlings don't have PMCs so who should release? But then along came a project that really wanted to release early, release often, and also do binary releases [2]. Their mentor had actually encouraged this since he believed release early, release often is good engineering and community-building practice. So what to do? Well, the issue was discussed, at some length, and it was decided that perhaps we could have releases if we added a disclaimer, and that the incubator PMC would vote and assume responsibility for the release. The project added the disclaimer to its website and made its release. Everything seemed fine, so someone turned those words into a template [3] and stuck them on the policy website along with a description of how to do a release. That was in September 2003 [4], and it's been policy since [5]. If for some reason you find these disclaimers really really horrible, you can go back into the commit history for the policy docs, and then into the e-mail archives to figure out why the policy says what it says, think about it some more, and perhaps come up with a better idea. Then that idea can be discussed and the policy can be changed, by the community :-) I personally think this is *fascinating* history. I'm weird like that. Unfortunately in 2012 those words from 2003 seem to have significantly gained in weight. A lot of projects have followed the rule without complaining, so why should you? This is not just some words some guy wrote, it's a community decision with a rule on a pretty website (not on a rebel CSS-less wiki with an edit this page invitation), and it has the word policy slapped on top of it. These days we probably have mentors that had never thought about open source communities, when the incubator had those rules already on the website. They've seen that rule, and they hand the rule to their podlings, who then follow the rule. The feeling is very different and the dynamic is different: it has changed from hmm, how should we tackle this into do what the rules say. This isn't bad per se (it's a good rule, probably), but I believe we do need to spend effort to compensate for the lack of positive feeling. Hence, community over (but not against) policy! cheerio, Leo [1] http://www.apache.org/foundation/bylaws.html [2] http://mail-archives.apache.org/mod_mbox/incubator-general/200309.mbox/%3c4c2f1577f2ef2840a9ae9ec61860c8810a0...@usseex01.amer.bea.com%3E [3] I tried to find the first version of the wiki page, but that was hosted on a machine owned by sun and inside a sun data centre, and we didn't migrate all the history (sort of in violation of apache infrastructure rules even then, but hey, projects really really wanted wikis and there was no apache hosted wiki...oh man, those dare-devil incubator rebels, breaking the rules!) [4] http://mail-archives.apache.org/mod_mbox/incubator-general/200310.mbox/%3c4c2f1577f2ef2840a9ae9ec61860c8810a1...@usseex01.amer.bea.com%3E [5] http://incubator.apache.org/guides/branding.html
Thoughts about reporting (was: Re: [RT] Community over policy...)
On Mon, Jan 16, 2012 at 6:42 PM, Sam Ruby ru...@intertwingly.net wrote: snip/ We may also have semantic gaps. Leo's [RT] may be presuming that a podling's board report[sic] is merely a bureaucratic requirement. snip/ Hmm :-) And so the threads collide... ...I guess I'll allow it. But since we're in my thoughts now, I'll go ahead and say something :-) I would say that you need to provide a quarterly report using this template and add it to that wiki page and then get it signed off by a mentor [1] is a somewhat bureaucratic expression of your community needs to be self-reflective and periodically tell us how things are going, because of [X] and [Y] [1] and that the expression of the latter is perhaps more important than the expression of the former. It's definitely more interesting! I think as far as requirements go, submitting written reports to be collated and read and then discussed in a conference call is not the best way of overseeing stuff. If I chaired a group of people that had to oversee something like apache I'd probably try and change how to go about that. Something involving green flags in checkboxes I think. Similarly, if I had to report into those people I would make a point of changing the style of the report every so often, to keep them on their toes, and make their oversight job as pleasant as possible. Fortunately, I don't hold any furniture-related titles. Having said that, I think incubator reports are good practice for board reports so as long as board reports function the way they do, podling reports should function similarly. Which is why I've been happy enough for current, former and future board members to present their opinions [2] on the subject and stay silent myself :). Fail. In fact, my personal plan [3] was to stay out of this discussion, and continue to do as little reading of reports as I can possibly get away with. My talents lie elsewhere. Benson can be the deals-with-reporting mentor, I can be the deals-with-license-headers mentor, and yet someone else can be the I-critically-review-30-incubating-projects-including-the-report-Benson-already-signed-off-on [4] PMC member. I will thank you for your reviewing and signing-off-ing efforts, and I will ensure my mentorees all buy you beverages. Come to think of it, I guess a good plan for the future is to co-mentor with at least 2 people that are on the board, since they read all the reports anyway eventually for their meeting, and if they don't, there'll be people frowning at them over the conference call, so they'll be much more motivated than me to do it well. Even better, I could try and make my co-mentors into board members, and I guess one of them should be the incubator PMC chair, too. Yes, that sounds like a plan. Mwuhahah. Hah? In any case, I hope somebody beats me to a thorough review of next month's podling reports, but if not, I intend to repeat the the process where I provide feedback here before providing feedback that will ultimately be published on the ASF web site as a part of the ASF board meetings. Thank you, Sam. I doubt I will beat you, though I may have a go :) cheers, Leo [1] these are imaginary quotes, no one said these things! I'm inventing them and/or paraphrasing from memory. [2] yes yes yes, not necessarily acting in their board member capacity. Still, people doing the work (reading the reports, doing the oversight), that know a lot about doing the work, they get to have a say. [3] Warning: I'm perhaps partly joking. I do read a lot of reports, but I don't quite do 'critical review' most of the time. [4] the last report I read for the podling I mentored was signed off by either Benson or Ross, I forget. But the example is stronger if I stick with Benson. Sorry Ross, I'll buy you an extra beverage. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [names] Public Review
Hey Robert, Thanks for this; it was obviously a lot of work! I like the word picks, flow and style of this guide a lot. There's a lot to read here and some new stuff to learn for me -- I confess I've been ignoring as much about trademarks as I can until a time comes up when I actually have a need to dig into it more. So I can't really help write, but I can ask questions :) On Sun, Jan 29, 2012 at 3:05 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: On Sun, Jan 29, 2012 at 11:45 AM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: The new documentation describing in more detail one way to check the suitability of the proposed name is just about ready for public review The URL is http://incubator.apache.org/guides/names.html It's fine to just dive in to improve phrasing, add examples etc. Once the information is collected and collated, then ask the trademark team to help interpret and analyse these results on the private lists, copying in the PPMC. Finally discuss the results of your investigation on the private PPMC list. We could probably do with some guidance of *how* to do this discussion. I.e. I _assume_ the CC is to trademarks@ but it's not stated. Similarly it's not quite clear what things need to be discussed. The discussion could be well a lot of stuff uses this name too but whatever it's probably ok -- +1, or it could be looks risky we may need to evaluate whether we are infringing (and then what happens?). Here's a good place to ask questions. This thread is also a good place to discuss content and dispute process details. * I personally think the way you wrote down that this is one possible approach is quite clear. I'll leave it to others to fix what they don't like about it ;-) I agree it's important that we know it's one possible way to care of this stuff. For example with Apache OpenOffice or Apache SpamAssassin or Apache Jena or other long-existing projects that come to the incubator the process is different since they typically did it years ago, are known to be the number one hit for that phrase, etc etc. * It's not clear to me what role the trademarks folks have in this process; I thought trademarks@ was primarily concerned with defending our marks, and providing policy to PMCs, i.e. not with doing the picking of the marks we use? Is it an advisory role because these folks happen to have experience, or is the advice intended to be, err, 'binding'? * If you are a new project and you have to pick a name, this is a useful guide. If you are a new project and you picked a name, but you didn't do your due diligence, you need to be nudged rather insistingly into doing your due diligence. And that then has a painful dynamic to it, because a group of people picked and decided and voted on a name and then they changed it. To fix this, we could put the process for the picking of the suitable name as part of the proposal process, i.e. you can choose to do it before you even send your proposal to general@. WDYT? Thus, instead of setting strict rules and requirements, I think the guide should just document the best current practice and suggest why following it is a good idea. Hmm, so there's an interesting balance here, and it's probably overdue for some shifting. I think we do need to make clearer the MUSTs around trademarks to new projects, basically passing on the PMC responsibilities we've gotten from the board via trademarks@. Perhaps we need another bit of documentation in the policy that points out the MUSTs, and then that bit links to this guide. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSSION] Regular rotation PMC chair
On Sun, Jan 29, 2012 at 9:39 PM, Christian Grobmeier grobme...@gmail.com wrote: On Sun, Jan 29, 2012 at 9:37 PM, Ralph Goers ralph.go...@dslextreme.com wrote: On Jan 29, 2012, at 12:16 PM, Benson Margulies wrote: On Sun, Jan 29, 2012 at 2:23 PM, Alan D. Cabrera l...@toolazydogs.com wrote: On Jan 29, 2012, at 6:18 AM, Ate Douma wrote: FTR: as should be clear from my above response, I disagree with the topic of this discussion thread. This should be about Regular (re)election of the PMC Chair. Regular rotation IMO would be unwise and undesirable. Good point. I share the same opinion. Let me try to state some alternatives: 1) No particular policy: The PMC has no special policy about recommending a new chair to the board. It will happen if the chair resigns, or if the PMC as a whole reaches a consensus on a change. 2) Fixed election schedule: On some schedule (e.g. annually), nominations are opened, including potentially the current chair, and a vote takes place. (I'd hate to have to fire up the full secret ballot mechanism used for board members.) Whomever wins is recommended to the board. ... If we don't reach a consensus on something else, we stick with the current state of affairs, which is, I claim, (1). +1. I would like it changed. My preference is option 2 alone. I don't see the point of term limits as I believe that will take care of itself. I'm not in favor of 1 because it always seems to end up feeling like it is personal when people bring up rotating the chair - i.e. isn't the current chair doing a good enough job, the current chair should say they want to resign first, etc., rather than it just being time to allow the PMC to reevaluate itself +1 for option 2 and what Ralph said +1 cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator, or Incubation?
Hey folks, I just wanted to chime in with a +1 for the general direction. I think there's actually a lot of work to do to iron out how to reorganize things. Before digging in, I suggest we abstract out a little bit to see if we have consensus on the overall goals and desired end state before starting to debate the details, or the process by which to get there. 1) There are people who produce guides, rules and policy that describe the incubation process. These rules are then imposed on other groups at apache by board decree. 2) At any point in time, there shall be many groups of people following the incubation process. 3) There is a mechanism in place to provide oversight over all the different ongoing incubations. 4) The differences between communities going through incubation and those that aren't is clear and understood by all (including end users, press, etc). I think the above invariants describe both incubation as of yesterday and incubation as of tomorrow. But, we have some issues with the current incubator. a) The volume of incubation activity has grown such that oversight is difficult. b) Large group sizes (particularly general@ and IPMC roster) make accountability and consensus-building difficult. c) meritocracy is hampered by having the people doing the work not having binding votes on their own work. d) ... add your own similar issues ... The basic realization is that combining all the people from 1) and 2) into effectively one big group [1] is no longer the best idea. So, we want to redesign how we organize into groups, and associated with that we want to tune our oversight mechanisms. The basic idea is to split the current single really big group that is the incubator into smaller groups that still cooperate and discuss and whatnot, but are accountable and overseen separately. These smaller groups become their own committees with their own VPs that report to the Board. Is that a reasonable re-statement of the abstract idea? Is that something we can all get behind? The next steps then involve deciding just how to split things up. Since I'm off to go skiing tomorrow I won't be around next week to participate in the details of all that. Have fun :-) cheerio, Leo [1] the choice of the vague term 'group' is intentional: give us some degrees of freedom to design the structure, in a formal *and* an informal sense. One kind of group is a PMC, but there's also another kind of group which is people subscribed to a mailing list and another one people that read the stuff that's on the mailing list and another which is people who feel responsible for what's going on on that mailing list, etc. On Wed, Feb 1, 2012 at 11:25 PM, William A. Rowe Jr. wr...@apache.org wrote: On 1/31/2012 5:05 PM, Mattmann, Chris A (388J) wrote: On Jan 31, 2012, at 1:28 PM, Roy T. Fielding wrote: Having said that, I should note that the context of Incubator is significantly different than a normal PMC. If incubator wants to structure itself more like a board and less like a project, I really don't have much to say against that. Note that it should effect all of the decision guidelines that give veto power, not just personnel decisions. Isn't that the problem right now though? Like it or not, the Incubator PMC has evolved into a mini-board, in the worse sense of the word. You guys have a monthly meeting via telecon; an agenda; a set of action items, and you still don't get everything that you want to get done, done. A very small percentage of folks within the IPMC actually maintain that type of board-like oversight over its podlings. And thus, because of that, the more I think about it, quite honestly, I don't know what the Incubator PMC is doing other than delay the inveitable eventuality that many of these projects will graduate and become TLPs and thus the board's problem; whereas many of them will not graduate, and become not Apache's problem. We have an Attic for projects that make it to TLP for that. Heck, we have SVN and could even reboot Incubator dead projects if a group of individuals came along and wanted to maintain the code. My conclusion from all the ruckus recently has been that the Incubator PMC is nothing more than an Incubator mailing list where many ASF veterans and those that care about the foundation discuss (and sometimes argue) about the foundation's policies and interpretations of law that not even lawyers are perfect at -- we're all human yet we try and get on our high horse here and act like we speak in absolutes and the will of one or a small subset is the will of the many when we all know that in the end, if it's not fun anymore, we wouldn't be here. What would be so bad about saying that the Incubator, over its existence, has served its purpose and has devolved into an umbrella project of the type that we are looking to get rid of at the Foundation. I agree with Bill on the perspective that I'm sure at some point (and it's probably already
Re: [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)
+1 - Leo On Thu, Feb 9, 2012 at 4:16 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: In the interest of moving the current discussion matters forward, please VOTE on this recommendation to the board by the IPMC. I'll leave the VOTE open for at least the next 72 hours: [ ] +1 Recommend Jukka Zitting for the IPMC chair position. [ ] +0 Don't care. [ ] -1 Don't recommend Jukka Zitting for the IPMC chair position because... On Fri, Feb 10, 2012 at 3:28 AM, Noel J. Bergman n...@devtech.com wrote: +1 --- Noel - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: February report review
+1 I'd also suggest that the below is a partial answer to the board's questions to the IPMC on how it would improve oversight so it should probably go in our report. cheers, Leo On Thu, Feb 9, 2012 at 4:59 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: On Thu, Feb 9, 2012 at 4:30 PM, Sam Ruby ru...@intertwingly.net wrote: On Thu, Feb 9, 2012 at 9:14 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: What I would like to see is the Incubator start identifying PPMCs that are stalled, and to consider what information they need (in future reports) to help them (us) make such a determination. I am not suggesting that this be made retroactive. Or that it be done immediately. A plan would be fine: i.e., setting a date by which the IPMC will have decided what information needs to be in such reports, and a schedule by which the PPMCs need to start providing said information. My suggestion is to ask the podlings now in category 2 to report again in May on their progress on the identified blockers. If there's been no measurable progress by then, we'll dig deeper to see what we can do. Podlings reporting in other months can be picked up for a similar oversight cycle over the coming months. By July we should then have a pretty accurate record of progress throughout the entire Incubator, including a clear list of podlings that are stuck and need help. Before the next quarterly report I'd rely on mentors to help the podlings identify and implement ways to move forward. And of course, if a podling or its mentors feel that more help is needed, asking on general@ or submitting an extra report is always a good idea. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC2)
(back from holiday, still catching up, just replied on jena-dev, but for the record since this is a [VOTE]...) On 8 February 2012 13:03, Andy Seaborne a...@apache.org wrote: The Jena PPMC has voted to release Apache Jena TDB 0.9.0-incubating and we would now be grateful if members of IPMC would review and vote for this release. -1, specifically based on On Sun, Feb 12, 2012 at 1:22 PM, sebb seb...@gmail.com wrote: The tag and the packaging also need to be sorted out before release. Sorry, but it seems to me like you'll have to bake another RC with some fixes. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
small, reversible steps
Hey folks, TL;DR Small steps! Less friction! Lazy consensus! Reversible change! Meritocracy! YAY :-D History Use small reversible steps is a powerful idea when evolving things, like when evolving a software architecture. It's an idea that was made popular @ apache by Stefano. Since the idea seems to be drifting to the back of our minds a bit lately, I thought I'd bring it to the front again [1,4]: It's exactly like thermodynamics, where a infinite number of small reversible steps is more efficient than a small number of big but not-reversible steps. The good old Software Engineering practices they teach you in college are bullshit: making architecture decisions without continous reversibility is expensive because design constraints change too much. Those who want to apply hardware engineering practices miserably fail. Open source is here to prove that such a messy way to do code is actually the only one that works and scales. Thankfully, 'incrementalism' is much more prevalent in IT now than it was a decade ago :-). Perhaps not as well understood, but, it is also a very powerful approach to shaping communities and community behavior [2]. Among other things, gaining consensus gets easier the smaller the increment, to the point that you can get away with lazy consensus for the smallest of steps, which is indeed very efficient. Erosion vs destruction I do suspect radical goals such as deconstructing the incubator [3] are worthwhile to pursue. The deconstruction of jakarta followed (after much deliberation) an incremental approach with many small and reversible steps. That was the right choice then, and I'm confident it is the right approach here. I.e. deconstruction by erosion instead of by destruction. By contrast, heavyweight big-bang discussion full of rhetoric where conversation is cast into argument with those 'for' and 'against' is of very limited value. Turning sets of ideas into a 'platform' that you must buy in to (or not) is worse. It divides a community that does not need to be divided, and it impedes consensus much more than needed. We won't get far that way. I'm glad I missed a week full of such e-mail while I was on holiday :-). I shall continue to try to steer clear of it! (hug), Leo [1] http://mail-archives.apache.org/mod_mbox/cocoon-dev/200010.mbox/%3c39fad0b5.2d3f4...@apache.org%3E [2] http://psteitz.blogspot.com/2011/08/engineering-emergent-behavior.html [3] http://wiki.apache.org/incubator/IncubatorDeconstructionProposal [4] that took ages to find btw. I think it's the first reference on a public list to entropy concepts in IT, at least around here? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)
On Thu, Feb 23, 2012 at 4:50 PM, Andy Seaborne a...@apache.org wrote: The Jena PPMC has voted to release Apache Jena TDB 0.9.0-incubating and we would now be grateful if members of IPMC would review and vote for this release. +1 from me. (justification: 1) I do not consider unintuitive file name and directory layout conventions blockers for release; I think this thread shows unintuitive is subjective anyway. I pointed the deviations out before on jena-dev, and then folks obviously thought about this and decided to do things differently from a lot of other projects. Even if the chosen convention is wacky that does not make it wrong. 2) Whilst LEGAL-124 remains unresolved there's plenty of precedent for not having license headers in test data and similar auxiliary files, all around apache, and so I consider it fine to continue current standard practice until different rules arrive. 3) all looks good to me ;-) ) cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)
On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies bimargul...@gmail.com wrote: Leo, are you out there? Hmm? Oh, this again... Having company names or trademarks in java namespaces is a pretty stupid convention. It gets us mess like this... There is no policy that incubating java projects must rename to use an org.apache namespace. There has never been such a policy. We don't need such a policy. There's (typically/usually/knock on wood) no legal/trademark issue. There's ample precedent of keeping 'legacy' namespaces around 'a while' for backwards compatibility. And that's fine. At the same time, (incubating) projects should definitely carefully consider whether it is reasonable to change their namespaces, how to go about it, etc. Incubation can be a good time and/or trigger to make such changes, especially for projects for whom backwards compatibility isn't a big issue (yet) or that are doing a major revision as part of coming here. With my incubator PMC hat on, I like to see that a project community has thought this situation through, discussed it on their dev list, and got to some kind of consensus on what to do. I'd imagine such plans will include a strategy for eventually having all their code end up in an org.apache namespace or at least not in a com.company namespace. I'm sure other people said all this already, apologies for the noise, but hey, I got prodded, so... :-) cheerio, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-5)
On Sun, Mar 4, 2012 at 11:19 PM, Andy Seaborne a...@apache.org wrote: The Jena PPMC has voted to release Apache Jena TDB 0.9.0-incubating and we would now be grateful if members of IPMC would review and vote for this release. +1 from me. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Apache Accumulo to TLP
On Mon, Mar 5, 2012 at 3:49 PM, Billie J Rinaldi billie.j.rina...@ugov.gov wrote: Please vote on recommending the graduation of Apache Accumulo with the following resolution to the ASF Board. +1 from me. Well done, that was pretty fast :) Is it right that your PMC roster doesn't have apache members on it? That's fine, but I do hope your mentors stick around for a bit...it tends to help 'grease the wheels' during your transition to PMC. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Thoughts on Incubator board reports
Hey hey, Jukka this is sounding so timid :). You know, I think I'll break rank and tell you what I really think. You may want to sit down first. You [1] did a *kick ass* job on the last report. Kick. Ass. [2]. Kapow! As well as spending the time to look through and digest it all beforehand on e-mail, you made sure we had discussion about it. Which btw, wasn't a flamewar, which was nice, too. I know that prompted me to do a similar run-through on half of your list (I ran out of steam/time...I guess I'll start at the bottom next time) and I simply found nothing to add, but I did do much more overseeing by following along than I would have done if, say, I had gotten nagged a couple thousand times more. So, definitely +1 to keep going like that, thanks for spelling it out too, you should know we got your back :) cheers, Leo [1] helped by others of course, yada yada, we so love all you bearded folks, you know who you are [2] http://images.allmoviephoto.com/2010_Kick-Ass/2010_kick-ass_001.jpg On Tue, Mar 6, 2012 at 12:29 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: During the February board meeting there was a discussion about what the directors would like to see in Incubator reports. ... we should keep including the individual podling reports ... the IPMC should also provide a report summary along the lines of what we did last month. ... we should also highlight any notable issues or other topics the board may want to focus on. ... we'll take some time to discuss the podling reports - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Jena Fuseki 0.2.1-incubating
+1 from me. Can we get 2 more IPMC votes? (Checked KEYS, signatures, LICENSEs, NOTICEs, license headers. Built source release, watched maven download the internet. Ran compiled source and binary distribution and played with web interface. Almost remembered how to write SPARQL. Etc. All looks good to me.) cheers, Leo On Sun, Mar 18, 2012 at 9:20 PM, Andy Seaborne a...@apache.org wrote: Hi, Here is a vote on a release for Jena Fuseki module, 0.2.1-incubating. This RC-2 of this release. Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... This vote will be open until: Wednesday 21/March 23:59 UTC (3 whole days: 72 hours from the same hour tonight). jena-dev thread: http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201203.mbox/%3C4F63A159.7010506%40apache.org%3E Staging repository: https://repository.apache.org/content/repositories/orgapachejena-081/ Proposed files and structure to merge with existing Jena dist/ area: http://people.apache.org/~andy/merge-jena-fuseki-0.2.1-RC-2/ Keys: http://www.apache.org/dist/incubator/jena/KEYS SVN tag: https://svn.apache.org/repos/asf/incubator/jena/Jena2/Fuseki/tags/jena-fuseki-0.2.1-incubating/ Andy - 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: Jena mentors (Was: [VOTE] Release Jena Fuseki 0.2.1-incubating)
On Wed, Mar 21, 2012 at 5:54 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: On Wed, Mar 21, 2012 at 5:34 PM, Leo Simons m...@leosimons.com wrote: Can we get 2 more IPMC votes? On a related note, who are currently mentoring Jena? The status page [1] doesn't show. The Jena team page [2] lists you, Bertrand, Benson and Ross as mentors. Is that accurate? If yes, please update the status page accordingly. Well, I do remember Ross mentioning at some point he never intended to be a mentor and ending up on the roster by mistake (he was Champion). Of course, being the engaged guy he is, he did in fact do a lot of mentoring anyway, so I would guess he can be on the list :-). But maybe he'd prefer not to. TBH I'm semi-seriously considering not doing any more voting about jena, unless it is to +1 their board resolution to graduate :-P cheers, Leo - 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 Tue, Mar 27, 2012 at 12:57 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Let's decouple this thread from the specific issue of the ManifoldCF release. There's a long tradition of Apache releases like the ones ManifoldCF is producing, so turning this suddenly into a blocker is IMHO bad business, especially since no legal issues are involved (this is about Apache policy). If we do come to the consensus that releases like this are contrary to Apache policy, *jaw drops*. Huh? But, but, but. But! It's called open *source*. I am honestly just really surprised that this can even come up as a discussion topic. It's such a core concept that source releases are, well, *source* releases, everything is built on top of it. It's not a policy thing, it's a definition thing. The one case I can imagine that might be sort-of ok is if you ship a release with an ant-based build that includes a custom task, and in the source release of your entire project you *also* include a binary version of the custom task, so lazy people (or those without a working bash, or whatever) can avoid running your bootstrap script. (and simlarly, s/ant/maven/, s/task/plugin/, etc). But there's obviously better ways to do that stuff (target that compiles task, taskdef for task in next target, that kind of thing). then affected projects should be given a reasonable amount of time to adapt. Uhm. Normally I'd want to take a similar approach. But. But. But! Open *source*. It's so fundamental to what we do. This seems exactly the reason why we have incubation disclaimers: so we make clear to our downstream users we might be making some mistakes like this, and so that we can then be agile in fixing it. Whoops, made a mistake folks, no downloads here, stand by while the podling makes a new release I'd think that when we find a problem like this after a release is published, we (we as in the PMC, this is not a task to shove onto infra!) should immediately explain the problem and then immediately yank any existing incubation releases that have an issue here. No grace period, no voting, no discussion. Just fix it. That said, I'm not aware of us actually having such a release out there? How to deal with this stuff for TLPs that got it wrong, well, I guess that's a conversation for (a) different mailing list(s). g'night Leo, still trying to pick his jaw up from the floor - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Multi-licensed dependencies
On Thu, Mar 29, 2012 at 8:42 PM, sebb seb...@gmail.com wrote: On 29 March 2012 18:43, Roy T. Fielding field...@gbiv.com wrote: On Mar 29, 2012, at 6:17 PM, Marvin Humphrey wrote: Personally, I agree with Roy. Perhaps it might seem a little odd to include the text of e.g. the GPLv2 in one of our LICENSE files (alongside a more permissive license), but the key here is that it is both legally OK for us to distribute a product bundling such a dependency without explicitly justifying our usage, and legally OK for a downstream consumer to distribute a product bundling ours which asserts usage of the dependency under a different rationale. I prefer to put our license in the file and then, at the bottom, refer to a list of other licenses per dependency (if included in this package), wherein the dependency licenses are in separate files near the dependency. However, this does not agree with the following [1]: ... When an artifact contains code under several licenses, the LICENSE file should contain details of all these licenses. For each component which is not Apache licensed, details of the component and the license under which the component is distributed should be appended to the LICENSE file. [1] http://www.apache.org/dev/release.html#distributing-code-under-several-licenses ...the license file SHOULD contain ... I believe at least some of these how-to-put-the-license(s)-into-the-file(s) statements are not necessarily backed up by it must be this way legally or this is unambiguously always the best way kind of thoughts, but more by this is a good standard way to do it, that is easy to do and (automatically) verify. So Roy saying I prefer does not necessarily conflict with the SHOULD in the policy. I very much like the approach where the Incubator teaches the documented policies that have been defined by Legal. While it's probably good to have Roy's preferences (which I trust are good ones) reflected in our policy docs, that should happen via legal-discuss in this case, and even after that, we should not change what we teach our podlings until the docs have changed. It gets way too confusing way too quickly, otherwise. cheerio, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPC] [VOTE] Graduate Apache Jena as a Top Level Project
On Mon, Apr 2, 2012 at 11:10 AM, Andy Seaborne a...@apache.org wrote: This is a call for vote to graduate the Apache Jena podling from Apache Incubator to be a top level project. +1, binding, mentor cheers! - Leo (doing a little celebration dance) - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Jena LARQ 1.0.0-incubating
On Sun, Apr 1, 2012 at 9:48 PM, Paolo Castagna castagna.li...@googlemail.com wrote: here is a vote on a release for Apache Jena LARQ module: jena-larq-1.0.0-incubating. ... Proposed files and structure to merge with existing dist/ area: http://people.apache.org/~castagna/merge-jena-larq-1.0.0-RC-1/ +1 cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about downloading binaries
(dropped infra@) On Mon, Apr 2, 2012 at 10:54 PM, Benson Margulies bimargul...@gmail.com wrote: I'm exceedingly sorry here that the IPMC as a whole let you down by not turning into these issues and dealing with them at the outset. Me too. Personally, I have no objection to including mutant jars in a -deps binary with a clear explanation of what they are, but I would like to see some support for that view, because I'd could imagine some objections based on recent email. Me neither. But let me expand on that :-) Note the recent (explosive?) discussions were about source releases. If you get those right, what ancillary stuff (binaries, -deps packages, maven-repo-structured jar directories, ...) you can then _also_ have is not so much under discussion I think. Looking into ManifoldCF a bit, I think what you need is * buildable source release that contains all the source for ManifoldCF * source release that contains all the custom patches for the dependencies that need patches ** you could include the source code, but I'd actually prefer not to do that * source release that contains instructions for patching and then installing needed dependencies ** ideally this is all scripted of course (`build.xml install-and-patch-xerces` downloads xerces source release, extracts and applies patch, builds jar, copies jar into place, ...), but I don't see that as a requirement And if you have all that, then yeah, having various binary conveniences as well is not much of a discussion. cheers, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about downloading binaries
On Tue, Apr 3, 2012 at 5:04 PM, Karl Wright daddy...@gmail.com wrote: It sounds like I wasn't clear enough. The proposal is for the following release artifacts: (1) A source-only tar (2) A source+binary dependencies convenience tar (3) A binary tar This is instead of: (1) A source-only tar (2) A binary dependencies convenience tar (3) A binary tar Hope that helps... The question is, will Roy (or anyone else) be unwilling to vote for the first option? Can't speak for Roy of course, but *my* interpretation is that what matters is having (1). A readily buildable source release that contains all the source code that comprises the project, that is the official release of the project by the ASF, that is the open source apache-licensed thing that is carefully inspected and tested by the (P)PMC, that is the thing that is voted on, that you point to from your website as the source release, and such and so forth. Once you have (1), there's many different acceptable approaches for (2),(3),(4), and so on. I personally feel ManifoldCF (like any other project), perhaps with help from their mentors, can decide for themselves what is the best approach. For example, I don't particularly understand the purpose/value of either version of (2) (wouldn't I just always want the binary version?), but that's fine :) cheerio, Leo - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate Jackrabbit to TLP status (pending board approval)
On Sun, Mar 12, 2006 at 11:34:18PM -0800, Roy T. Fielding wrote: The Apache Jackrabbit committers have voted to request graduation from the Incubator as a TLP. ... So, I am asking for a vote of the Incubator on graduation of Jackrabbit that is conditional on the board's approval of a TLP for that purpose. This way we don't have to vote again after the board meeting on Wednesday. Please send in your +1/0/-1 to approve/abstain/disapprove. +1. Much like SpamAssassin some time ago, Jackrabbit is looking like a healthy community which has had a smooth trajectory through incubation, and as such sets an example for other incubating projects to follow. Kudos and good luck! cheers! Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator PMC membership
On Tue, Mar 14, 2006 at 10:10:32AM -0800, Alan D. Cabrera wrote: I'm curious, how does one get into the Incubator PMC? You ask for it, or people ask you. * If you're an ASF member and you step up to mentor a new project, Noel (VP) tells you this means you should subscribe to the incubator PMC mailing list and sends the board an email to ACK the addition. * If you're an ASF member and you're not mentoring a project, you send e-mail to the PMC mailing list and then Noel sends the board mostly the same e-mail (this near-automatic acceptance of ASF members onto the incubator PMC is a new thing, I think it was a change somewhere post-apachecon). * If you're not an ASF member, I suspect it has in general been based on invitation only (which involves the Incubator PMC voting, probably in private, like what happens on so many other projects). When the incubator started, it was ran more like most other ASF projects (and ASF membership wasn't especially considered at all for incubator PMC membership; I think I became an incubator PMC member before I became an ASF member). It seems lately the ASF membership has found it more and more important to ensure that the incubator has a sizeable representation of ASF members, but I haven't really followed those discussions closely at all. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
PMC composition, inactivity, policy (was: Re: ActiveMQ and ServiceMix reports)
Can people *please* get into the habit of changing subject lines to match subject matter around here? Thanks! On Thu, Mar 16, 2006 at 12:03:27AM -0800, Henri Yandell wrote: Alan wrote: Not providing commit karma seems to be a bit like forced retirement because of inactivity. Something that ASF frowns upon. We do have this concept of emeritus. In some projects emeritus status is supposed to be about automatic after 6 months of inactivity. If someone is MIA then a good reason not to provide commit access (not neccessarily the abstract privilege, but the actual access with login and password) is security -- we don't want people not managing their passwords and/or SSH keys. Let's do another scenario. Someone works very long and hard on one component of the project. That component becomes very mature and rock solid so, we really don't hear from him very often. Is it fair that he doesn't get commit karma when it graduates? IMO, no, it is not fair. Is it fair that he does not make it into the project PMC? Yes, it is fair, IMO. What if there is suddenly a problem with this component (perhaps a patent claim) and the PMC has to act? What if he is the only person on the PMC who really knows about prior art for this component? Would it be fair to have him be inactive yet on the PMC mailing list for say, 3 years, prior to that happening, if it means that the PMC as a whole is able to deal with the patent claim within a week instead of within two months? What is not fair is someone making decisions while not doing any of the work (eg we think meritocracy is fair), but you can be on a PMC yet not make any of the decisions (you just don't vote), and this is not really a very bad thing, as long as you live up to your PMC responsibilities when you have to. Its not black and white. Every PMC is unique, as is ever project, and every individual. In the end we're talking about individuals working together and they do that in many different ways. I'm convinced - this definitely seems like a very good reason to have inactive committers following an incubated project through to either TLP stage, or into another TLP, but not being on the PMC. I'd be less convinced on a project that wasn't previously open so that there was no way to know if committers had previously contributed; but for open source projects who join the incubator this is a great point. *shrug*. This neatly ties into the whole open source vs open development discussions. Some projects are more open than others. In fact you've helped me resolve a direction on my general problem in this area at Jakarta where we have a huge number of inactive committers (300) and PMC members (40) - inactive committers good, inactive PMC members bad. Oversimplification. As an example of inactive PMC members, consider excalibur. The excalibur PMC hasn't had to do much over the last few months except help the chair submit a board report or two and vote on a few releases. The entire PMC (as a PMC) is inactive and this is not a bad thing. If there is something needing PMC attention, all of a sudden enough of those people would jump right back into active gear to deal with it. I don't really understand where all the talking about what the right and wrong policies are is coming from. The right policy is a PMC deciding by consensus (or some other voting scheme, sometimes) what its composition should be. It seems we're looking to policy as a way to scale our processes, and I think that won't work. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Non-final materials in final ASF materials (was: Re: ActiveMQ and ServiceMix reports)
On Sat, Mar 18, 2006 at 07:41:04AM +, James Strachan wrote: BTW I CC'd the Geronimo PMC as this is an interesting dilema for the Geronimo folks too I'm not so happy with crossposting between public/private lists (private lists should be unused if possible) so I dropped that again...this is a fine example of something which IMHO should not be private discussion... On 3/17/06, Leo Simons [EMAIL PROTECTED] wrote: On Thu, Mar 16, 2006 at 12:10:50PM +, James Strachan wrote: On 3/16/06, Davanum Srinivas [EMAIL PROTECTED] wrote: So we could include the incubating ActiveMQ code inside an actual production Geronimo release - provided the ActiveMQ jars keep (their current name) of incubator-activemq.jar? If so thats great, we can start integrating the Apache ActiveMQ code into Geronimo ASAP - yay! I don't think the incubator is supposed to be telling the geronimo PMC what it can and cannot put into its releases. I think the incubator is supposed to be talking about the releases of incubating projects (like indeed, ActiveMQ) only. So the Geronimo PMC should decide - whether to stick with the old codehaus-activemq or the new incubator-activemq. (Maybe its a 'when' rather than 'whether') Yes I think so. Now, without my incubator PMC hat on (but as a user of and contributor to ASF software and part of its community) I think it totally sucks ass if production releases contain non-production stuff, unless it is *very* clear which parts are non-production stuff, they are not enabled or run by default, and all the appropriate warning signs (*use this at your own risk*) are added (Re: experimental modules in HTTPD, or experimental modules in the linux kernel). Geronimo 1.0 shipped with the codehaus version of ActiveMQ. Since then the code has moved into the incubator and its had heaps of bug fixes made to it (along with some nifty cool new features). So from a production standpoint; the incubator code is now better code, not worse. Okay...so my comment above is not very relevant (I thought 4.0 as opposed to 3.x meant big changes and hence less proven-for-production-ness)... So shipping with the codehaus code in future Geronimo releases would be a bad thing IMHO I agree. Chances are, some users or repackagers of geronimo stuff (there's a few of those now, right?) would just replace the codehaus stuff with the newest stuff and still try and call it geronimo. Mess would result. Your quote above (for people reading along: this is probably out of context at least a little, go read the entire thread) scares me a whole lot since it seems to mean you don't necessarily think the same way. Sorry, I'm not sure I follow Nevermind. We found out my concern did not apply :-) In the case of incubating projects, it may sometimes also be the case that IP vetting is not (properly) done yet, and that is stuff you really shouldn't ship at all (I don't know about ActiveMQ, I suspect it is all fine IP-rights-wise since it has been open source for so long). But validating the IP is all in order for a release is not something the incubator PMC is responsible for when it comes to software not under its review, that is something the PMC publishing the release is responsible for. Agreed - though I thought the IP/software grant stuff had to be sorted for any release from the incubator? I think so, but if I were a PMC member for geronimo I would still make sure to double check all this before +1ing a release. There's unfortunately a bit of a history around here for status files to not be up-to-date... One more question then... ActiveMQ 4.0 is long overdue - I get asked when its gonna be released everyday by someone somewhere :). We were originally hoping to release it last year when most of the development was done but then the incubation process started and we've been treading water a little waiting until we thought we could actually ship some release candidates then the full 4.0 GA. (Which is why there's not been as much developer discussion as last year; we've mostly been in bug fix mode for months waiting until we can release 4.0). Up to now I'd thought we could only do a 4.0 release after leaving the incubator. I remember last time I looked the incubator policy talked in terms that podlings could only do milestone releases. Though I just reread the policy document http://incubator.apache.org/incubation/Incubation_Policy.html and it doesn't seem to even mention that world any more. So I guess that means we could go ahead and start trying to do the 4.0-RC-* releases and try get the full 4.0 release out - provided the Incubator PMC approves the release and we release the code as incubator-activemq with all the necessary disclaimers to avoid any confusion to ensure users are aware the code is still in the incubator
Re: [POLICY] Lazy account creation
On Sun, Mar 19, 2006 at 09:51:40PM +, robert burrell donkin wrote: On 3/19/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: What we'll probably do is run it like we're running Harmony. The list of committers on the proposal are the people we expect to show up, but we won't be creating accounts by default - we'll need to have each person say yes, I'm ready and will be contributing immediately before making the account for them. this seems a useful tradition: is it too early to codified this into policy? Yeah, very much so. If Geir hadn't been running around like crazy for the first few months to handle the incoming patch stream it would not have worked. I think Harmony has 7 or so mentors who are all ASF members, which is quite a luxury. We also had an excuse of sorts to not set up accounts (eg it wasn't a completely concious decision from a community perspective) -- we wanted to sort out some of the legal stuff first. This made things easier to explain. We were also (deliberately) starting from scratch, whereas most projects around here start from a single existing codebase, and that is also a big difference. You can't just go and bring a bunch of people from an existing project in and remove their commit karma. I haven't committed anything to excalibur in months (I think) but I would be somewhat unhappy if a move to the FooBar organisation would mean I'd lose commit access (I use the code and sometimes I find a problem and then I want to just commit the fix to trunk). I think its sometimes a useful tradition to just go and do what seems right rather than what people wrote down as policy as long as you comply with the spirit and intent of the policy and don't mess up any of the tricky bits (like all the legal ones). But that is not so easily codified and perhaps as a written policy can lead to problems. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Process for becoming a mentor
On Wed, Mar 22, 2006 at 09:01:18AM -0800, Jason van Zyl wrote: Just poking around the incubator site and I see a responsibilities page for Mentors which is good but I don't see any criteria for being a mentor. I think we don't have very general ones for those, probably since its hard to agree on (I don't think I fully agree with the list you made, for example). Special casing things is much easier, like so... OpenEJB: snip/ ODE: snip/ ActiveMQ: snip/ At any rate I would like to be a mentor for these projects so what do I do from here? Since you're an ASF member and the relevant communities sound willing from your descriptions, what you do is sign up to the relevant mailing lists and get going! :-) I guess that these projects need to somehow communicate to the incubator that they want you as a mentor (in general its pretty much been along the lines of a we need help message to this mailing list followed by a here is help message from a new mentor followed by a cool message followed by a you're now an incubator pmc member, please subscribe to the pmc list message from the incubator VP to the new mentor). I think it's important that mentor's justify their position Really? Want to expand on that? I've previously assumed its implicitly something like I have some idea of what I need to do and I'm willing to help and coupled with consensus along the lines of this person can help us it is enough... and I think have done so above and so does the Incubator PMC approve a mentor for a project? I assume that's voted on like everything else but don't see that anywhere in the process of becoming a mentor. Yeah I guess its badly documented, most of it all is focussed on what the responsibilities of a mentor are...I suspect because we've only been in situations where we didn't have enough, and also because it often makes sense to have ASF members as mentors (for example they have access to various relevant info which is otherwise private) and the idea is that those should be trusted to know what they're getting themselves into :-) As long as there is consensus among the involved projects (I'm not too sure what the current community organisation is for the projects you mention, but I think there's a dev list by now for most of them) all the incubator PMC has historically done is welcome you aboard... cheers! Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] iPMC now with iMentor and free inSight (was: Re: Process for becoming a mentor)
Sorry, can't resist... On Fri, Mar 24, 2006 at 12:36:27AM +0100, Erik Abele wrote: Simple example: When the IPMC decides that you are a mentor for X then you don't have How cool is that? What's Erik doing on the iPMC? More than he's ever done on a PC! The new iMentor Core Duo can wear two hats at the same time! Yes yes, I'm a mac addict... - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the Incubator PMC to be more responsive
On Tue, Apr 11, 2006 at 08:20:00PM +0800, Gav wrote: I know *I* decided a few weeks ago not to spend any more time at any intersection between the wider geronimo community and the incubation stuff because its become obvious that my opinion on a variety of stuff doesn't mesh well with the apparent consensus within that community. I haven't gone so far as to set up an actual ignore filter on (activemq|wadi|servicemix|...) but I might as well have. I read your message sort-of by accident. Your opinion may not mesh well at the moment, but it needs to be continued to be heard I would have thought. Why? Endless discussions just annoy everyone...the ASF is a big place, and there is plenty of room for disagreement. And your vote is valued as is everyone elses. I don't have a vote on the direction of geronimo or the organisation of its community and I shouldn't have. If someone raises a vote should it not be compulsory to vote on it in some kind of way? Most certainly not. Maybe other incubator pmc members have a similar mail-reading behaviour. This surely is unacceptable behaviour. Excuse me? That's a rather bold statement... Why else is the Incubator PMC here but to sort out EVERY Incubator related Issue. The incubator PMC is for oversight of the incubator. PMCs are not there to do work. That's what we have volunteers for (committers and contributors and mentors and more). Blocking some issues whilst being active in only what you find interesting is not good is it. There is a difference between what a PMC has to do and what individuals on that PMC have to do. There is also a difference between having no spare time and blocking something. Blocking is when you vote -1, and even then it often isn't blocking. When you're a volunteer, doing what interests you (or what other motiviation you might have) is a perfectly healthy thing. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Status Report for Harmony (was: REMINDER: *** Board Reports DUE! ***)
(please drop harmony-dev from the CC list on replies. Thanks!) Hi Noel, Sorry for the lack of report for harmony so far (BTW, we should probably get Marvin to send out automated reminders to relevant (P)PMCs too, it should save you some nagging effort). The wiki is currently down, so I can't see what's up there right now or whether someone else already wrote something so I'm resorting to sending an e-mail; hope that's ok. cheers, Leo - Harmony status report - Harmony is going well, so well that it is not easy to sum up all the things happening. There is, however, currently nothing requiring board or incubator PMC attention. Highlights for the last quarter: * no releases. * We have welcomed one new PPMC member: * Tim Ellison * we have welcomed three new committers: * Mikhail Loenko * George Harley * Stepan Mishura and expect to add quite a few more in the next quarter. * we have received and processed several more bulk contributions from different parties, including for beans, regex, math, jndi, logging, prefs, sql, math(again), crypto, and rmi (twice), hundreds upon hundreds of unit tests, an eclipse plugin for doing harmony development, and more. Our framework for accepting these contributions (based on jira, svn, and faxes and documented on the harmony website) seems to be working well. * there was concern over a potential copyright infringement within our JCHEVM component. This concern has been addressed by receiving a code donation for the potentially infringing files, without having to resort to lawyers and to the mutual satisfaction of all parties and under the watchful eye of the Incubator PMC. * we have begun collaborating with the SableVM community, which has relicensed its VM under the ALv2 (the related previous potential licensing/copyright issues have been resolved without having to resort to lawyers and to the mutual satisfaction of all parties and under the watchful eye of the Incubator PMC). * we have seen a lot of discussion on how to do testing, how to use jira, etc etc, as more and more developers gear up to contribute to the project. These kinds of discussions are going well and the collaborative consensus-based process is emerging. * we have identified the (future) need for some serious build and testing server infrastructure but have not approached the infrastructure team about this yet. IBM is currently hosting a Maven Continuum server to run the harmony tests, and sending the results to our mailing lists. - On Sun, Apr 16, 2006 at 06:47:52PM -0400, Noel J. Bergman wrote: See: http://wiki.apache.org/incubator/April2006 *STILL* waiting to hear from ADF Faces, Agila, AltRMI, Felix, Harmony, Kabuki, and WebWork 2. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Incubator PMC to approve 3.0-M1 release of ServiceMix
On Wed, Apr 19, 2006 at 10:59:30PM -0400, Noel J. Bergman wrote: -1 Bill Stoddard is correct in his understanding of http://incubator.apache.org/incubation/Incubation_Policy.html#Releases. The fact that other people have voted +1 without verifying that the release adheres to Incubator policy is a bit disturbing, but that's why we have multiple sets of eyes on these things. More than a bit, if you ask me. People even asking for a vote for a release without a NOTICE file is like, seriously messed up. What is going on around here lately? LSD, puzzled(tm) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Incubator PMC to approve 3.0-M1 release of ServiceMix
Hey Dan, I wrote a long-ish e-mail about all this, but I don't think its going to help anyone. So I apologize for any and all confusion. Concretely... On Fri, Apr 21, 2006 at 01:05:33AM -0400, Dan Diephouse wrote: I am really confused by the reaction to this. I don't see any reason to be puzzled or upset. I don't want to make this a bigger issue than it is, but: 1. The project is incubating and this is the first time its done an Apache release. There are a lot of check boxes that need to be checked to make Apache happy. Overlooking a NOTICE file that almost no one looks at doesn't seem like that big of a jump to me. I can understand why you don't see that, but that viewpoint should change. With an M1 release, I think everyone was a bit more worried whether the damn thing worked at all. As we move toward a .0 release things will certainly get more cleaned up. 2. Incubating release don't need to conform to Apache policy as far as I understand it. Only to whats outlined in the release section [1]. Thats why Roller can release with LGPL dependencies. So in this light, the NOTICE file shouldn't be a hold up, no? Only -incubator instead of -incubating can. Using LGPL dependencies is about policy. This is about what is legal. Besides complying with policy, you need to comply with the law, which involves complying with the terms and conditions of a variety of licenses. As an example, ServiceMix redistributes jars under an apache license which have NOTICEs applying to them. Thus the appropriate attributions *must* then be kept around (so says the license), so not having notices and stuff in place means a license breach, which is not at all about policy. Its illegal. As another example, CDDL-licensed things explicitly prohibit getting rid of *any* legal notices (which is common sense anyway). Doing illegal stuff can get us and our users sued. Hope that clarifies things. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Incubator PMC to approve 3.0-M1 release of ServiceMix
James, dude, On Fri, Apr 21, 2006 at 07:15:48AM +0100, James Strachan wrote: On 4/20/06, Leo Simons [EMAIL PROTECTED] wrote: On Wed, Apr 19, 2006 at 10:59:30PM -0400, Noel J. Bergman wrote: -1 Bill Stoddard is correct in his understanding of http://incubator.apache.org/incubation/Incubation_Policy.html#Releases. The fact that other people have voted +1 without verifying that the release adheres to Incubator policy is a bit disturbing, but that's why we have multiple sets of eyes on these things. More than a bit, if you ask me. People even asking for a vote for a release without a NOTICE file is like, seriously messed up. What is going on around here lately? Thanks for volunteering Leo to add details of the NOTICE file to the Incubator release policy :) *sigh*. I feel like a broken record these days. Nowhere does any policy ever say you can do stuff which is not permitted by law or for which you have no license. To state the reverse in a policy would be rather, well, redundant. There is ample documentation out there on our websites (and more in the works) to help with complying with the law and various licenses. To give you an idea. I have volunteered to help with a less confusing contribution policy. You can find it at http://incubator.apache.org/harmony/contribution_policy.html I have also volunteered time and effort to help with a less confusing third party contribution policy, of which you can find a draft at http://people.apache.org/~cliffs/3party.html The result of these documents will be folded into the incubator policies as appropriate in due course (and I might very well be the person to take care of some of that), but we're not quite ready for any of that yet. Until that time, each and every project needs to figure it out on its own. I have previously written a whole bunch of documentation for different projects on how to do releases, eg, see some old info at http://wiki.apache.org/avalon/AvalonReleaseManagerHowto and I have also been helping out for several years now to get that kind of info on the central ASF website about this stuff, eg http://www.apache.org/dev/#releases which is referred to many, many times from the incubator website. The relevant section of that documentation (for this thread) is http://www.apache.org/dev/release.html#license which, I would think, is already quite clear. Thanks for volunteering to make it more clear. I wouldn't really know how. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The Process of New Committers
On Sun, May 14, 2006 at 10:32:50AM -0400, Noel J. Bergman wrote: Leo Simons wrote: Noel J. Bergman wrote: When a PPMC decides to vote, it should post a note to the Incubator PMC to let the PMC as a whole know about the vote. You mean before the vote, after the vote, before results are announced, after it, or is taking care of this with a CC on the request of the creation of an account enough? I mean that if you are having a vote, just let the rest of the PMC know about it. We don't vote in dark corners (discussing potential committers in private so as to avoid embarrassment and facilitate honest discussion, aside). The PMC is collectively responsible for all projects under Incubation, and ought to be kept aware of what is happening. Do you have a concern about that? Not at all! From your e-mail it sounded to me as if you had something more specific in mind (and frankly, it seems that incubating projects on a whole haven't been all to good at bubbling up enough info so I could imagine the need), I just wanted to make sure. with harmony we seem to have consistently had enough incubator PMC members active on the PPMC list to get enough binding +1s That's fine snip/ Ok, then we're pretty much on the same page already after all :-) ciao! LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Project templates
On Thu, Jun 08, 2006 at 09:15:25AM -0700, Justin Erenkrantz wrote: On 6/7/06, Paul Fremantle [EMAIL PROTECTED] wrote: I will try to get a template based on Maven 1.x ready for ApacheCon It probably makes far more sense to make that Maven 2.x. -- justin *cheer*! Go, Paul, go! :-) LSD, who loves it when a plan comes together... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Project templates
On Mon, Jun 12, 2006 at 06:02:42PM -0700, Jeremy Boynes wrote: robert burrell donkin wrote: On 6/7/06, Paul Fremantle [EMAIL PROTECTED] wrote: I will try to get a template based on Maven 1.x ready for ApacheCon It probably makes far more sense to make that Maven 2.x. both would be best a lot of projects are still maven 1. what would be great is a maven 2 ready maven 1 build as well as a maven 2 build. Paul's focus may be M1 as I think Synapse/Axis are using it. Tuscany is using M2 so if Paul wants to work on M1 I'm willing to come up with a similar template for M2 (I would propose as an archetype mojo). Would this be an appropriate thing to check into incubator SVN I would say so. , and if so where? incubator/public/trunk/template/maven[12] ? Sure! LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dublin Docathon
On Mon, Jun 19, 2006 at 04:15:57PM -0700, Cliff Schmidt wrote: On 6/19/06, Justin Erenkrantz [EMAIL PROTECTED] wrote: On 6/7/06, Cliff Schmidt [EMAIL PROTECTED] wrote: That was my plan as well; so I'm pretty flexible. I guess I'd probably prefer not to schedule anything formal on Monday morning, since some folks may still be getting in. How does Monday afternoon work? Works for me -- also probably works okay for those in U.S. helping remotely. I'll be in Dublin in the mid-morning. I'll plan (as I've also heard Robert say) to be working on docs most of Monday and Tuesday with whomever is there. It sounds like that will likely include Robert, Justin, Noel, Sanjiva, possibly Ross, and me. /me raises hand. Not sure I'll be typing much (I see ApacheCon as an RSI prevention week :) ), but I think I'll sit in, and maybe I can keep the coffee flowing... LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] CeltiXfire Project
(can you please fix your mailer to * not break email threading * wrap lines thanks!) On Wed, Jun 21, 2006 at 01:44:36PM -0400, Sakala, Adinarayana wrote: ? The one JSR mentioned above is 181 which I believe is part of Java EE and not the JDK, right? I belive JSR 181 is part of EE. Which JSRs are you referencing? JAX-WS 2.0 which i think is definetely part of JSE [2]. Ah, I thought we had that stuff already somewhere in ASF WS land. I guess we'll have two to choose from! :) * Official Build Systems What does this mean? I was requesting if there is an official apache continuous integration server like Continuum or Cruisecontrol or something else, we would like our project to be setup as well. If this is not something that is setup as part of standard process, i am happy to remove that part of request and deal with it later. No, apache doesn't tend to do official if we don't have to. We have hardware that PMCs can get 'slices' off for various tasks, we have a few machines that run gump which everyone is always welcome to participate in, and there's I think things in process to set up a shared continuum server. Jason is I think, involved, and as your mentor will probably help make those boxen useful to you guys when it becomes available. Its not something we need to deal with right now. LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New committers
On Wed, Jun 21, 2006 at 09:04:27PM -0700, Martin Cooper wrote: On 6/21/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 6/21/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Yah, I guess so. But, then follow the rest of the stuff on the new committers page that Jean sent out.-- justin thanks justin. sorry justin, for bothering you again... Or should we create a adffaces-ppmc list for the adf faces incubation? What do you *want* to do? What makes most sense? We didn't have one for the WebWork incubation, which I think is similar to the situation you are in with ADFFaces. We also didn't get clear direction on what we were supposed to do don't you love it when delegation actually works :) , so we just used the Struts PMC + initial committers as an informal PPMC to vote on bringing in new committers. That seems fine (especially if it worked well!) I think this is one such example where there is no good one size fits all answer. Eg, if you have lots of informal PPMC stuff to do, there's always the option of setting up a mailing list :) What's important is that a PMC at some point is involved in the decision (infra@ wants account requests coming on behalf of a PMC) and that the actual project community (which seems to usually not be 1-1 with any PMC in case of incubation) is happy with the decision process. (disclaimer: there are lots of important things :) ) LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] web site dropped the learn category
Hmm, I certainly didn't really miss them. Because... On Wed, Jun 21, 2006 at 03:43:22PM -0700, Jean T. Anderson wrote: Incubator web site navigation no longer has a learn category with links to these pages: http://incubator.apache.org/learn/ http://incubator.apache.org/learn/newcommitters.html basically duplicates http://www.apache.org/foundation/how-it-works.html#meritocracy http://incubator.apache.org/learn/mailing-lists.html basically duplicates http://www.apache.org/foundation/how-it-works.html#management + http://www.apache.org/dev/#mail http://incubator.apache.org/learn/releasemanagement.html http://www.apache.org/dev/#releases http://incubator.apache.org/learn/rules-for-revolutionaries.html Those have lived in a variety of locations throughout the years. I don't know if they're anywhere else at the moment. They should be on the web somewhere :) http://incubator.apache.org/learn/theapacheway.html This page doesn't contain anything substantial by itself. I think this happened accidently in the conversion to Anakia last winter. I guess so. I can easily restore this category and will do so unless somebody recalls that it was deliberately dropped. No, I don't think so. But since /dev/ and /foundation/ have improved so much since these docs were originally written (*years* ago), I think we shouldn't bother. I just checked, and apart from rules-for-revolutionaries I don't think there's anything there that we need to save which is not on the site elsewhere. ciao! LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Jini Project
Hey all, On Thu, Jun 22, 2006 at 11:29:46AM +0200, Mark Brouwer wrote: Niclas Hedhman wrote: On Wednesday 21 June 2006 19:19, Leo Simons wrote: What I'm missing is an idea of the interaction between jini.org and this proposed new apache project, and an idea of the interaction between the JCP process and the apache project. Eg is the apache project a (reference?) implementation of a bunch of JCP specs managed through jini.org (in which case I'd say it needs a new name), is it a 'full' move from jini.org to jini.apache.org, or something else? It has been discussed that jini.org will serve as a information portal, with links to docs, specs, implementations, the starter kit, and so forth. The Apache project will first be the center of coding of the starter kit, and other useful generic tools. Ok. Sorta makes sense. It has not yet been decided what exactly should happen to the specifications and related process (JDP). Many people like the JDP, but also recognizes the overhead needed to keep it running. One alternative that has been discussed is to let the Jini TLP manage the JDP (with a couple of amendments) as well. I read up on this JDP thing a little and I would suggest for starters that you keep all that in place as-is-now and re-evaluate later. It seems like a big thing to change, and perhaps after the new apache project is more 'established' and 'known to be what it is' and 'trusted' as successful the discussion will be easier (or simply moot since no-one wants any change :) ). I guess this means keeping jini.org around for a long time to come, and I think this means you need a name for [EMAIL PROTECTED] which is not jini :) Bringing the Jini specs (the community approved standards) into an ASF project without a JDP like process can IMHO be seen as monopolizing what is perceived as Jini. Whether that is a good thing or a bad thing is up to the reader ;-) Apache has a meritocratic process which is in many ways quite different from democratic (I imagine that with jini in 1999, 'democratic' meant less 'control' for sun than 'meritocratic') . I wouldn't want to switch from one to the other lightly! My personal stance is that it is an issue that is not urgent, and can be discussed through incubation. I disagree here, some people in the Jini community find it important to know in advance which way this is heading, e.g. to hedge their risks using or investing in this technology and determine their own future path. FWIW, moving things to apache in general has not meant an increase in risk for whatever it is that is moving. I would not worry too much :) LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STATUS] (incubator) Wed Jun 21 23:53:03 2006
On Wed, Jun 21, 2006 at 11:53:04PM -0400, Rodent of Unusual Size wrote: APACHE INCUBATOR PROJECT STATUS: -*-indented-text-*- Last modified at [$Date: 2006-02-05 04:40:19 -0500 (Sun, 05 Feb 2006) $] ^^^ This file is not maintained and has not been maintained for a *long* time. The last few edits were all me pointing to other places where we do status tracking. If there are no objections I'll get rid of it at some point (and ask Ken to disable the auto-mailer). LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New committers
On Thu, Jun 22, 2006 at 12:55:54PM -0700, Matthias Wessendorf wrote: What do you *want* to do? What makes most sense? well, MyFaces PMC is faster; but adffaces-ppmc has it's charme too. But... after adf is a subproject we'll need to delete this list. ^^^ archive/disable So, what is easier for you guys? Creating a mailing list is about 2-3 minutes of work, archiving it perhaps just a little more. Infrastructure is chronically lacking volunteers, but this kind of thing is nevertheless something that's ok to ask for :) I think we should take the time for creating a PPMC list. Should I bring it up to the INCUBATOR jira? Or the IPMC? Or Craig? who is our mentor. What's most important is that there's agreement before there's a request for resources. Get agreement somewhere ([EMAIL PROTECTED] is probably the wrong forum for that :) ), *then* file a jira issue as documented on www.apache.org/dev/. Craig can do that, but others can as well. As long as its clear the request is inline with policy and after a PMC agreed on it. The incubator PMC is on this list and some individuals have offered opinions; I don't think you need to ask for formal approval from us. The use of PPMC lists is established practice :) LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Various
Hani, (I'm a big BileBlog fan. I'm ever so upset that Geir always gets named when it comes to Harmony while I and more importantly quite a few others also pour lots of effort in too. I did a lightning talk at ApacheCon Las Vegas titled The ASF sucks. I had 5 minutes, I could've gone on for 30. Lots of fun. I think most people liked it. I'm a committer and member and things like that around here. Most people around here appreciate some good roasting or bile as much as the next person.) On Fri, Jun 23, 2006 at 05:52:51AM +0100, Hani Suleiman wrote: I'm fairly astounded by the amount of email generated due to my name being on the initial committer list. I would say I was a little surprised. This e-mail of yours is also a bit of a surprise though. Nevertheless. To respond to this actual email. www.apache.org says The Apache projects are characterized by a collaborative, consensus based development process, an open and pragmatic software license, and a desire to create high quality software that leads the way in its field. We consider ourselves not simply a group of projects sharing a server, but rather a community of developers and users. Some of the keywords there relevant to this thread are collaborative and community. We expect many simple things from each other such as * showing respect for your peers * making sure your e-mails to apache mailing lists are PG-13 and preferably suitable for all ages * not making unfounded assertions * never flaming other people, especially not in public * no trolling or flaming in general Being frank and undiplomatic is fine. I'm frank and undiplomatic all the time. Saying some piece of software is bad is fine (if backed up by technical argument or reference). For example if I mention that I think that SOAP is a bad idea in the first place (I do) and that I think that all implementations of it today all have rather serious problems (for example, scalability is simply still a joke. 50 than 3 requests per second is still abonimable. I want 5000, and mind you, when running on my laptop), that is fine. But e-mails like this one basically do fit the 20-year-old textbook definitions of trolling and flaming that the usenet people invented way back. I won't bother picking it apart to point this out, I'm rather confident you know exactly what I mean. Being frank and undiplomatic again, we don't have all that many people around here who repeatedly display that kind of behaviour on apache mailing lists, and that's not about to change. Now, could we please get back to more interesting things? LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Withdrawing Kabuki from Apache Incubator
Hi Andy, Thanks for being frank and open. Changing your mind can be such a hard thing to do, and changing the minds of lots of people is even harder. On Sat, Jun 24, 2006 at 02:55:56PM -0700, Andy Clark wrote: Thanks for your extreme patience in the matter of the proposed Kabuki contribution to the Apache Incubator. ... we have made the difficult decision to withdraw Kabuki from consideration for incubation at Apache. ... For anyone that is either frustrated or concerned by this decision, please feel free to contact the President and CTO of Zimbra, Scott Dietzen[2], as he made the ultimate decision and he would like to understand your concerns. One nitpick: I can see how the decision Scott makes is to not donate code to the ASF on behalf of Zimbra (or himself) and not execute any grants and the like. But the President of a company does not decide to stop the incubation of an apache project. The incubating community does that (and I take the we in the rest of your message above to be that community), or perhaps the Incubator PMC. Of course the point is kinda moot since the idea was to start Kabuki with a donation from Zimbra and it seems there's not all that much of a Kabuki community right now, but its only kinda moot, and not completely :) cheers! LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
3 cheers for docathon-ers!
(Hurray! Hurray! Hurray!) Heya gang, just went to read through a bunch of the new incubator site. I think y'all did an amazing job this week; things are so much clearer now. Many thanks! (I'm sure that's on behalf of everyone 'round here as well as future podlings) cheers, Leo PS: now that the site looks so good, it sorta feels like we need someone to redesign the logo for a bit too...do we have any takers? :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Don't +1 lightly (was: Re: [VOTE] Incubator PMC to approve the 3.0-M2 release of ServiceMix)
On Sun, Jul 02, 2006 at 07:08:48PM +0100, ant elder wrote: A (non-binding) +1 from me to say thanks for the Tuscany votes. Huh what? Exactly what semantics attach to a +1 is always a muddy discussion, but IMNSHO they really ought not be thanks for something unrelated. Its utterly confusing. Thanks! LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
