Karma Request
I am an IPMC member and mentor for the new Streams project in the Incubator. Can I please get karma to edit the Incubator wiki (username CraigMcClanahan)? Craig
Re: [Vote] Graduate Trinidad (to an Apache MyFaces subproject)
On 4/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Incubator PMC, The Trinidad community believes that Trinidad is ready for graduation, as evidenced by this vote (see [1]). +1 Craig (Mentor) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Difference between Maven repository and dist directory
On 3/15/07, Jochen Wiedmann [EMAIL PROTECTED] wrote: On 3/16/07, Craig McClanahan [EMAIL PROTECTED] wrote: [...] using the normal Apache distribution network to make them available, and (for Maven users) not even making it visible that you're using a non-official release because they didn't have to configure any repository, you blur the distinction so much that it's going to get totally lost. If we accept this argument, then we naturally need a place where the incubating releases can be retrieved from; hence, the m2-incubating repository. If we do not accept this argument, then AFAICT we are basically making the incubating projects cannot do releases policy inoperative. There's a flaw in your argumentation, though a more practical. I can understand that the Apache dist directory is something reserved for certain artifacts. Fact is, the ibiblio repository (as opposed to the incubator repository) is not. The ibiblio repository is specifically designed to hold artifacts of all kinds, if the license permits. There are all kind of jar files of all kind of sources. If artifacts are in the designated incubator repository, then nothing prevents external users from uploading them to Ibiblio, which is usually done sooner or later. (If the artifacts are actually in use.) In other words, the simplest way for me to hijack an Apache release is to put a worm in it and push it to ibiblio myself? Doesn't sound like a very trustable scenario. In other words, your intention that users have to configure any repository is lost. You cannot prevent that. Or are you telling me that the owner of the incubator artifacts (typically the ASF) reserves particular distribution rights, which are limiting the ASL? All you achieve is that the POM ifiles of ncubator artifacts typically have a lesser quality, because they aren't maintained by the project owners. Apache's current policy is that we allow incubating podlings to publish incubating releases to a special Maven2 repository that we host, which means downstream users are required to add a repository setting in order to see these artifacts. That's enough warning (in my thoughts) that they are depending on an incubating project's output. If the artifacts are ending up in the public repository anyway, that means: * Some Apache folks are violating our own rules by pushing these artifacts into our own dist directory (which gets mirrored there). * Ibiblio is accepting Apache artifacts posted by folks other than the originating projects, which seems like a pretty grave security concern. Jochen Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Difference between Maven repository and dist directory
On 3/16/07, Daniel Kulp [EMAIL PROTECTED] wrote: Craig, the point is that downstream users may not be required to add a repository setting. If I depend on A, and A depends on IncubatorB, I would get IncubatorB without needing a repository setting if the pom for A has that setting in it. An argument for dumping the entire set if distinction between incubating and non-incubating projects, instead of just some of them. That's pretty much my point. If there are huge use cases where users DON'T have to put a repository entry in, then why are we bothering having a separate repository? That's bandwidth/processes/etc.. on p.a.o that we consume for no reason. Push that to central. Performance concerns should not drive policies. Policies should drive practices, which should drive efficient implementations. The policy I'm most concerned with in this thread is whether incubating project releases are official Apache releases, that provide the ASF legal protections to the authors, and assurances to the downstream users that ASF has done its usual vetting of these releases. If we indeed want that to be the result, then sure ... get rid of the incubating repository, get rid of the restrictions on posting incubating releases to the central repository, and so on. But also get rid of all the other useless crap (requiring incubating in version numbers etc.) that does not accomplish anything useful in this scenario. Is everyone in ASF willing to be comfortable with the ASF stamp of approval on a project that might still be in the process of vetting code provenance, or still checking licenses, but chooses to do an incubating release anyway? J. Daniel Kulp Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Difference between Maven repository and dist directory
On 3/16/07, Yoav Shapira [EMAIL PROTECTED] wrote: Hi, On 3/16/07, Craig McClanahan [EMAIL PROTECTED] wrote: Is everyone in ASF willing to be comfortable with the ASF stamp of approval on a project that might still be in the process of vetting code provenance, or still checking licenses, but chooses to do an incubating release anyway? I don't think that's the question. The question I see is: is everyone in the ASF willing to agree that the Incubator PMC has sufficient oversight processes in place when approving podling releases? If so, great, we're done, and if not, we need to fix the Incubator release vetting process. If we buy into this (and I'm not totally convinced, but it is a separate question), then we're still not done ... we have a bunch of other hoops that we still force on incubating podlings that should be removed as well. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Killing the incubator m2 repository
On 3/16/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 3/16/07, Davanum Srinivas [EMAIL PROTECTED] wrote: Sorry, i lost you. this whole we need podling artifacts in central repo because right now you are putting our user through a meat grinder has no basis in fact. Am asking for JIRA issues, email threads that show that this is indeed a serious issue and not just a made up issue. Show me the evidence is what i am asking. By comparison, I've now asked three times if there was any specific situation that necessitated the policy of a separate repo for Incubator artifacts. Thus far, I've received no answer whatsoever. Was this policy simply plucked out of thin air (i.e., a made up issue) or was there a specific situation that prompted it? Part of the original reasoning was that podlings could not make an official Apache release because they weren't actually projects yet, and we didn't want downstream users to assume that they were. However, it's pretty tough for a podling to build a community if they can't release anything at all -- so a compromise mechanism was set up that required podlings to use things like -incubating in both the version numbers and filename artifacts of their releases, *and* to avoid using standard Apache release mechanisms ... essentially, a podling release is more akin to a nightly build that you might grab from p.a.o/builds, meaning that you deliberately have to look there for it. For Mavenites, the corresponding concept was a separate repository that downstream users would (theoretically -- as has been pointed out, it doesn't really work for transitive dependencies) have to explicitly indicate their willingness to depend on incubator podling releases, by adding the incubator repository to their POMs explicitly. But times change. Apparently now people think that since the Incubator PMC has binding votes on podling releases, then these things *are* indeed official releases, providing both the usual legal protections to PMC members who voted for it, and assurance to downstream users that things like code provenance have already been vetted. If we buy into this philosophy, then a restriction on publishing artifacts to p.a.o/dist and the mirrors, and having a separate incubator repository for them, are ridiculous and should be removed. My grumpiness is over the fact that *only* removing these two restrictions only goes half way. If podlings can create official ASF releases, then they should also not be subject to any restrictions like -incubating in artifact names or version numbers. They are either official releases or not. They can be relied upon by downstream users or they cannot. If we're going to go this direction, go *all* the way, and erase any distinction between a podling release and a TLP release, since we would be claiming that there is no legal difference between them, nor any potential concern for downstream users about code provenance. Anything in between (such as only doing what the vote proposes) leaves us sending totally confusing mixed messages. Craig Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Castor - http://castor.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Should we treat incubator releases differently to normal releases
On 3/15/07, Henri Yandell [EMAIL PROTECTED] wrote: Two parts to the vote: ONE: Should Incubator tarballs go in the normal place (and thus mirrors). [ ] +1 [X] -1 TWO: Should there be an Incubator maven repository. [X] +1 [ ] -1 Vote to last a week. Unless people are bored of replying, or it's a flamefest, or we're too busy pursuing eternal enlightenment and running free in the mountains. My reasoning goes like this: we make incubating projects go through some special hoops like wanting incubating as part of the artifact filenames, in an effort to warn people that these things are *not*, in fact, official Apache releases (whatever that means). When you are using the normal Apache distribution network to make them available, and (for Maven users) not even making it visible that you're using a non-official release because they didn't have to configure any repository, you blur the distinction so much that it's going to get totally lost. If we accept this argument, then we naturally need a place where the incubating releases can be retrieved from; hence, the m2-incubating repository. If we do not accept this argument, then AFAICT we are basically making the incubating projects cannot do releases policy inoperative. A secondary benefit of the approach I recommend is that access to the Apache distribution channels are a carrot towards actually graduating. The corresponding stick (getting thrown out of incubation) hasn't happened enough to be considered a viable threat (and the cases that it has occurred have been over community issues, not they just aren't getting around to graduating cases). Hen Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Should we treat incubator releases differently to normal releases
On 3/15/07, Jeremy Boynes [EMAIL PROTECTED] wrote: Podlings cannot do Releases because they are not Projects established by the Board. However, the artifacts produced by them are voted on and approved by the Incubator PMC and hence are official Releases by the Incubator Project and hence by the ASF. This is essential if the artifacts and their authors are to receive any legal protection though being product of or actions by the Foundation. And therein lies the rub, I believe. It was my understanding that we (ASF) did *not* want to extend such protections to the artifacts produced by podlings, because they were *not* in fact part of the ASF yet. If these are indeed going to be official releases, we should totally dispense with the requirements for -incubating in artifact filenames and version numbers, let them announce the releases on announcements@ mailing lists, and all the other accouterments of a normal project release. If they are not going to be official releases, the state of the world before this vote seems to make sense. I can likely be persuaded to the these really are official releases policy position (although it would reduce the role of the incubator to just community issues, and I wonder about our comfort level with extending the legal protection in cases where code provenance issues might not have been cleared up yet). But, if we're going to go there, lets go *all* the way there instead of one baby step represented by this vote, which would result in policies undermined by practices. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] approve the release of Trinidad's Maven plugins (1.0.0-incubating)
On 2/21/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: The Trinidad community voted to release the the maven plugins as a 1.0.0-incubating release. These plugins are required for the maven build of the core code of the Trinidad Podling. To fulfill the incubator guides, we like to ask you guys, the Incubator PMC, for a permission to release those maven plugins. There were seven +1 votes and the vote has been tracked at [1]. (5 binding) The plugins are documented at [2] and our release notes inculde the bugs that have been addressed ([3]). The plugins are available as source and bin inside the following m2 staging repo (see [4]). +1 One general comment ... it would be good if the website referenced at [2] actually included usage instructions for how to actually use the plugins. Craig Thanks Matthias [1] http://tinyurl.com/3dpa5g [2] http://incubator.apache.org/adffaces/plugins/index.html [3] http://wiki.apache.org/myfaces/ADF_Faces/plugins_release_1_0_0-incubating [4] http://people.apache.org/~matzew/stage/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Incubate new podling, River (nee Braintree, nee..., nee Jini)
On 12/20/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: [ ] +1 Accept River as a new podling as described below [ ] -1 Do not accept the new podling (provide reason, please) +1 Craig
Re: voting was Re: [PROPOSAL] Ivy
On 10/23/06, david reid [EMAIL PROTECTED] wrote: Davanum Srinivas wrote: it's a hint that the voter is a pmc member. *sigh* Really, no, seriously, you're telling me that the PMC can't be trusted to count votes from it's members and others it feels are qualified? Wow... Seriously, pointing out such differences just splits the community. Hey, my vote counts! Yours doesn't! After seeing the people involved in the incubator at AC US, I'm pretty sure they were all past the stage of being impressed by such things. We should get over ourselves. There is another viewpoint here that had better be considered, though ... we invite the community to participate in these votes, and I can guarantee you that the majority of people who are reading the vote thread have never bothered to read the rules on what votes count (indeed, they are more likely than not to be unaware there IS such a thing as binding versus non-binding votes). Are you really preferring that we HIDE the fact that their (non-PMC members) vote doesn't officially count (although it does influence consensus), and have them go away pissed off because they thought they were misled? Craig
Re: Maven 2 repo for incubating project releases?
On 7/29/06, Andrus Adamchik [EMAIL PROTECTED] wrote: On Jul 29, 2006, at 7:12 PM, Justin Erenkrantz wrote: AIUI, the concern raised by Noel was that Maven never indicates the artifact version number. Therefore, even if it had 'incubating' in there somewhere, it wouldn't matter as no one would know it was under incubation. I guess I am with Jukka on that. From my limited Maven experience (correct me if I am wrong), Maven 2 is very explicit about versions. You have to specify it at least in the parent POM of the project: dependency groupIdabc/groupId artifactIdxyz/artifactId version1.0-incubating-SNAPSHOT/version /dependency The only case I can think of where you don't set an explicit version is when you get a dependency indirectly (as a dependency of another dependency). Still the files (artifacts) you end up downloading as a result will have incubating in the file name, and the folder name of the local repository. In this later case if a user doesn't pay attention (s)he will not be aware that something was downloaded from Apache at all (incubating or otherwise); if (s)he does - incubating label is clearly visible. There are (at least) two scenarios where I believe there is legitimate cause for concern with the way Maven does things: * You can declare a dependency on a particular groupId/artifactId combination *without* specifying a version number. The meaning is something along the lines of take the latest version you know about. Thus, you could unknowingly be declaring a dependency on an incubating project if incubating is only present in the version number. This can be alleviated by requiring that incubating be part of the group or artifact identifier, which I think would be a really good idea. * The harder problem is that Maven2 does transitive dependency identification. If you declare an explicit dependency on module A, which itself has a dependency on incubating module B, you're not going to know that you are depending on incubating code unless you are very careful about analyzing the entire set of POMs for all your dependencies (or you generate the website and analyze the dependency report that is produced there). In short, direct dependencies can be addressed by an Incubator policy that requires incubating in the group or artifact identifiers of Maven POMs. The harder problem is indirect dependencies. Craig McClanahan Andrus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of ADF Faces Incubation Request
On 3/8/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Craig McClanahan wrote: On February 19, 2006, Manfred Geiler (MyFaces PMC Chair) sent a candidate podling proposal to [EMAIL PROTECTED] Should have been to general@incubator.apache.org Agreed ... it was later linked to a posting there. Could you please let us know the current acceptance status of this proposal into the Incubator? The proposal didn't have any discussion (at all, that I can find), most likely because it was posted to the wrong list. Not that I believe that people deliberately ignored it, but the target audience was much smaller. The proposal said, [We] ask that you accept the following proposal for a new project at Apache, implying that the Incubator PMC was being asked to vote on it. However, a separate e-mail had noted that the MyFaces PMC has already voted to accept the project. My understanding of the incubator process is that the Incubator PMC still has to vote to accept a podling (see second paragraph under Acceptance at [1]), and that the positive vote of the intended destination TLP (MyFaces in this case) is a prerequisite. Is that understanding correct? If so, has there ever been such a vote (my request to be added to the Incubator PMC, due to being mentor for the ADF Faces contribution, will eventually let me find that out for myself). If an I-PMC vote is required and has not occurred, can we please do so? If a vote isn't required, I can just go ahead and start on the administrivia required to set things up. --- Noel Craig [1] http://incubator.apache.org/incubation/Process_Description.html
[jira] Created: (INCUBATOR-16) Set Up Mailing LIsts for ADF Faces Podling
Set Up Mailing LIsts for ADF Faces Podling Key: INCUBATOR-16 URL: http://issues.apache.org/jira/browse/INCUBATOR-16 Project: Incubator Type: New Feature Reporter: Craig McClanahan Per the ADF Faces proposal[1] that was accepted by the MyFaces PMC, please set up the following mailing lists for this podling: * [EMAIL PROTECTED] * [EMAIL PROTECTED] * [EMAIL PROTECTED] * [EMAIL PROTECTED] All of these lists should be available for unmoderated subscription by the public, require moderator acceptance for posts from non-subscribed addresses, and be archived according to standard policies. Initial moderator should be me ([EMAIL PROTECTED]), although we will likely add others later. [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg11166.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (INCUBATOR-17) Set Up SVN Repository for ADF Faces Podling
Set Up SVN Repository for ADF Faces Podling - Key: INCUBATOR-17 URL: http://issues.apache.org/jira/browse/INCUBATOR-17 Project: Incubator Type: New Feature Reporter: Craig McClanahan Per the ADF Faces proposal[1] that was accepted by the MyFaces PMC, please set up a Subversion workspace named adffaces under the Incubator SVN root directory. Initial committers (with current Apache accounts) shall be: * Craig McClanahan craigmcc * Matthias Wessendorf matzew * Martin Marinschek mmarinschek * Bruno Aranda baranda We will also be adding several additional developers as soon as their accounts have been set up (documented via a separate JIRA ticket). [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg11166.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (INCUBATOR-18) New Committers for ADF Faces Podling
New Committers for ADF Faces Podling -- Key: INCUBATOR-18 URL: http://issues.apache.org/jira/browse/INCUBATOR-18 Project: Incubator Type: New Feature Reporter: Craig McClanahan Per the ADF Faces proposal[1] that was accepted by the MyFaces PMC, please set new user accounts for the following committers: * John Fallows [EMAIL PROTECTED] * Jonas Jacobi [EMAIL PROTECTED] * Omar Tazi [EMAIL PROTECTED] * Adam Winer [EMAIL PROTECTED] Each of these individuals should have filed an ICLA already, and each should be granted commit access to the Incubator adffaces podling SVN repository created by issue INCUBATOR-17. [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg11166.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (INCUBATOR-17) Set Up SVN Repository for ADF Faces Podling
[ http://issues.apache.org/jira/browse/INCUBATOR-17?page=comments#action_12369595 ] Craig McClanahan commented on INCUBATOR-17: --- I forgot to mention that commit notifications for this repository should be sent to the new [EMAIL PROTECTED] maililng list being set up under INCUBATOR-16. Set Up SVN Repository for ADF Faces Podling - Key: INCUBATOR-17 URL: http://issues.apache.org/jira/browse/INCUBATOR-17 Project: Incubator Type: New Feature Reporter: Craig McClanahan Per the ADF Faces proposal[1] that was accepted by the MyFaces PMC, please set up a Subversion workspace named adffaces under the Incubator SVN root directory. Initial committers (with current Apache accounts) shall be: * Craig McClanahan craigmcc * Matthias Wessendorf matzew * Martin Marinschek mmarinschek * Bruno Aranda baranda We will also be adding several additional developers as soon as their accounts have been set up (documented via a separate JIRA ticket). [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg11166.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (INCUBATOR-19) Set Up JIRA Project for ADF Faces Podling
Set Up JIRA Project for ADF Faces Podling --- Key: INCUBATOR-19 URL: http://issues.apache.org/jira/browse/INCUBATOR-19 Project: Incubator Type: New Feature Reporter: Craig McClanahan Per the ADF Faces proposal[1] that was accepted by the MyFaces PMC, please set a JIRA project named MyFaces ADF-Faces for issue reporting. Notification emails should be sent to the new mailing list [EMAIL PROTECTED] being set up in ticket INCUBATOR-16. [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg11166.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (INCUBATOR-17) Set Up SVN Repository for ADF Faces Podling
On 3/8/06, Garrett Rooney (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/INCUBATOR-17?page=comments#action_12369600] Garrett Rooney commented on INCUBATOR-17: - If you want infra people to see these issues it probably makes more sense to file them in the Infrastructure project, not the Incubator project. That's what's typically done when setting up new projects. You also need to have an incubator status page set up at http://incubator.apache.org/projects/ before any infrastructure can be set up. Thanks Garrett ... I'll shift over the relevant stuff. Sure wish this was written down in the docco for mentors :-). Yah, I know, me complained, me can fix it :-). Craig Set Up SVN Repository for ADF Faces Podling - Key: INCUBATOR-17 URL: http://issues.apache.org/jira/browse/INCUBATOR-17 Project: Incubator Type: New Feature Reporter: Craig McClanahan Per the ADF Faces proposal[1] that was accepted by the MyFaces PMC, please set up a Subversion workspace named adffaces under the Incubator SVN root directory. Initial committers (with current Apache accounts) shall be: * Craig McClanahan craigmcc * Matthias Wessendorf matzew * Martin Marinschek mmarinschek * Bruno Aranda baranda We will also be adding several additional developers as soon as their accounts have been set up (documented via a separate JIRA ticket). [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg11166.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status of ADF Faces Incubation Request
Ping? Is this thing on? Craig On 2/28/06, Craig McClanahan [EMAIL PROTECTED] wrote: On February 19, 2006, Manfred Geiler (MyFaces PMC Chair) sent a candidate podling proposal to [EMAIL PROTECTED], cc'd to the MyFaces developer list[1]. Could you please let us know the current acceptance status of this proposal into the Incubator? Thanks, Craig McClanahan (Proposed mentor for the ADF-Faces Podling) [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg11166.html
Status of ADF Faces Incubation Request
On February 19, 2006, Manfred Geiler (MyFaces PMC Chair) sent a candidate podling proposal to [EMAIL PROTECTED], cc'd to the MyFaces developer list[1]. Could you please let us know the current acceptance status of this proposal into the Incubator? Thanks, Craig McClanahan (Proposed mentor for the ADF-Faces Podling) [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg11166.html
Fwd: Please add me to the Incubator PMC
Broadening the receiver list in case the PMC list is getting moderated and the original message is not visible. Craig -- Forwarded message -- From: Craig McClanahan [EMAIL PROTECTED] Date: Feb 28, 2006 3:50 PM Subject: Please add me to the Incubator PMC To: [EMAIL PROTECTED] In preparation for my role as mentor for the ADF Faces proposal from the MyFaces community, and my role as an ASF Member, I hereby request being added to the Incubator PMC. Craig McClanahan
Re: Starting a java specs project
On 12/30/05, Alan D. Cabrera [EMAIL PROTECTED] wrote: Looks good to me. Guys, should we not begin to create a specs project in Jakarta? It seems that we have a consensus. Well, maybe ... I have a couple of concerns about the practicalities here. First, at least for the set of standards that are JCP related (non-JCP standards will likely have a similar set of issues, however), let's divide the world of specs we might be interested in having API classes around for into two groups (a) JSRs that Apache also hosts implementations for (MyFaces, Tomcat, Geronimo, Pluto, a bunch of the web service ones, etc.) (b) JSRs that Apache does not host implementations for, but where projects might want to rely on implementations acquired elsewhere. For group (a), the current practice is to host the API classes inside the project that is also providing the implementation. That makes sense to me for a number of reasons, but the most important ones revolve around ensuring that the produced classes comply with the corresponding TCK tests to ensure spec complance. The people most familiar with the requirements, and the most motivated to watch for potential compliance-breaking changes, will be the folks doing the corresponding implementation. Even in the current situation, it's really easy for a committer to try to tweak API classes in a manner that will not be compatible ... but these cases get caught quickly, because the in the know developers are going to be watching. Note that if a primary goal of this effort is to have a common repository of API jars (and that's certainly a worthy goal), it doesn't require a separate project to accomplish that -- simply a mechanism for cooperation on what repository to post API jars into. (However, even there, we'd need to check licensing in each case whether the API jar can be published separately.) For group (b), the latter consideration will also apply -- the API classes for a JSR are licensed as described in each individual JSR. If a primary goal of this effort is to encourage the development of a community interested in the general issues of implementing Java based standards (also a worthy goal), that's great ... but it does not seem to me that sharing API code is a prerequisite for accomplishing this. Craig What are the next steps? Regards, Alan On 12/30/2005 6:14 AM, James Carman wrote: Why not do like we do with the commons? spec-javamail -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Friday, December 30, 2005 9:08 AM To: general@incubator.apache.org Cc: [EMAIL PROTECTED] Subject: Re: Starting a java specs project On 12/27/05, Hiram Chirino [EMAIL PROTECTED] wrote: Hi, I think this would be great! I know it's silly, but I get annoyed at the fact that many of the J2EE spec jars that I use from apache have geronimo- in the jar name but It's just the ASL 2.0 spec jars that I'm using and not really a geronimo implementation. In general, I think that this would make a good TLP since it would provide a good area for cross project involvement. [presuming it was stored at Jakarta Specs] Do you think they should be apache- or jakarta-, or either would be fine? Would 'jakarta-spec-javamail' be too much of a mouthful? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX Toolkit Framework Proposal
On 12/20/05, Sam Ruby [EMAIL PROTECTED] wrote: Sylvain Wallez wrote: Adam Peller wrote: [snip] So the questions are: - is the ASF the place for Eclipse extensions? I don't deny the ability to _existing_ project to host their tooling, but this isn't the case here. As I mentioned, I was involved with these discussions. The ASF doesn't tend to make these types of decisions based on the technical aspects of a project. What impressed me about the people who were proposing this is that they were sincerely interested in the Apache License and collaboration model. Belief in the Apache collaborative development model should certainly be a prerequisite for acceptance into the Apache community (to me, that's the thing that binds ASF as a community more strongly than anything else). But that, by itself, is not a compelling argument for combining these two particular subprojects into a single proposal. That strikes me as bad software engineering, as well as bad social engineering. From a software engineering viewpoint, focusing on a single tool as a delivery vehicle will tend to bias architectural and implementation decisions towards what is easy to express in that particular tool. It would leave aside the little detail that not everyone interested in AJAX will be using that tool, or will even be using Java. I'd like to see the various AJAX libraries, and the communities around them collaborate more ... but that problem space is plenty big enough without figuring out bindings to tool widgets, for a particular platform, at the same time. From a social engineering viewpoint, this particular combination of subprojects would create a perception that Apache's support for AJAX is all about what you can do in Eclipse. That's too limiting a scope for what we should be trying to achieve. A better answer might be to separate the tooling aspects from the framework aspects, and consider building a community around tools for building AJAX based applications in general, that consumes this technology but unoubtedly others as well, rather than trying to combine oil and water in the same project. Craig
Re: JDO2 Snapshots
On 8/8/05, Noel J. Bergman [EMAIL PROTECTED] wrote: Roy T. Fielding wrote: Snapshots are not releases. Releases require three binding +1s, a majority of positive votes, and a verifiable signature. I think it is absurd for any project to be distributing snapshots to end-users since it bypasses our mechanism of oversight. And this is true for all projects, not just Incubator projects. So I guess we should banish the concept of nightly builds of any Apache project? :-) More seriously, I agree with your subsequent comment about putting things into repositories that get downloaded automatically (without the user necessarily understanding the provenance of what they are downloading) is crossing the line. When I manually download a nightly build, I should have enough sense to understand what I'm doing (as well as what the incubating adjective in the filename means). Expecting me to go examine all the individual dependency downloads my build script does, every single time, is a bit much. Craig In contrast, I don't mind an incubating project making verifiable releases with proper voting and the appropriate disclaimers. And this is something that we do permit. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Derby as sub-project of Apache DB
On 7/20/05, Jeremy Boynes [EMAIL PROTECTED] wrote: I believe Derby has demonstrated Apache's community values and is ready to graduate. +1 +1 as well. I've been lurking on the various Derby lists, and am satisfied that the community gets it what it means to be an Apache project. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] beehive v1 milestone 1 release
On 5/28/05, Eddie ONeil [EMAIL PROTECTED] wrote: Putting [EMAIL PROTECTED] back on the thread. Noel, Geir, or Craig, can you confirm for everyone that we must pass the JSR 181 TCK before calling a release 1.0-final? If the release includes code that claims to implement JSR181, then yes it does (just like any other implementation of any other JSR). If you released the non-JSR components separately, they would not be under any such restriction. Thanks. Eddie Craig On 5/27/05, Jeremiah Johnson [EMAIL PROTECTED] wrote: Note that I narrowed the scope of my opinions to beehive-dev, so if Craig, Noel, etc. are watching from general@incubator.apache.org, they may not have seen your comments, Eddie. - jeremiah -Original Message- From: Eddie O'Neil Sent: Friday, May 27, 2005 8:42 PM To: Beehive Developers Subject: Re: [vote] beehive v1 milestone 1 release One other thing -- if someone (Craig, Noel, Geir, etc) can explain otherwise (that we can go -final without having passed the TCK) definitely let us know. The sooner we do such a release, the better! Eddie Eddie O'Neil wrote: Jeremiah-- It is my understanding after having talked to Craig and others who have been involved in the process of implementing a JSR before that we *can't* do a release of a JSR implementation until the spec is final. At this point, JSR 181 is not final, and as such, we can't say we're a final implementation of it. The process of getting the TCK to pass the Beehive WSM implementation is something that we're starting through the appropriate Apache channels. As far as judging WSM, my understanding is that should be done against the TCK, which means that we need to wait for it to be public before we can pass it. :) Eddie Jeremiah Johnson wrote: I am not a committer, so I can't vote. I do have an opinion that I would like to express about the release. In the 'beehive release status' email from May 19, it said that we're not able to go for a 'Final' release as the JSR 181 TCK is not yet public. It is unclear when the TCK will be public, so I disagree with the logic of waiting for a final release. It is unclear (to me) if the TCK will even be for the version of JSR 181 that WSM has been implemented against. There is a version of the JSR 181 that has been voted final and Beehive WSM has been coded according to the current status of JSR 181. In looking at the JSR 181 status, I see that Sun has been 'assured by the spec lead that both [of their concerns] will be address quickly'. At least one of those concerns (full alignment with JAX-RPC 2.0) will probably result in changes to JSR 181 and the TCK. If the TCK isn't available now, then it seems logical to me that the Sun changes will be incorporated into the TCK before the TCK becomes public. (Note that even though I work at BEA - I have no connection to the JSR 181 spec and no idea what the status of the TCK is). The cycles that seem possible to me could just continue to push 1.0 Final. It seems sensible to me to be voting on going 1.0 and then when the TCK is public and if Beehive can get it, then any incompatibilities should be recorded as bugs. I say 'if Beehive can get it' because it seems that OSS projects in the past have had trouble getting TCKs and I don't know if that will be the case with the JSR 181 TCK or not. WSM should be judged as best as possible against JSR 181 without the TCK. If WSM is judged to be in line with JSR 181, then go 1.0; if not, then fix it. I think that Beehive should be used as a 1.0 release. Those are my opinions. Kill me now. - jeremiah -Original Message- From: Eddie O'Neil Sent: Wednesday, May 25, 2005 11:02 PM To: Beehive Developers; general@incubator.apache.org Subject: [vote] beehive v1 milestone 1 release All-- The blocking bugs have been dealt with and we've been adding documentation and samples furiously over the last couple of weeks. At this point, I'd like to propose that we release a Beehive 1.0 milestone 1. The code is ready to go -- though I believe that a few committers have some outstanding documentation and samples still to be completed. So, I suggest that we kick the tires of the branch at SVN change 178556 in beehive/branches/v1/m1 (being created now) and let a few more doc / sample related checkins trickle in over the next couple of days. If anyone has concerns about this, please feel free to say so... Tomorrow (Thursday), nightlies will be cut from this branch so that a binary
Re: [VOTE] Graduate MyFaces and recommend as TLP
Sorry for inattention. Definitely +1 for MyFaces becoming a TLP. Craig On Tue, 18 Jan 2005 21:13:39 -0500, Noel J. Bergman [EMAIL PROTECTED] wrote: I seem to recall that Mr. Struts, and several other Strutters, were watching MyFaces. Would you ping Craig for his response? Other than inattention (which is my guess), can you conceive of any reason for people to not support MyFaces being promoted as a TLP? Whom do you propose to be on the PMC? Which ASF Members will be present? Will you and Craig be there? --- Noel -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 18, 2005 15:01 To: general@incubator.apache.org Subject: RE: [VOTE] Graduate MyFaces and recommend as TLP 2 Mine and yours :) On Tue, 18 Jan 2005 14:39:51 -0500, Noel J. Bergman wrote: Ted, It has been almost a week, albeit with a long weekend in the middle. Would you please review the archives and post a body count for this thread? I deliberately try not to cast the first vote on these issues, but you can add my +1 to the list. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: apcvs-unix-group
Matthias, It turns out I misled you into asking for something you already have :-). The Incubator website is rooted at directory /www/incubator.apache.org on server www.apache.org. So, you can ssh to that machine, and create a new directory for your MyFaces at, say, /www/incubator.apache.org/myfaces (creating a new directory to contain it). Then, add a link to it from /www/incubator.apache.org/myfaces.html and you should be good to go. Before starting to create anything, be sure to set your mask (umask 002 from the command line) so that file permissions get set up correctly. Craig On Sat, 20 Nov 2004 19:54:39 +0100, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi all, could somebody add me to apcvs-unix-group? my account is matzew I would like to update the website for MyFaces, which is in incubator. Thanks, Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Percentage of projects using Subversion was Re: Donation of JAXP 1.3 Sources to Apache
On Tue, 19 Oct 2004 11:40:47 -0700, Justin Erenkrantz [EMAIL PROTECTED] wrote: --On Tuesday, October 19, 2004 1:56 PM -0400 Neil Graham [EMAIL PROTECTED] wrote: I'd also be curious to know what proportion of Apache projects have migrated to SVN so far? There would be a significantly higher amount of churn caused to the community by an SVN migration than was caused by our earlier Jira migration; so I'd prefer to go down a well-trod path than be on the bleeding edge in this particular instance. http://svn.apache.org/repos/asf/ A fair number of projects have already converted and a few more (such as httpd) have already agreed to convert, but are waiting for the 'right' time to convert. (My hunch is a bunch more might migrate at upcoming AC'04.) FWIW, we (Struts) just switched, and once you take advantage of svn copy and svn move, or the ability to actually delete a directory, or cheap tag==branch, you'll never look back :-). For more info, please see: http://www.apache.org/dev/cvs2svn.html This tool did a really good job of importing our CVS history logs, too. HTH. -- justin Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT:VOTE] Accept MyFaces for Incubation
Noel J. Bergman wrote: The vote to incubate MyFaces has passed. Voting in favor: James Holmes Alex Karasulu Dain Sundstrom Roy Fielding Berin Lautenbach Phil Steitz Stephen McConnell Craig McClanahan Jim Jagielski Davanum Srinivas Geir Magnusson Jr Cliff Schmidt Noel J. Bergman Craig, would you please put in the requests for infrastructure and root (account) support? Also, if we are going to use CVS, I believe you have sufficient karma to handle the CVS setup. If you don't, or don't have time, let me know. Perhaps Ted and James (champion and mentor, respectively) could do the mailing list and root (account) requests? I'll be happy to set the CVS repository (with karma) and Bugzilla categories. --- Noel ref: http://mail-archives.apache.org/eyebrowse/[EMAIL PROTECTED] tor.apache.orgby=threadfrom=818890 Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: proposal: modify incubation application process to require a reference to the code itself
Noel J. Bergman wrote: java.apache.org history shows a long history of failures in incubating projects without code. jakarta doesn't, exactly because we established that rule. It would be a *major* step back if we lifted that requirement. We wouldn't be lifting it because we haven't had that requirement. In the case of Geronimo, we pretty much forced Geronimo to code from scratch, based on their expertise. That said, it would be extremely rare to incubate a new community without seed code. I don't know of another such. But we do have a quite successful precedent for making an exception. Again, I think it goes back to community. We've rejected code without a community, but I don't think I'd reject a community that lacked code, if we had ASF Members who wanted to sponsor it. --- Noel There's still an outstanding question from the original message in this thread, though ... would we reject an entry into incubation if there *was* code, but we couldn't look at it unless the incubation was accepted? I believe we would always want to require code review in such a circumstance. Whether or not we'd be willing to do such a code review privately (under some form of NDA) is a separate question. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
