Re: Process question on release votes
On Mar 19, 2014, at 10:48 AM, sebb wrote: On 19 March 2014 15:05, Mark Struberg strub...@yahoo.de wrote: what has been with the rule that an ipmc must forward the VOTE to the incubator pmc when it gets started, and those members can also cast a binding -1 ? IPMC votes are the only ones that are binding. However, even a binding -1 vote is not a veto - it is just a negative vote. But IMO it would be foolish for an RM to ignore a -1 vote. In PMCs that have been established some time, IME the expectation is that the RM will cancel the vote if the -1 appears to be justified. This means that PMC members who have already voted probably won't revote as a -1 even if they agree with the -1 (perhaps they overlooked that issue - not everyone can check every aspect of a release). If there is some doubt as to whether the -1 should really block the release, IMO the RM should follow up to explain why they think it is not a blocker. So either way, the -1 is resolved before the release proceeds. Those projects are being foolish. If something bad is found that others also think is bad, they should change their vote to -1. Relying on the RM to make a decision like that just means they don't care and a good RM will go ahead and release based on the majority vote. There are also plenty of valid reasons for a -1 on a release that will occur frequently. The most common one is I have just one more change I want to get in The less common one is I'll keep voting -1 on the release until you drop your veto on my favorite change. There are no vetos on releases. That is not an accident. Releases are majority decisions, as in a majority of folks on the PMC think that moving forward with X is better than waiting for Y. That's what the PMC has been empowered by the Board to decide. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
Release votes are expected to be a decision of the list of people empowered by the foundation to make that decision. How that list of people is populated for podlings is up to the PMC. Right now, the only list we have is the IPMC itself, as appointed by the board. If the Incubator wants to create separate subcommittees to mimic the operations of podling PMCs, with the subcommittee delegated the right to mint incubating releases and the subcommittee membership recorded in an appropriate place for Incubator committee records, that would meet my approval. The purpose of this requirement is to protect the folks who make release decisions (i.e., to provide a corporate record of their right to do an ASF release, since most of them have no other employment, contract, or officer role to back them up). Roy On Nov 10, 2013, at 7:34 AM, Joseph Schaefer wrote: Unlikely to get at least Roy’s approval because release votes are expected to be a decision of the full committee, not any one member of it. On Nov 10, 2013, at 10:29 AM, Alan D. Cabrera l...@toolazydogs.com wrote: On Nov 10, 2013, at 1:04 AM, ant elder ant.el...@gmail.com wrote: How about simply changing the rules for Incubator releases so that they don't require at least three binding votes, but instead make it at least three votes only one of which must be binding. That would mean there would still be the element of oversight that a mentor vote gives but avoids all the problems with not having three mentors. I'm sure the board would grant the Incubator authority to implement that change. The board has charged us to vet the podlings and their releases. What process is used is up to us. I would prefer a variant of your proposal. The first release needs three mentor/IPMC votes. Subsequent releases only require one mentor/IPMC vote. Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
On Oct 2, 2013, at 10:20 AM, Alex Harui wrote: On 10/2/13 10:09 AM, Doug Cutting cutt...@apache.org wrote: On Wed, Oct 2, 2013 at 9:49 AM, Alex Harui aha...@adobe.com wrote: To me, agreeing on the norm is not the same as policy, especially policy that does not allow for exceptions. I agree. Establishing whether there is a norm is a useful first step. That's what I'm trying to take. Thus far I've seen noone disagree that consensus is most common for committer additions at Apache. I've also seen folks suggest that they prefer having norms than having explicit bylaws for their projects. I don't anticipate any policy being established as a result of this discussion, except perhaps better documenting what the assumed default is for projects that don't choose to have explicit bylaws. And again, to me, consensus != unanimity. This might be another case where better documentation would help. In my experience at Apache, consensus is equated with unanimity. In my tour of the internet since my last post and your reply, it does appear that most Apache-related information indicates that committer voting uses consensus and thus the Voting document [1] is out of date. It isn't out of date. It is just plain wrong. It does not reflect any of our projects, but rather presents an incomplete summary based on someone's personal experience. It is difficult to do better than that without having a universal set of project bylaws. Apache doesn't have a single set of project bylaws/guidelines because we want projects to be self-governing. Inherent in that notion of self-governing is that projects need to have the freedom to do some things differently based on the nature of the project or the particular set of individuals involved. By some things, I mean things that are not necessarily constrained by the ASF need to maintain corporate oversight (which is almost entirely encompassed by release votes and the procedure for naming someone to the PMC). Hence, we don't have a single policy for how or when to make someone a committer. That is supposed to be defined by the project. Most people just assume that there exists a magic set of bylaws that are adopted if a given project just doesn't care (like most don't care, until the shit hits the fan and it is too late). For those projects, we typically assume that they have adopted the HTTP Server Project Guidelines, since those were the originals: http://httpd.apache.org/dev/guidelines.html I found this link as well [2]. I'd be tempted to replace the Voting document [1] with this [2], although I'm not sure I understand the difference between consensus and unanimous consensus. Your thoughts? Consensus is that everyone who shares an opinion agrees to a common resolution (even if they do not personally prefer that resolution). Unanimity means that everyone present agrees (for a PMC discussing things in email, that means everyone listed on the roster must affirmatively agree). Hence, consensus decisions can be vetoed, as is clearly stated in the HTTP Server Project Guidelines, unless the project has decided to adopt some other set of bylaws. Roy [1] http://www.apache.org/foundation/voting.html [2] http://www.oss-watch.ac.uk/resources/meritocraticGovernanceVoting -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] [VOTE] HCatalog to Graduate and become part of Apache Hive
It is a majority decision. In theory, the PMC could decide to create special bylaws that would change that to a lazy consensus decision, but then I would have to lay the smack down about why it is that the US government sucks because supermajorities are designed to deny proper governance. In the absence of specific rules (like our lazy consensus rule on code change voting), you can assume that lazy majority decisions are the way that decisions are made at Apache (like releases). Roy On Feb 14, 2013, at 9:58 AM, Mattmann, Chris A (388J) wrote: Hey Alan, Great point -- thanks for highlighting the concern, and yes, Benson, I'd like the Incubator PMC to request this clarification from the board. BTW, not frustrated with you guys at all and wish you the best. Just trying to help (even if it didn't seem like it) based on my existing experience with several of Apache's largest umbrella projects :/ Cheers, Chris On 2/14/13 8:31 AM, Alan Gates ga...@hortonworks.com wrote: I'd like second and extend Benson's point about clarifying how these things should work. In addition to clarifying what it means to graduate into a subproject now that that is frowned upon, clarifying how these votes work would help. I think Chris felt that we ignored his vote and pushed ahead. From my reading of the docs it was supposed to be a majority vote and thus to view the -1s as a veto would be to improperly ignore the 5 +1s. If the rules were clear in advance for the next group that faces this situation it will help to avoid these misunderstandings and frustrations. Alan. On Feb 14, 2013, at 3:29 AM, Benson Margulies wrote: I'm not so much opinionated as confused here, perhaps because I have a very linear view of governance. I like to know how a vote fits into a governance structure or process, and I've felt for some time that this case (podling goes to existing TLP) is not well-explained by our structure. Back in the days when subprojects were normal and valid, the incubator had a role on behalf of' an existing TLP in supervising IP and community behavior. Graduation meant: OK, umbrella, we certify that these people can behave like a project and have clean IP. And, perhaps, the board actually established subprojects? It's all before my time. Now that subprojects are no longer in the picture, I don't even know why the IPMC should ever incubate a podling *if the plan, from the start, is to be part of some existing TLP.* So I have assumed that HCatalog started out with the intention to grow into an entire TLP, and came up with the Hive plan as a fallback. To try to make this long story shorter, I think that we should make a proposal to the board with a schema for handling this case that makes sense in current conditions. I'm happy for it to be your schema, which amounts, as I see it, to the board having a supervisory moment when this happens, with an IPMC vote providing the same sort of strong recommendation one way or the other that it does for establishing a TLP. On Thu, Feb 14, 2013 at 12:49 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Benson, I saw your later email(s) and Incubator board report. It's fine and I think the message of my objection comes across. So thanks for that. One thing I wanted to comment on: On 2/13/13 4:10 AM, Benson Margulies bimargul...@gmail.com wrote: Chris, The obvious compromise is to ask them to report the vote result as it happened, it seems to me, -1's and all. But where do you think that they are reporting anything? There's nothing happening here at the board level. There's no board resolution needed for a Hive committer to type 'svn cp' on the hcatalog tree, Not by my counts. There's a *community* resolution and a recommendation to be made by the IPMC, nonetheless. Otherwise, the IPMC is pretty useless IMO, and more importantly, so is the Incubator. Why bother even incubating HCatalog? Hive could have simply svn cp'ed whatever code came in, or whatever code the podling arrived at, and Incubation would have stopped then. But we both know that's not the way it works. Even if a podling graduates to an existing TLP, go check out the past resolutions. You'll note there's a section in there that discharges the responsibility of the IPMC for the podling. So, yes, the IPMC *is* involved. And yes, the IPMC vote matters. Cheers, Chris - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail:
Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release
On Jan 25, 2013, at 4:13 AM, Benson Margulies wrote: On Fri, Jan 25, 2013 at 3:04 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Benson, On 1/24/13 7:23 PM, Benson Margulies bimargul...@gmail.com wrote: It's unfortunate to have this conversation in parallel here and on https://issues.apache.org/jira/browse/LEGAL-157. Also, this thread is a combo of the discussion of ordinary jars-of-classes (where I'd forgotten the policy) and the much more tangled question of models, which is what the JIRA is wrestling with. To answer Ted, I think that Roy might write something like: It's not the mission of the ASF to create complete, end-user-friendly, software products. It's our mission to create open source code. If someone else wants to build up an end-user-friendly aggregation of ASF code and models from bombs of whatever, that's great, and we encourage them. What about Apache OpenOffice? I asked this question about Open Office, and I got, more or less, what I typed in above. I was puzzled, but there you have it. As I recall, Roy made a remark like 'our real users are people who will take the source of Open Office ...'. The Apache Software Foundation is not a retail software company. We foster an ecosystem, and do our best not to shoot ourselves in the foot by directly competing with commercial interests and killing the ecosystem in the process. Please don't confuse the development community with the end-user community. They are not even remotely the same things. There is nothing preventing folks in the development community from providing the best support available, for the most polished binary releases, for folks who only care about open source as a fashion statement. They can even do so using our infrastructure, if they are part of our development team. It just isn't the ASF doing so -- it is some person or company doing so. Yes, being user friendly has a huge value for the projects. So what? We have to leave something for others to do. And I did mention, many times over, that the *right* way to handle openoffice.org was to manage the user-facing site separately from the development organization, with separate nonprofits if necessary, particularly since then the user-facing site could host all of the OO distributions without busting our brand. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Linda
I suggest choosing a different name. http://en.wikipedia.org/wiki/Linda_%28coordination_language%29 We generally don't use names that have been (and continue to be) used extensively by other software projects. Roy On Nov 16, 2012, at 9:14 AM, Sebastian Schaffert wrote: Dear all, we would like to propose a new project called Apache Linda as a Linked Data Platform implementation to the incubator. Andy Seaborne was so kind as to volunteer as a champion for the project. The proposal is available at http://wiki.apache.org/incubator/LindaProposal The goal of Apache Linda is to provide an open implementation of a Linked Data Platform that can be used, extended, and deployed easily by organizations who want to publish Linked Data or build custom applications on Linked Data. Linda will follow the core recommendations of the W3C on RDF, SPARQL and Linked Data publishing, particularly the emerging Linked Data Platform (LDP) recommendation. It will also offer extensions for frequently needed additional functionalities like Linked Data Querying, WebID, WebACL, Reasoning, and Versioning. Linda aims to cover both, Linked Open Data, as well as Enterprise Linked Data scenarios, providing facilities to deal with different data sources and requirements (small data/big data, open access/restricted access, etc). We are looking forward to your feedback and suggestions on how to improve the proposal and idea! Sergio, Thomas, Jakob and Sebastian -- | Dr. Sebastian Schaffert sebastian.schaff...@salzburgresearch.at | Salzburg Research Forschungsgesellschaft http://www.salzburgresearch.at | Head of Knowledge and Media Technologies Group +43 662 2288 423 | Jakob-Haringer Strasse 5/II | A-5020 Salzburg - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Shipping binary file in CloudStack release
[generic incubator comments -- nothing specific to CloudStack] ... On Oct 29, 2012, at 8:01 AM, Noah Slater wrote: On 29 October 2012 14:48, Chip Childers chip.child...@sungard.com wrote: On Mon, Oct 29, 2012 at 10:39 AM, Noah Slater nsla...@apache.org wrote: But regardless, you couldn't. A single -1 vote would be enough to block the release. Binding or not binding. It doesn't matter. If somebody expresses a real, and justified, concern about the artefact, then you don't release until you've addressed that concern. If that's true, then should the release policy [1] be updated? [1] http://www.apache.org/dev/release.html#approving-a-release Perhaps. I know I started out RMing with the idea that I just needed to collect more +1 votes than -1 votes. But I think that's broken in practice. I think if you have a valid, justified, -1 vote, and you release without addressing it, then there is something SERIOUSLY wrong. It entirely depends on why the -1 is cast. Release votes are lazy majority decisions. They are not at all like design decisions or adding a new committer. A person could -1 a release simply because they are working on a new feature and want the group to wait until it can be included. These are matters of opinion. If someone casts a -1 because something is seriously wrong, then we expect the rest of the PMC to wake up and say -1 as well. If they don't, then it isn't seriously wrong even if one or a few people think so. IOW, if it is a serious issue then we can expect the majority to agree that it is a serious issue. There is no need to change the rules to accomplish that. An RM can choose to stop working on a release at any time. We are all volunteers. However, the release decision is made by the PMC; if a vote has completed on an artifact, then that artifact can be copied to dist by anyone in the PMC. If something really bad is found in a voted-on-but-not-yet-announced release, then we expect the PMC to work together to ditch the old artifacts, fix the problem(s), and start again with a new version number. If they don't, the project has a much larger problem than anything we might find in a release. Note that there has never been a case where a real problem is found and the rest of the group hasn't immediately shut down the release. However, there have been cases where individuals have poisoned an entire project simply by dragging their feet on the release process for the sake of their own work or world-view. A release vote is required to be a majority decision, rather than a consensus decision, because Apache understands group dynamics. That cork is meant to be popped. It is better for the group that it be popped on a regular basis, where regular is defined by the majority of the group. The more, the merrier. Adding glue around the cork to make sure it doesn't pop, unless we really really mean it, is not a good plan. We are far more likely to be hurt by a project that can't release than a project that occasionally releases too soon. Folks often lose sight of that when focused on fixing a specific issue. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Graduate the Apache SIS podling from the Apache Incubator
On Sep 10, 2012, at 12:46 PM, Jukka Zitting wrote: Hi, On Sat, Sep 8, 2012 at 4:42 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Please see the resolution below and VOTE on it for the graduation of the Apache SIS podling from the Apache Incubator. I'll leave the VOTE open for at least 72 hours. [x] +1 Graduate the Apache SIS podling from the Apache Incubator per resolution below. WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software, for distribution at no charge to the public, related to the acquisition, processing, representation, and dissemination of spatial data, The placing of the for distribution at no charge to the public part is a bit unusual, but I can see why having it at the end of the sentence might be a bit confusing. I have been making that unusual change every time a resolution comes to the board. If there is a template for incubator use, please change it to be like the above resolution, where related to ... is at the end of the clause. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2
On Aug 21, 2012, at 4:59 AM, Branko Čibej wrote: On 21.08.2012 12:52, sebb wrote: I think the NOTICE problems are serious enough to warrant a respin. This is an unreasonable request. The IPMC voted on the 3.4.0 release. The notice file has not changed between 3.4.0 and 3.4.1. How then do you justify this new requirement? It is his opinion, not a requirement. It is not fair to the podling if the IPMC invents new requirements and reverses its own decisions for no apparent reason. This NOTICE issue certainly shouldn't be ground for vetoing a release. Nobody can veto a release. Even the board would require a majority vote, though root has the power to stop distribution. By the way, the same holds for binaries being included in the releases. The 3.4.0 release, with binaries, was approved. If the podling did not change its release procedures and policies and artefacts in the meantime, it's not reasonable to hold up what amounts to a security release solely based on the IPMC having screwed up the previous release vote. Of course it is reasonable to expect a podling to read and respect the release process. That's the point of doing the release with IPMC review. It is fair to require changes for the next release. It's not fair to use different criteria for two successive, essentially identical releases. (N.B.: I use the term essentially identical in the sense that, whilst some of the sources have changed, the overall structure of the release artefacts has not.) Fairness has nothing to do with it. These issues are all documented http://www.apache.org/dev/release.html http://www.apache.org/legal/src-headers.html#notice http://incubator.apache.org/guides/releasemanagement.html#best-practices-svn This is not a difficult task, but it does require practice to get right. Every RM on every project goes through this pain. Adherence is necessary to enable peer review. Peer review is necessary to enable volunteers to act on behalf of the ASF. Acting on behalf of the ASF is necessary for legal protection of the project contributors. We are teaching the project how to do an open source release without being held individually liable for the millions of things that might get one sued for making an open source release. Being half-assed about it would not be doing them a favor. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [MENTORS] Third Party source
I fear we are miscommunicating again. Only the copyright owner is allowed to (re)move copyright notices or permit others to (re)move them on the owner's behalf. Jeff just needs to give the project permission -- one simple email message to the list is enough -- and then anyone at Apache can move them. He doesn't need commit access if he doesn't want it. If he doesn't want to give permission, then just leave them as they are. It is not a prerequisite on releasing the code. Our *desire* for a company granting code to Apache to remove their own copyright notices from every file is because 1) it hinders open collaboration if volunteers think their new work is going to look like it is owned by company (C) 2) if one contributor gets credit in a file, then *every* significant contributor should have the same credit, which is a problem for contributors that would rather not be the first point of contact during a lawsuit. and so we request the notices be moved at the time of (or shortly after) initial code donation because that is when folks are happy to do so and actively communicating with the ASF. It is also for their own good, even if they don't know it yet. Roy On Jun 7, 2012, at 1:58 PM, Greg Reddin wrote: Hi Incubator, See the email below from Alex Harui. I need help figuring out what to do here. I'm not sure if Jeff was ever an employee of Macromedia or what the full situation is. Perhaps Alex can clarify if needed. Essentially, we wanted to offer Jeff commit rights to make the modification as suggested by Roy. But Jeff indicated he's too busy to do it. Since he owns the copyright and seems willing to donate the code, what would be the appropriate methodology here. Do we need a software grant? Would it be sufficient to have an ICLA on file from Jeff? Thanks, Greg On Wed, Jun 6, 2012 at 2:22 PM, Alex Harui aha...@adobe.com wrote: Hi Mentors, Some of the source code in the compiler is copyrighted by Jeff Dyer who wrote some of original code that was then acquired by Macromedia/Adobe. At the time of the donation, Roy Fielding said we should make Jeff a committer so he can move the copyrights to the NOTICES file. Does that make sense? If so, I will ask him to submit an ICLA. I assume his committer status doesn’t require the usual vote protocol? My understanding is that need to get this cleared up in order to cut an official release. Thanks, -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui - 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
diversity
On Jun 5, 2012, at 2:45 PM, Ralph Goers wrote: I posted an email earlier today where I discussed my confusion over the diversity requirement. I'm not comfortable doing anything without getting some feedback on whether the diversity requirement, as currently stated on the wiki, is correct or whether diversity should simply be measured by how a project makes its decisions as Roy suggests. There is no diversity requirement at the ASF. There is a behavior requirement for graduation and a behavior requirement for TLPs. We must not confuse the two. If the Incubator says that there is a diversity requirement for graduation, ignore it (or at least figure out what the docs were supposed to say and then do that). I'd urge folks to fix the docs, but I know where that leads ... and I have no cycles to spare. A diversity requirement would mean that a person's employment status impacts their ability to participate here. IOW, it would create a perverse incentive for them not to be employed. Now, I'll explain why ... Everyone here participates as volunteers, even when they are employed by someone else and that employment pays them to contribute here. If we set requirements on diversity, we are telling potential employers of our volunteers that they should not hire those volunteers who happen to work on the same project. They should not offer them employment. They should not pay them well. They should not encourage their other employees to contribute here. I hope that clarifies the situation. I will not tolerate a perverse incentive that punishes our existing volunteers or prevents additional volunteers from joining our projects. That is far worse than a project that happens to be dominated by one employer's volunteers (assuming they still *behave* as an Apache project). This is not a theoretical issue. How long ago was it that Day hired Jukka --- a spectacularly productive dude who lived in Finland? This very issue came up at the time. Is it safe to hire Jukka when he represents most of the diversity of Jackrabbit (at the time, still in Incubator)? Do you have any idea how f*$ing insane it would have been if we had decided not to hire Jukka? If we had backed off because of a frigging diversity requirement? My mind boggles at the loss. Or what if Day had hired him and then said he can't participate in Jackrabbit? How much damage would that have done to Apache? IMO, far more than anything we'd ever gain from enforcing an arbitrary quota for PMC composition. I don't know about the rest of you folks, but I happen to like getting paid while still contributing at Apache. I think it has worked out well for both organizations, and for countless others downstream. I wouldn't mind getting paid more. Hence, we don't allow perverse incentives that interfere with our volunteers' future prospects for gainful employment. It would be wrong, even if it is well-intentioned. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Flume Graduation (was Re: June reports in two weeks)
There is no diversity requirement for graduating from the incubator. In many ways, incubation hinders community growth. The requirement is that the project makes decisions as an Apache project, not in private, which is harder to get used to doing if a lot of people share the same office. Diversity is only a warning sign that means we need to check for decisions made in our forums and advise accordingly. It is not an end in itself, nor has lack of diversity hindered other projects from continuing on to build a larger community as a TLP. Roy On May 26, 2012, at 11:44 PM, Ralph Goers ralph.go...@dslextreme.com wrote: On May 26, 2012, at 9:29 PM, Arvind Prabhakar wrote: Hi Jukka, On Sat, May 26, 2012 at 4:43 PM, Jukka Zitting jukka.zitt...@gmail.comwrote: IIUC Flume operates under an RTC model where people are not supposed to commit their own changes, which obviously makes the above data less relevant for evaluating the true diversity of the community. However, seeing only a single trivial commit by both jarcec and juhanic even though they became committers already over three months ago does seem to suggest that they may not be as comfortable in their committer role as people from Cloudera are. As you noted in your comments above - the Flume project tends to follow RTC with the reviewer committing the code. I happen to have taken up the role of the reviewer for the most part and hence you see the skewed commit counts. If you want to see the actual contribution, I would suggest looking at fixed JIRA issues by assignees. A quick report yields the following: aprabhkar - 26 - Cloudera [6] brocknoland - 19 - Cloudera [7] esammer - 56 - Cloudera [8] hshreedharan - 34 - Cloudera [9] jarcec - 6 - AVG Technologies [10] jmhsieh - 8 - Cloudera [11] juhanic - 9 - CyberAgent [12] mpercy - 34 - Cloudera [13] m...@apache.org - 1 - Trend Micro [14] prasadm - 34 - Cloudera [15] t...@cloudera.com - 3 - Cloudera [16] w...@cloudera.com - 3 - Cloudera [17] Looking at this, the average number of issues resolved by Cloudera committers (not counting Tom who is a mentor) is 26, and that for non-Cloudera committers is 5. Note that this number does not include other committer work such as the number of code reviews they have done, the number of design discussions they have participated in, something that is very valuable to the project. Another way of looking at these same statistics: Cloudera - 217 Other - 16 That means Cloudera is responsible for over 93% of the Jira issues. It is great that Cloudera is doing so much work but those stats hardly prove diversity. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC0
On Mar 29, 2012, at 4:07 PM, Fabian Christ wrote: Hi, Am 26. März 2012 17:20 schrieb Roy T. Fielding field...@gbiv.com: On Mar 26, 2012, at 4:41 PM, Karl Wright wrote: On Mon, Mar 26, 2012 at 10:24 AM, sebb seb...@gmail.com wrote: On 26 March 2012 02:38, Shinichiro Abe shinichiro.ab...@gmail.com wrote: The LICENSE file includes references to lots of jars that are dual licensed under CDDL v1.0 and GPL v2. However, there is no indication which license has been chosen by the project. I think this is a blocker. A project does not choose a license. The license is provided by the copyright owner. We do not change that license, nor do we reduce the number of the available licenses to choose from, for downstream recipients. Therefore, it doesn't make any sense to indicate which one is chosen. I am following all these discussions for doing a first release of Apache Stanbol (incubating) but get totally confused. According to http://apache.org/legal/resolved.html#mutually-exclusive you have to choose the license and include only the license that you have chosen. The answer in that document is wrong. I believe what they meant to say is that we only include one of the licenses in the text/pointers of our product-wide LICENSE file. Mainly for dual-licensed GPL. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Multi-licensed dependencies
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. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Multi-licensed dependencies
On Mar 29, 2012, at 9:37 PM, Marvin Humphrey wrote: On Thu, Mar 29, 2012 at 11:42 AM, sebb seb...@gmail.com wrote: On 29 March 2012 18:43, Roy T. Fielding field...@gbiv.com wrote: 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 Pointers are sufficient. It is also at odds with the Apache HTTPD LICENSE file we've been treating as a canonical sample. The documentation on www.apache.org/dev may have been contaminated by well-meaning volunteers and changed from Roy's original meaning, but I assume that the HTTPD LICENSE and NOTICE files haven't gotten away from him and are still 100% consonant with both the letter and the intent of the ALv2. I know more about the letter and intent of the ASF's license and licensing policy than anyone else at the foundation. This was discussed and approved on the licensing list some time ago. While Roy's suggestion of referencing licenses spread over multiple files seems like a perfectly sane alternative, I'd argue against documenting it as best practice unless HTTPD changes their LICENSE file to match. httpd's license refers to small snippets of code all over the tree; all of the licenses are fairly close to BSD. It is simply more convenient to list all of those in one place. Inclusion of entire jar files is different. As is including huge and nasty license files, like the GPL. You do not want to mix all those licenses together, particularly since most of those licenses won't be included in your source distributions. Also, you cannot mix the GPL license in with the others. We are not shipping a combined work as GPL. We can ship an aggregated work, wherein the aggregation consists of separate components in separate directories with their own license files, or we can ship an overlayed work -- where the GPL distribution is unpacked on top of an Apache-licensed distribution. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
On Mar 28, 2012, at 2:39 PM, Benson Margulies wrote: Roy, Of course you, personally, can't be expected to supervise all projects or fix all documentation. At the same time, there's something a little depressing about the situation. On the one hand, the principle at work here is, to paraphrase you, absolutely central to the defined mission of the Foundation. On the other hand, over all these years, the Foundation has apparently failed to do two things: to find a way to document this so clearly that no member, let alone PMC chair let alone committer could miss it; and to supervise projects sufficiently to detect divergence. The board can read reports all year long and never discover that someone has drifted off the rails here. None of this, however, is what I really want to write about. Consider me in the role of a PMC member voting on a release with external dependencies, not included (of course) in the bundle. What do I do? If you want to do it right, build the whole thing from scratch -- nothing but the source code. If there isn't at least one person (or CI bot) doing that per project, we're screwed. Well, I fetch the dependency. In source? In binary? From where? And how do I ensure that I get exactly the same thing that the next voter over gets? If the build automatically downloads, I don't appear to have this problem, but, really, what do I know about what that download is downloading? You don't. Fortunately, we require three +1s, so it is fairly hard to trick the whole PMC. This all boils down to the semantics of the vote. All I can really do is attest that the sources are legitimate Apache sources, and that I was able to build and run something using *some version of some dependencies*. Is this really good enough? Yes. In our role as serving the public good, is this giving the user community enough information? The user community is not our immediate concern. Downstream developers are. We are only responsible for what we decide to release. Consider the following thought experiment: what if projects bundled up their binary dependencies into an archive with a manifest file that described their provenance, signed them, and put them someplace? Someplace not 'inside a release'. Then, the source release would be aligned with a particular, reproducible, version of its dependencies. Yes, it's called a -deps package, and individuals occasionally produce them and even redistribute them from our servers (as binaries). Users are warned that binaries are provided for their convenience, and that building from source is preferred for verification. Organizations or individuals that would be offended by (or prevented from receiving) the binaries are fully capable of building their own IF and ONLY IF the binaries do not exist in our source packages. If this is still completely unacceptable, the logic seems to lead inexorable to dealing in Other People's Sources: capturing a snapshot of their sources so as to be able to state, unequivocally, what the dependencies are. Maybe all this reads as pointless quibbling and no one cares about it. I have another issues to raise, however: the gap between public perception of Apache releases and legal reality. When AOO releases, soon, a giant flood of *binary packages* will move out onto the mirrors. Accompanied, yes, by a source release. Formally, legally, the only real release is the source package. Realistically, no end users will touch it. From their point of view, the thing with the Apache seal of approval that they will trust, download, and install will be a binary. AOO isn't unique, but it's the starkest example, because of it's end-user focus. I feel a little bit disingenuous, in our role as a public charity, about the disparity between the public perception that we're releasing binary packages and the facts. This strikes me, in unhelpful retrospect, as an issue that the board or membership should have taken up as part of accepting AOO. I don't have a proposed solution; please don't mistake me for proposing to tamper with the fundamental 'releases are source' principle. But I think that something here does not fit. How is that different from any of our other projects? End users don't compile Java. Hell, most developers don't compile Java. We distribute plenty of binaries. We just don't call them SOURCE. The source is what we review. The source is what we bless. If anyone wants to go further than that, they are free to do so as long as they don't call the result an Apache release. It is a binary package, a user convenience, a download hosted by openoffice.org. I don't care. People have to understand this. There will always be a role for downstream commercial or non-commercial redistributions of Apache products. Why? Because the ASF is incapable of taking on the enormous liability associated with released binaries that are not produced in a controlled environment with a controlled set
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC0
On Mar 27, 2012, at 2:15 AM, sebb wrote: On 26 March 2012 16:20, Roy T. Fielding field...@gbiv.com wrote: On Mar 26, 2012, at 4:41 PM, Karl Wright wrote: On Mon, Mar 26, 2012 at 10:24 AM, sebb seb...@gmail.com wrote: On 26 March 2012 02:38, Shinichiro Abe shinichiro.ab...@gmail.com wrote: Hello Incubator IPMC, Please vote on whether or not to release ManifoldCF 0.5-incubating, RC0. This RC has passed our podling vote and awaits your inspection. You can find the artifact at http://people.apache.org/~shinichiro/apache-manifoldcf-0.5-incubating-RC0/, or in svn at https://svn.apache.org/repos/asf/incubator/lcf/tags/release-0.5-incubating-RC0/. The NOTICE file says: Apache ManifoldCF Copyright 2010-2011 The Apache Software Foundation The LICENSE file includes references to lots of jars that are dual licensed under CDDL v1.0 and GPL v2. However, there is no indication which license has been chosen by the project. I think this is a blocker. A project does not choose a license. The license is provided by the copyright owner. We do not change that license, nor do we reduce the number of the available licenses to choose from, for downstream recipients. Therefore, it doesn't make any sense to indicate which one is chosen. In any case, the indicated artifacts are only included in binary packages. We don't release binaries, so none of these licenses belong in our source product's LICENSE file. We need to be clear that the source code package does not include these dependencies. They only exist in binary distributions. That's not the case with this product at present; all the jars are actually in SVN and they are also in the source and binary archives. Do I really need to explain what source code means? http://www.apache.org/dev/release.html#what All releases are in the form of the source materials needed to make changes to the software being released. Apache releases open source and ONLY open source. Our releases are absolutely forbidden to contain anything other than the open source code that is in our vcs-of-record, meaning code that is in the form most likely to be edited by recipients for the sake of modifying the product, and in some specific cases the generated (and open) source code of build scripts. Binary distributions and binary/jar dependencies MUST be separate packages that are not voted on by the PMC during the release vote, because they are not part of our product and are not released by the ASF. No PMC has been granted the authority to publish binary releases on behalf of the ASF. It would be contrary to the mission of the foundation. They may distribute binary build packages of existing source releases, but these are not ASF releases -- they are just builds provided by the project for user convenience. Likewise for jar files of dependencies -- they are NOT our product and they MUST NOT be present in the source code package that is voted on for release. If podlings get this wrong, fix them. If TLPs get this wrong, fix them. No project should ever leave incubator before this is drilled into their collective skull: The ASF produces open source software! If any ASF member is aware of an Apache release package that is not 100% open source code, you are hereby instructed to DELETE it from our servers. Nobody, not even me, has the right to place a compiled class in one of our packages and call that a source release. Is that clear? Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)
On Mar 27, 2012, at 12:57 PM, Jukka Zitting wrote: Hi, [dropped infra@, I believe most interested people are already on general@] 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, then affected projects should be given a reasonable amount of time to adapt. I don't see where you get the idea that there is a long tradition of including binary artifacts within the source package releases at Apache. There may be specific groups who are apparently lacking the appropriate clue and stubbornly refuse to read the messages I have sent multiple times to this mailing list, legal-discuss, and members, but there is no question whatsoever that a source package cannot include binaries. It would not be a source package otherwise. http://incubator.apache.org/guides/releasemanagement.html This issue is not open for discussion. It is is a mandate from the certificate of this foundation -- our agreement with the State of Delaware that I signed as incorporator. It is fundamental to our status as an IRS 501(c)3 charity. It is the key charter delegated by the board as part of every TLP resolution: charged with the creation and maintenance of open-source software ... for distribution at no charge to the public. Class files are not open source. Jar files filled with class files are not open source. The fact that they are derived from open source is applicable only to what we allow projects to be dependent upon, not what we vote on as a release package. Release votes are on verified open source artifacts. Binary packages are separate from source packages. One cannot vote to approve a release containing a mix of source and binary code because the binary is not open source and cannot be verified to be safe for release (even if it was derived from open source). I thought that was frigging obvious. Why do I need to write documentation to explain something that is fundamental to the open source definition? Also, let's make a clear distinction between binary distributions (i.e. the packages that result from building one of our source releases) and binary dependencies (i.e. binary distributions of upstream projects). AFAICT there's clear consensus that binary distributions are *not* official Apache releases, and we've been pretty consistent about that so far. However, the word on binary dependencies is much less clear. There's explicit Apache policy (category B, etc.) that talks about binary dependencies and plenty of Apache releases contain them. This is clearly not an area where we have consensus. Please point those packages out to me and I will ask Joe to give me root access again so that I can go through and personally delete them from our dist directories. Seriously. I am so tired of having to send these emails, write the documentation, and then watch Java projects to do the wrong things again and again. It is time for the sledgehammer. The Category B is about products in general, not just source packages. Yes, that documentation sucks. Yes, I said so at the time. No, it is NOT an approved policy document of the ASF. The categories are about software licensing of the product as a whole, including hard dependencies and built packages, not whether something is included in a source code package. On Tue, Mar 27, 2012 at 11:50 AM, Roy T. Fielding field...@gbiv.com wrote: Likewise for jar files of dependencies -- they are NOT our product and they MUST NOT be present in the source code package that is voted on for release. Citation needed. Note that the source materials reference you mentioned earlier is vague. It covers stuff like configure scripts in httpd releases, test files, and indeed (as far as it so far has been interpreted) binary dependencies of upstream open source projects. I'm fine if this point needs to be clarified and some current practice terminated, but let's follow standard process to do so. It isn't even remotely vague. Source has only one definition. And it isn't just that document: http://incubator.apache.org/guides/releasemanagement.html#best-practice If any ASF member is aware of an Apache release package that is not 100% open source code, you are hereby instructed to DELETE it from our servers. What hat are you holding here? Which packages explicitly are you referring to? My hat. I'll make it a board directive at the next meeting, if you like. If I had known of any such packages, I would have deleted them already. Don't you remember the similar conversation we had about Jackrabbit releases? The only jar files we should have in subversion are the non-product trees -- the places where we store build tools, the artifacts
Re: [VOTE] Release ManifoldCF 0.5-incubating, RC0
On Mar 26, 2012, at 5:36 PM, Karl Wright wrote: Some clarifications: Hi Roy, (1) Our LICENSE.txt file currently contains references to all non-Apache jars that we redistribute, and a reference or description of the licensing of that jar. We do not attempt to relicense anything. No shared release process is involved for any third-party jar we redistribute. The actual text we include is typically something like this: This product includes a jaxb-impl.jar. License: Dual license consisting of the CDDL v1.0 and GPL v2 (https://glassfish.dev.java.net/public/CDDL+GPL.html) Jar included under terms of CDDL v1.0 license. (2) The purpose for including the above is to clarify the terms under which we believe that we are able to redistribute those jars. Therefore I don't think Sebb's request is unreasonable. If you believe that this information is in the wrong place, then please let us know where it should go. As I've said before, we're not doing things any differently than most other Apache projects. Please clarify your recommendations. I had two separate comments, neither of which are intended as a criticism of ManifoldCF. First, Sebb's request is reasonable; it just happens to be wrong. No Apache project needs to say Jar included under terms of CDDL v1.0 license. A project might choose to say that, but it is nonsense, and certainly isn't a requirement of incubation. Second, Apache projects only release SOURCE. We don't release third party binaries, period. Hence, the specific examples that you provided are not valid for a release LICENSE. They might be valid for the license file included within a binary package, but please note that such a license file will be different from the LICENSE that is provided in the source distribution, and is not something we would be voting upon (because no PMC can be expected to verify the validity of those binaries). Hence, what you need to do is split the LICENSE in two -- one for source packages (that do not include dependent jars) and one for binary packages (that do include the dependent jars). Hopefully, Jukka can step in and document how the LICENSE and NOTICE files are crafted for Jackrabbit and Sling, since those projects have the exact same issues regarding third-party libraries that are only included in the binary packages. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IP Clearance? NAK
On Mar 1, 2012, at 7:55 PM, William A. Rowe Jr. wrote: On 3/1/2012 9:49 PM, Sam Ruby wrote: I don't know what statement Roy is referring to, so I won't challenge it directly. Instead I will ask that people work together to find out what processes are right for the ASF at this point in time, even if these processes are different than the ones that we used 10, 5, or even just 2 years ago. In this specific case, I trust Roy to inform us if it meets the narrow response he received with respect to a single committer's creation on behalf of their employer (as we understand this submission) or if it has some additional considerations. My understanding is that the author of the code in question is an existing committer, has an iCLA on file, says he authored it, and says he has permission from the copyright owner to contribute the code to the ASF. He has made that statement in both the public list (archived) and the actual commit. That's all we need for contributions of code from committers to an existing TLP. It can be five lines of code or five million lines of code. We trust our committers. I know that the incubator occasionally thinks it owns the process for all contributions of code at Apache. I don't care. When code comes from a source that has not yet signed a contributors agreement with Apache, then we should have it go through Incubator to be sure that some paperwork gets signed. But when it comes from an existing committer who says he has permission to contribute under his own iCLA, we already have the signed agreement on file and the contributor is entirely responsible for the accuracy of his own statements. There is no need for incubator to be involved. If there was any such need, then every single commit from every contributor would need to go through the same process. There is no need to waste the contributor's time, nor the time of the project chair, with useless procedural nonsense that has no value whatsoever beyond the statements already made by the contributor. We have several layers of contributor licensing to cover our ass, and if for some bizarre reason that is not enough then I am absolutely certain having another document in incubator summarizing it won't help. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator, or Incubation?
On Feb 3, 2012, at 2:00 PM, Sam Ruby wrote: There is a place in the middle, which very much intrigues me. Instead of replacing 1 IPMC with n PMCs, having n+1 PMCs, with the Incubator playing a role much like legal or trademarks (or infra or press or...). In particular, when problems arise the board would direct the PPMC to work with this group. This group would be much smaller than the current Incubator, but would continue indefinitely. IMO, that sounds like ComDev. ComDev was created, at least in part, to complete the documentation tasks that Incubator dropped and act as an Apache-wide community builder regardless of project status. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] eliminate vetoes on personnel votes
On Jan 31, 2012, at 12:52 PM, Doug Cutting wrote: On 01/30/2012 05:12 PM, Greg Stein wrote: I've never liked vetoes for this. One person can hold an entire PMC hostage simply for disliking someone (or worse: subtle corporate concerns masked otherwise). People have said in the past, you should have veto so you're not forced to work with somebody you dislike. I respond, grow up. we work with annoying people all the time, and the majority says they *can* work When this question came up in another context, Roy's concern, as I recall it, was something to the effect that if you don't allow vetoes of proposed PMC members then you might create a dysfunctional PMC. (Roy, please correct me if I miss-recall.) Well, it boils down to the fact that making someone a PMC member gives them veto power over the changes you make. The only way that works socially is if everyone currently on the PMC agrees that person is a peer. 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. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 11, 2012, at 8:33 PM, Noel J. Bergman wrote: Roy T. Fielding wrote: Noel J. Bergman wrote: The ASF is not about code; it is about community. If a community forks, or otherwise emerges around a codebase, we are not accepting the CODE: we are accepting the COMMUNITY. One company is not a community. As you've otherwise acknowledged, I was talking in the general case, and you're addressing a specific instance. And it seems to me that if we are to say that a COMMUNITZY is not permitted to participate despite use of code that is perfectly proper according to the license, then we are beggaring out own license, the whole point of which is to permit forks, and to prevent a sole copyright holder from assuming control over the community. If there is no community for the original codebase, yes. Agreed. 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. Why not, *IF* there is an active second community that wants to fork? Again, in the hypothetical, not in the specific, case, which you say is a single vendor, not a community. Because it is rude to do so. The second community is welcome to fork their own code and contribute that here. In some cases, an open community will have joint copyright and some of those folks can split off and contribute the whole here even if the others don't like it. But that is a rare case, and I'd suggest we would have to look at it carefully to avoid being used as someone else's pawn. If the original developers of the code do not want their license changed, then we will not fork the code at Apache. I kind of take that as a given, since how could we fork it if we can't relicense it? We could fork BSD variants without relicensing the files. By forking them here, we relicense the end product (our releases). We choose to do so as an Apache fork only when it is desired by the current maintainers of that code. Otherwise, we make it clear that we are only distributing a copy of their code, under their original license, and place it in a location for third-party code (srclib) or have the user download it separately at build time. We only accept voluntary contributions The presence of a community that wants to work here implies voluntary, and not everyone has to agree with the fork. Don't you remember the origins of Apache Felix? By community, I mean the people who have contributed to the work and thus have a vested interest in its future. Such community members are welcome to contribute here any work products that they have personally developed or own copyright to, and any code for which they have an expressed permission from the copyright owner that it is okay to contribute it here. We also accept, at face value, files under a compatible license for which the author is no longer responding to communication, or small subsets of code for which copying them here has no negative impact on some other community, such as copying routines out of FreeBSD for use in httpd. Yes, open source licenses give permission to fork. We try to do no harm when we fork. It's a philosophy thing that is fairly unique to Apache because we are so community-centric, but it is not difficult to explain to others and many open source developers just assume it as a given. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 9, 2012, at 9:11 PM, Greg Stein wrote: On Jan 9, 2012 10:03 PM, Roy T. Fielding field...@gbiv.com wrote: ... And, no, the discussion has not been with the Trac community -- it was in private with a few individuals; as far as Apache is concerned, it never happened. And Oracle's private conversations, and their decisions regarding OOo contrary to the community, were somehow acceptable? Acceptable to whom? Oracle owned the copyright on the code. LibreOffice is not the community for Oracle's codebase -- it is just the most public and successful of the earlier forks. Oracle made the choice of where they wanted to contribute their own code, long before they contacted the ASF. I am damn sure that we didn't have any significant private discussion with Oracle before their proposal was submitted to the incubator. IBM did, I presume, and maybe a few others acting as individuals, but not the ASF. As far as Apache is concerned, those private discussions didn't happen. The Apache work began with a public proposal, and it wasn't until then that Oracle could be said to have discussed it with the Apache community. Is the result acceptable to us? Yes. Acceptable to the LibreOffice community? Probably not, but it wasn't their's to contribute even if they had wanted to do so. Oracle was the only entity with the ability to relicense that code to the ASF. ... There is no fork in the current plan, so this discussion is moot anyways. I believe the point was to settle the issue so that we don't have to deal with this situation again. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 9, 2012, at 9:42 AM, Hyrum K Wright wrote: On Sat, Jan 7, 2012 at 4:10 PM, Roy T. Fielding field...@gbiv.com wrote: On Jan 7, 2012, at 1:49 PM, Greg Stein wrote: On Jan 7, 2012 4:24 PM, Roy T. Fielding field...@gbiv.com wrote: ... The original developers are not ambivalent to this fork. Untrue. Christian and Remy are, and always have been, supportive. They were the ones to suggest the fork, rather than trying to make the changes in trunk. I read the trac-dev mailing list. To say that they are supportive is a huge stretch of the imagination. They are sadly resigned to see a potential contributor decide to fork the code instead of working with them directly. And the rest of the community (which is far larger than the core) thinks the idea stinks. If you read trac-dev, you will also notice that the discussion about the so-called fork has more responses than all other threads in the last three months *combined*. Lots of navel gazing, not much work. (Though surprisingly, discussion *has* picked up in the past couple of weeks, so maybe this is a Good Thing all around.) Yes, that is a common side-effect of introducing a sense of awareness to a project that is otherwise in stasis. I have no doubt that Trac needs new blood and a driving force capable of energizing the community that developed on top of it. What you have is a vocal minority that disagree. Ethan is not even a core committer, as far as I can tell. It isn't a vocal minority. Not a single person outside of WANdisco considered it a good idea. Not one. Yes, most of the people commenting were the implementers of plug-ins, but they are also supposed to be part of the Bloodhound proposal. Edgewall, the copyright holder, is a defunct shell. That is a primary reason WANdisco wanted to move to the ASF: a home with actual backing and longevity. Then we should be able to convince Christian and Remy to join the initial committers list and bring the rest of the TRAC community with them. Why has that not been done? It has been. They have essentially said we've moved on, best of luck. I don't follow that. Is Edgewall still a formal organization capable of owning copyright? If not, who owns the copyright? Have Christian and Remy stopped all work on Trac, or are they just busy with their $jobs? And, no, the discussion has not been with the Trac community -- it was in private with a few individuals; as far as Apache is concerned, it never happened. Yes, there are many reasons to prefer that it is under the ASF. Many, many, many reasons. That doesn't change the fact that Apache only accepts voluntary contributions. Before you import code to the ASF, you have to get some indication from the authors that they either *want* us to maintain that code or that they have completely abandoned it. Not just a sigh and a statement that the BSD license is forkable -- they have to want Apache to build a community for maintaining that code. Otherwise, we don't, for social reasons that have little to do with licensing. WANdisco has definite problems in how they approach and work with open source communities. They discussed this stuff with the Trac principals privately, rather than with the broader community. But my read is that the Trac leads are supportive of Bloodhound. They are supportive of people doing work on Trac. They did not support a fork at the ASF. What they told WANdisco was that, rather than come to some artificial agreement on how they should work together before WANdisco had contributed anything, that WANdisco should fork the code and start by making contributions. That's it. The only reason that Christian has not directly opposed Bloodhound is because he believes the BSD license gives permission to fork the code. My interest here is seeing Trac revitalized, improved, and delivered as an awesome open source issue tracker. I'm tired of Bugzilla and (non-OSS) Jira. I like the Google Code tracker, but I'm biased there :-P There is no evidence to suggest that cannot be done on trac-dev. I'm not sure I agree with this statement. Trac has a singular and well-defined philosophy built around a small core and an environment of plugins. This isn't the place to debate the merits of that architecture, but suffice it to say that such a system can often require a lot of work to get to a usable state. The goals of Bloodhound are separate from that: create a full-featured issue tracker which is easy to deploy and use for end users and administrators both. Honestly, Trac is a good product, and is an excellent choice as the core for Bloodhound, but the community goals differ. Significantly. Those sound like the goals for a commercial distribution of an open source project. In any case, there is no evidence that it cannot be done on trac-dev because it wasn't attempted. Bloodhound won't happen on trac-dev because the Trac community is philosophically opposed
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 6, 2012, at 8:17 PM, Noel J. Bergman wrote: The ASF is not about code; it is about community. If a community forks, or otherwise emerges around a codebase, we are not accepting the CODE: we are accepting the COMMUNITY. One company is not a community. And it seems to me that if we are to say that a COMMUNITZY is not permitted to participate despite use of code that is perfectly proper according to the license, then we are beggaring out own license, the whole point of which is to permit forks, and to prevent a sole copyright holder from assuming control over the community. If there is no community for the original codebase, yes. 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. That does not stop people from forking the code elsewhere, perhaps in-house or at google code, growing a community over time, and attracting their own community. If a corporation were to create an ASF-licensed codebase, and later decide to take back control, would we refuse a COMMUNITY-based project based on that codebase? It depends on where the community wanted to take it. In this case, which is far more interesting than a theoretical case, a company with long ties at Apache has decided to fork an existing, community-supported open source project that is currently under the BSD license, without having made any significant contributions to that project in the past, and is using Apache's reputation as an excuse to place themselves in control over this new community at Apache. That is wrong. The original developers are not ambivalent to this fork. What they told WANdisco is the same that we would tell them -- the license allows you to fork the code if you desire to do so. They did not want a fork -- what they want is for WANdisco to participate in their own community *first* and then everyone can see whether the existing community wishes to adopt their changes (or not). The VOTE was based on misleading information. The Incubator PMC should declare it void and request a new proposal. The existing Bloodhound podling should be placed on hold until this is sorted out. If WANdisco wishes to fork trac for their own commercial reasons, they are free to do so under their own name and their own responsibility, not ours. If the existing TRAC community wants to join the ASF, then their community can be asked to put together a joint proposal to that effect -- not one dominated by a sole corporation that has not even been a part of that community. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Jan 7, 2012, at 2:10 PM, Roy T. Fielding wrote: On Jan 7, 2012, at 1:49 PM, Greg Stein wrote: On Jan 7, 2012 4:24 PM, Roy T. Fielding field...@gbiv.com wrote: ... The original developers are not ambivalent to this fork. Untrue. Christian and Remy are, and always have been, supportive. They were the ones to suggest the fork, rather than trying to make the changes in trunk. I read the trac-dev mailing list. To say that they are supportive is a huge stretch of the imagination. They are sadly resigned to see a potential contributor decide to fork the code instead of working with them directly. And the rest of the community (which is far larger than the core) thinks the idea stinks. http://groups.google.com/group/trac-dev/msg/96c8e39fa1c8e401 Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
incubator is a single group
Hi folks, It has come to my attention that we are wasting resources and time trying to manage separate committer lists within infra for every podling. That is something that we can effectively manage once a TLP has become self-governing and self-sufficient in its interaction with infrastructure. It is not something that we can effectively manage when we have dozens of podlings trying to make changes through the incubator chair. I *suggest* that incubator change the procedure such that all committers (or at least all committers within a single LDAP group) have access to all incubator areas and that new people simply be requested to only commit within areas for which they have been given permission by the podling developers. That will significantly ease everyone's job and allow more direct control by podlings for inviting/uninviting their devs. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Howl as an Incubator Project
On Mar 9, 2011, at 8:23 AM, Alan Gates wrote: Some context here for you. Howl is a project that was recently accepted to the Incubator. It is a proposed new component in the Hadoop eco system. There is significant concern in the Incubator that this will clash with the name of the Howl OW2 project (http://howl.ow2.org/) and thus cause Apache legal troubles. The relevant email threads can be seen at http://tinyurl.com/5w7y9p9 and http://tinyurl.com/4t7jjt9. As can be seen in the email threads some are concerned about legal issue while some feel that the use of the name is acceptable. There is interest in the team proposing Howl to keep the name since the name has already been in use for 9 months in the Hadoop, Pig, and Hive communities (without confusion or legal issues I might add). However, we would like to get legal's input on whether using Howl for this project name presents a risk for Apache. Thanks. It isn't just a legal issue. Generally speaking, it is rude to use a product name for an open source project when that name is already in use by another open source project (and in this case has been in use since 2004). What's more, their use of the name actually makes sense. We try not to be rude to OW, and they try not to be rude to us. So, the answer from this board member is no, you will not be allowed to use that name at Apache. Even if the incubator accepted it, the board would insist on a change later on because it isn't a nice thing to do to others. 9 months discussion in Hadoop/Pig/Hive is irrelevant when compared to seven years of actual product releases by that other project. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Proposal] Traffic Server
On Jun 15, 2009, at 5:56 AM, Leif Hedstrom wrote: Roy T. Fielding wrote: I like the idea, though I would prefer that a larger group of committers (outside Yahoo!) were known up front because that sounds like a big code base. Any chance you could convince some of the former coders to join in the proposal? This is definitely a valid concern. We will try to get more people involved now that the process has begun, but I don't know if or how soon we can get some external developers to sign up. It's a bit of a catch 22, since we don't have the source out there yet. I know, and they may be prevented (by former employee contract) from talking about it until after Y! makes the code public. I would just place it on the wish list of things to do before graduating. BTW, Traffic Server is a registered trademark (2304928) owned by Yahoo! Is that trademark going to be assigned to the ASF as well or does the project plan on changing the name? I would like to see how various bits compare to implementations within httpd, particularly the protocol bits. We have run TS through Co-Advisor a number of times, and it fairs pretty well (as well as Squid, at least). Would it help putting up the results somewhere (I'd have to verify that this is possible and doable first though)? And as I mentioned in the proposal draft, we run TS + apache together for many Y! sites, and they work very well together. Sorry, I did not mean to imply that acceptance was conditional on the code quality. I am just interested in seeing if our projects can help each other once the code is available under the Apache License. If there is a scarcity of mentors, then I will mentor this project. However, I'd prefer not to because my time is limited and I would not want to short-change the project. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Proposal] Traffic Server
On Jun 12, 2009, at 9:17 AM, Leif Hedstrom wrote: Good morning, We would like to submit the Traffic Server proposal to the incubator. Our draft is available at http://wiki.apache.org/incubator/TrafficServerProposal A quick overview of Traffic Server: Traffic Server is a Yahoo! / Inktomi caching proxy server. It has been actively developed and used inside Yahoo! for the last 3+ years, and we are now ready to begin the next step in it's evolution: make it Open Source. TS is a fairly large piece of software (300k+ lines of C/C++ code), and provides features and benefits lacking in many existing proxy/caches. I am obviously looking for feedback and comments on the proposal, as well as a few mentors. Doug Cutting has accepted to be our Champion. I like the idea, though I would prefer that a larger group of committers (outside Yahoo!) were known up front because that sounds like a big code base. Any chance you could convince some of the former coders to join in the proposal? I would like to see how various bits compare to implementations within httpd, particularly the protocol bits. However, I don't have the time to be a mentor. Cheers, Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[IP-CLEARANCE] httpd mod_fcgid
http://incubator.apache.org/ip-clearance/httpd-mod_fcgid.html Apache HTTP Server's mod_fcgid is a module for httpd that enables the server framework to provide FastCGI services using a clean-room implementation of the FastCGI 1.0 specification (http:// www.fastcgi.com/devkit/doc/fcgi-spec.html). All IP checklist items are complete. Roy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Click Incubation - Status
On Jul 30, 2008, at 4:15 PM, Malcolm Edgar wrote: One possible complication to this is that all the code in Click currently has a copyright header assigned to Malcolm Edgar, even if they were contributed from other comitters. So in committing code people have explicity assigned their copyright to me. This was a habit I picked up from working on Tapestry. If you have signed documents from each author saying that they have irrevocably assigned copyright to you, then you have copyright ownership of the work and there is no need to bother anyone else. However, I think that is unlikely, given the discussion so far. Just placing a notice on top of the work doesn't give you copyright, not does committing to a file that has such a notice constitute assigning copyright. Contributions to an Apache Licensed work are understood to be covered by the license itself (when no CLA is given), which defines a nonexclusive license and not copyright assignment. However I don't know whether this copright statement would has legal standing, or is in the spirity of Apache. If it has legal standing, then Apache has no choice but to accept it. Assignment, though, has very specific legal requirements. The spirit of Apache still requires that all the current committers on the project sign an iCLA, since that establishes a common agreement on their future contributions to any ASF project. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Click Incubation - Status
On Jul 27, 2008, at 9:22 AM, Andrus Adamchik wrote: Is there existing code in Click written by Ahmed? As getting an ICLA or rewriting this code will be required as a part of the IP clearance process. That isn't quite true. The ASF requires documentation that the original author has licensed the code to the ASF or to someone who can license it to the ASF. If, for example, the code was published by that author under the Apache License, BSD license, or any similar non-copyleft open source license, then the ASF can redistribute that code. We may need to retain some original license headers, but we do not need everyone who isn't going to participate to sign an ICLA. Likewise, an email message sent from the author saying that we can redistribute their code under the Apache License is a legitimate form of license -- just save the message in its original (raw) form. In any case, rewriting this code does not have any impact on copyright. Nobody can change the copyright on a work by copying it, even when the copy is from distant memory (think music for comparisons). The ideal outcome would be for Ahmed to send an ICLA, regardless of his future participation plans, but that's of course up to him to decide. Yes, that is the most sensible thing. He can send it via email if that helps. Because the iCLA is not a copyright assignment (just a non-exclusive license), we can rely on any written communication that can be reasonably determined to be from the author. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Do we really need an incubator?
Dims, I have to disagree. The releases that we allow incubating projects to make, with three +1s and a majority approval, are full Apache releases. They have been officially approved by the foundation and we are 100% responsible for their content. That's okay, because they also tend to receive far more detailed inspection and thus are better quality and more conforming to our policies then our pre-incubator TLPs. There is no reason for a separate repository. It certainly isn't relevant to a podling's desire to become a TLP -- that is more than adequately compensated by the freedom from slow IPMC approvals and ability to host their own website without the butt-ugly egg icon and disclaimers. A separate repo does not help protect users from incubator code, since users don't set the Maven configs that define which repos to use and which modules are dependencies. At best, what it does is add an irrelevant incubator layer on top of all Maven repo requests that masks the normal repo path from developers, introduces another way to inject insecure code, and wastes our bandwidth sending 404 responses to automated build requests. In contrast, if real incubator releases are allowed to be placed in the normal Maven locations, then the incubating config does not mask the normal Maven path, there is no need to send *all* repo requests to incubator first, the project documentation for Maven doesn't have to be a special-case, and releases are still subject to the same quality controls as all Apache releases. Regardless, the user never makes a decision regarding incubator code in the Maven repo. The user is either going to pull the incubator release directly and then build it using Maven with the provided pom, or some other project is going to make a decision to add the artifact (with incubator in its name) as a dependency. The Maven repo path is irrelevant to the user's decisions -- it just changes the background bit traffic and the load on our servers. In short, the policy is just plain stupid (speaking as a C developer who builds a few projects via Maven only a couple times a year). Yes, it would be nice if Maven was more secure, properly checked signatures, and properly delegated namespaces so that third-parties would be unable to add artifacts within other org's trees. None of those issues are specific to incubator. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Do we really need an incubator?
On Jul 7, 2008, at 5:01 PM, Justin Erenkrantz wrote: Apache isn't about 'community over code'. The code is just as important - if not more so. For Incubator releases, the releases aren't held to the same legal standard as releases from other PMCs. Huh? The only difference I know of is the possible presence of external dependencies on LGPL code, which is not a legal question at all. All legal issues are satisfied before we even let the code be imported, let alone released. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Q: ip-clearance step 5
On May 18, 2008, at 6:52 AM, Robert Burrell Donkin wrote: apache needs a record of the checksummed artifact. this is likely to be the zipped code. FTR, Apache only needs this if there is no other way to map the contribution to the contributor. The easiest way to map them is to have the contributor (or their employee) commit the code directly to subversion or attached to jira/bugzilla, in which case the checksum is unnecessary. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[IP-CLEARANCE] httpd mod_domain (was mod_dns)
http://incubator.apache.org/ip-clearance/httpd-mod_domain-clearance.html httpd mod_domain (nee mod_dns) IP clearance Apache HTTP Server's mod_domain is a module for httpd that enables the server framework to provide Domain Name Services (DNS). It was originally called mod_dns, but the name has been changed to avoid confusion with a different third-party module called mod_dns. item record Date 2008-04-18 Contribution mod_dns Contributor(s)Netmask (El-Mar) Internet Technologies Ltd., Issac Goldstand Software Grant(s) grants/netmask.tif Corporate CLA(s) cclas/netmask-el-mar.pdf Individual CLA(s) Issac Goldstand (issac) Location of importhttpd/sandbox/mod_domain/ Destination PMC Apache HTTP Server (httpd) Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (INCUBATOR-74) IP Clearance Template is rubbish
[ https://issues.apache.org/jira/browse/INCUBATOR-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591773#action_12591773 ] Roy T. Fielding commented on INCUBATOR-74: -- I like the approach, but the template only needs a single table: http://incubator.apache.org/ip-clearance/httpd-mod_domain-clearance.html We could add links from the table headings to their definition in the guide. IP Clearance Template is rubbish Key: INCUBATOR-74 URL: https://issues.apache.org/jira/browse/INCUBATOR-74 Project: Incubator Issue Type: Bug Reporter: Robert Burrell Donkin Attachments: ip.diff http://mail-archives.apache.org/mod_mbox/incubator-general/200804.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (qpid) Diversity
On Mar 7, 2008, at 11:07 PM, Niclas Hedhman wrote: On Friday 07 March 2008 16:39, William A. Rowe, Jr. wrote: So the CCLA exists for those who's employment agreements would otherwise cause them to violate their claims made via their CLA contract. Uhhh So, are we now saying that heaps of people don't need to get the CCLA from their employer? I thought the CCLA was the belt and suspenders to ensure that the employee has the right that he claims. Otherwise, why is the CCLA a matter between the employer and ASF, and not a standard document to be signed between the employer and employee, for the employee to keep. Because it is more politically correct (easier for the employee) if the paper says it is coming from the ASF, it is a lot easier for the employer to understand why another corporation would need that permission, and it is a lot less likely to be lost if it is recorded with a third party. The employee can (and should) keep a copy for themselves in their own records. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Sling
I would just add that JSR-311 might also be an option. As an aside (and since you folks are on the Expert Group), do we know if JAX-RS will be under a suitable specification license, or has Sun encumbered it as they have other Sun-led specifications? We don't know. We won't implement JSR-311 if it isn't open, but at this point I wouldn't trust Sun even if they promised a BSD license. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: incubator releases need to be under www.a.o/dist/incubator
On Feb 21, 2007, at 2:50 PM, Leo Simons wrote: On Feb 21, 2007, at 1:08 AM, Roy T. Fielding wrote: One thing that seems to have been forgotten is that an approved release must be in the form of SOURCE CODE and must be placed in the associated PMC's public distribution area under http://www.apache.org/dist/ The second must there in that sentence has been topic of much debate. I believe the main arguments against it go along the lines of are not real apache releases, we should not bother our mirrors with this, goes against infrastructure release policy, etc. I think my point was that I don't consider it a debate any more. What is the point of debating something if we never make a decision? Should we interpret the below [...] as we make US government officials unhappy (to say the least) if we put releases (for their definition of release) that are or might be subject to export laws in any location other than www.apache.org/ dist/? No, it should be interpreted as: we made guidelines for the PMCs because we gave them guns with loaded ammunition and did not want them to shoot the collective us in the feet. Allowing a podling to make a release is giving it the gun, loading the ammunition, and then ... what? I think the same guidelines should apply to incubator WHEN incubator decides to make a release. The fact that the code came from a podling does not make the gun any safer. More to the point, incubator's lack of discipline in this matter makes it harder to maintain consistent documentation on our www dev site, which makes me very grumpy. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: podling BIS notifications
On Feb 20, 2007, at 10:55 PM, Cliff Schmidt wrote: +1 to everything above -- although, rather than saying a later notice needs to be sent out when the encryption functionality changes, I'd put it as, a later notice needs to be sent when any information on the prior notice has changed...but this would typically only be the case for changes in manufacturer to some included crypto component. See http://www.apache.org/dev/crypto.html#faq-additionalemails. Yep, I oversimplified. We don't know exactly where the line needs to be drawn, since the BIS has been very lenient or very overloaded in the past and never (to my knowledge) taken us to task for doing it wrong. Or maybe we always did it right. Nevertheless, the EAR is the law as far as the ASF is concerned, and has to be obeyed even if we think the law is confusing and pointless. My guess is that ongoing development of source code bits within subversion qualifies as an open conference, just like our mailing lists, and thus not subject to the export controls. It is only No -- the BIS folks consider open source development in between releases to be the same as beta releases. There is a separate license just for betas, but the TSU one is simpler. This is why we send the TSU notification prior to starting to commit encryption code to SVN. This is also covered in the FAQs: Ah, rats, I was hoping that it wasn't classified as 5D002 until the code was in functional form, since that is what the definitions in 772 and 740 would indicate. But you are right that what matters more is what BIS folks consider. http://www.apache.org/dev/crypto.html#faq-firstnotification http://www.apache.org/dev/crypto.html#faq-public If any of these FAQs could be more clear, let me know. Actually, I think it would be clearer as a step-by-step decision process rather than a FAQ. I'm not volunteering any more, though. ...although, speaking of the exports page, I noticed that there is now software with an ECCN of EAR99. I'm not aware of any software we distribute at Apache that meets this category. Can anyone tell me what the rationale is for this? Umm, my bad -- I read the definition on their summary page and followed how it was used by other companies. The definition in section 734 (c) Items subject to the EAR consist of the items listed on the Commerce Control List (CCL) in part 774 of the EAR and all other items which meet the definition of that term. For ease of reference and classification purposes, items subject to the EAR which are not listed on the CCL are designated as EAR99. is more clear. So, our software would only be EAR99 if it were not publicly available, since making non-5D002 software publicly available means the items is not subject to the EAR, so that is only a concern for redistributors that distribute modified versions. Not our problem. I'll fix the page. Damn spaghetti regs. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
incubator releases need to be under www.a.o/dist/incubator
At various times, various people have stated various rather incongruent descriptions of what has to be done when a podling performs a release http://incubator.apache.org/guides/releasemanagement.html One thing that seems to have been forgotten is that an approved release must be in the form of SOURCE CODE and must be placed in the associated PMC's public distribution area under http://www.apache.org/dist/ and by doing so ALL of our releases get archived at http://archive.apache.org/dist/ Aside from fulfilling the ASF's purpose as a foundation, placing releases in the appropriate location means that they will get mirrored correctly and archived automatically. In turn, that gives us a simple URI that can be used to direct government inspectors for the export license page http://www.apache.org/licenses/exports/ The export regulations don't care whether a product is labeled as incubating or not. Therefore, placing incubating releases somewhere other than regular releases is self-defeating. The Incubator PMC must ensure that approved releases are published in the correct location after being approved, such that the release is archived correctly, and the easiest way to do that is to follow the same guidelines as all of the other projects. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
podling BIS notifications
I noticed yesterday that James Snell was being very proactive and submitted the correct BIS notification for Abdera. http://mail-archives.apache.org/mod_mbox/incubator-abdera-dev/ 200702.mbox/raw/[EMAIL PROTECTED] However, please note that Abdera is not yet an Apache Project, even though it is a released product, and that the responsible party is the Incubator PMC. I have corrected the information on the exports page accordingly, which will show up on the live site after 5:11pm PST. There is no need to correct the notice. In the future, it is generally better for such notices to be submitted by an ASF officer and from an apache.org address. If the NSA chooses to knock on your door, we want you to be able to put the right hat on while talking to them. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: incubator releases need to be under www.a.o/dist/incubator
On Feb 20, 2007, at 7:11 PM, William A. Rowe, Jr. wrote:
In other words, we agree there is probably an export issue to resolve,
however /dist/incubator/ does not exist for a reason, and it would be
helpful if you ran changes to the incubator past the incubator PMC
before confusing our podlings with contradictory information.
Yes - it merits discussion, but what's happened several times with the
usual push-pull of the discussion here is that half the podlings race
off to the left while half of them are still on the right, and it
becomes impossible to manage.
No, what's happened is that the people pointing out the obvious
are usually shouted down by the people who never bother to edit
the documentation.
FWIW, compare incubating releases to tarballs in tlp.a.o/dev/dist/,
not those in www.a.o/dist/tlp/ - yes they are not mirrored and
archived, that's what SVN is for.
Those aren't releases. See the FAQ.
The only thing that the BIS is typically interested in is not what
we ship, but the source code in svn.a.o/repos/asf/incubator/{proj},
if I've understood the dialogs so far?
No, they are interested in anything identifiable as a product.
Once identified as a product, the next question is whether said
product has been released, since Release == officially given to
third parties == exported worldwide.
Therefore, the BIS notices (if needed) must be in place before the
Incubator votes on a release. An Incubator release is no different
from the eyes of the external world (and our legal risk) than any of
the other ASF releases. The ASF relies on the ability of the Incubator
PMC to make the decision of when to release. How a release is handled
after that decision is subject to ASF-wide policy.
... at least this is how they have been handled. Part of it is the
oversight and project health (they haven't graduated yet) and half
of it is to slow down the Apache Foo announcements following some
code dump. Once a project proves it can collaboratively develop
it's code base and create releases (not always as trivial to determine
as that would sound) then they need to be evicted from the incubator
to Project status. Progress, not perfection :)
Yeah, I know, but none of that matters to the BIS.
Noel J. Bergman wrote:
Roy,
At various times, various people have stated various rather
incongruent descriptions of what has to be done when a podling
performs a release
One thing that seems to have been forgotten is that an approved
release must be in the form of SOURCE CODE and must be placed
in the associated PMC's public distribution area under
http://www.apache.org/dist/
and by doing so ALL of our releases get archived at
http://archive.apache.org/dist/
The associated PMC would be the Incubator, and you might notice
that there
is not an incubator/ directory under those locations.
Yep. In other words: please create one and start using it.
As I understand it, the primary issue is that there has been a lot of
emphasis to say that Incubator releases are explicitly NOT
official ASF
releases and are not to be conflated as such.
Bah! Doublespeak is not doubleplusgood. It is an official release
*because* the Incubator PMC voted to release it, and therefore needs
to be processed as a release because that is what the delegated
authority of the board decided when they cast the release votes.
What you call the package, or any color you choose to paint it,
does not matter. The question regarding is it a release is a
simple metric: If the package is delivered outside the context
of the development group with the intent that it will be used
by third parties, then the package is released. End of story.
Doing that requires official PMC approval, which is the Incubator
vote, followed by the appropriate dropping of artifacts in the
locations that the ASF expects of all releases.
All I am saying is that the last part is not being done right now,
and hence the archives are not being populated with all of the
releases, and therefore the archives cannot be used as the pointer
to the BIS from the exports page to the released versions.
That's bad, for both historical and legal reasons.
Were they to be considered
official, at least at some points in the past, many ASF folks
would have
railed against allowing them at all. At various points, people
went so far
as to suggest that the Incubator be forked separately from ASF
infrastucture
to create more distance, which would be going too far IMO. So we
have made
every effort to keep Incubator releases and real ASF releases
separate.
Well, tell those people to think about *why* we have these procedures
in place for real projects, and then why it should be obvious that
encouraging podlings to avoid those procedures only increases the
risk to the ASF. If they don't like the perception, then they should
vote -1 on the release (and live with the fact that their perceptions
may be marginally insignificant compared with the majority's desire
Re: podling BIS notifications
BIS notices have to be made if a product contains encryption functionality controlled by the EAR's 5D002 classification, or is specifically designed to make use of a 5D002 classified item (as would the case if the source code contains calls to OpenSSL or JCE interfaces), or if any released package contains any other product that is classified as 5D002 (as it would if the Bouncy Castle jar was included in a release package). A conservative read of the EAR would indicate that JXTA depending on Bouncy Castle makes JXTA 5D002, so if Tuscany is specifically designed to use JXTA then it would also be 5D002. (The same sad fate applies to Apache httpd 2.x modules as well, apparently, even if they aren't designed to make use of the SSL components.) Hence, the podling should bring it to the attention of the IPMC when a release vote is made, and the IPMC chair should be the one to edit the exports page and send the appropriate message to the BIS *prior* to the release being published. Noel can delegate that if he wants, but whoever has the hat needs to be kept aware of the situation. The notice only needs to be sent once per product when it is first considered for release and later only if the product's encryption functionality changes. We don't know exactly where the line needs to be drawn, since the BIS has been very lenient or very overloaded in the past and never (to my knowledge) taken us to task for doing it wrong. Or maybe we always did it right. Nevertheless, the EAR is the law as far as the ASF is concerned, and has to be obeyed even if we think the law is confusing and pointless. My guess is that ongoing development of source code bits within subversion qualifies as an open conference, just like our mailing lists, and thus not subject to the export controls. It is only when the bits appear in functioning product form that the encryption controls apply (it is the encryption *functionality* that is controlled, so says the regulations, since everyone knows that encryption itself is not a secret technology). *shrug* But being proactive on the notice is always better than being reactive to government agents. Note, however, that if anyone commits something like the OpenSSL or Bouncy Castle source code and/or binaries, which are products in and of themselves, to the subversion instance, then the PMC must file an export notice for the subversion area even if no ASF product has been released yet. That is because distributing third-party products from a public web server is the same as exporting them. Personally, I think it is wrong for projects to commit code to subversion unless it is intended to be maintained as source, but I know that some real projects at the ASF are too lazy to write build scripts and instead use our subversion instance as a binary distribution medium. As far as timing goes, the notice should be sent as soon as it becomes clear that the product will eventually contain code that is designed for a given 5D002 product (i.e., anything that uses encryption for purposes other than mere authentication). Preferably, before that code is committed to subversion. The real benefit of having the exports page (aside from answering the FAQ) is that we now have a single source link to provide to the BIS that is independent of the product names and release versions, and so we can easily send the notice once, before any chance of an export occurs, and not worry about it later. Note: For those wondering about history, we submitted the equivalent of BIS notices for the Apache HTTP Server a long time ago when the ASF first began, and then again when the regulations changed, and again just last week to make the exports page the official source link. AFAIK, we have never received a response from the BIS or its predecessor, but that may have been handled by our legal rep. Cliff has been working on making sure that our process is officially okay. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
resigning from incubator pmc
I am too far underwater to keep track of the incubator mail, so there is no point in continuing to be on the PMC. I'll probably be back some day when I have a reason to justify the time and focus. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Synapse
+1 Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: release voting
On Dec 19, 2006, at 8:02 PM, Greg Stein wrote: On 12/11/06, Roy T. Fielding [EMAIL PROTECTED] wrote: ... Can a PMC chair veto a release? No. A chair only counts as one vote. A chair's only special powers are to receive things officially and ensure that the PMC does vote. Euh... no. Nowhere is that stated in the ASF Bylaws. They're quite mum on what the Chair can do. Yes, but Bylaws are subject to the General Corporation Law of the State of Delaware http://www.state.de.us/corp/DElaw.shtml and committees, unless explicitly stated otherwise, are expected to govern themselves under generally accepted codes of procedure. Like, for example, The Standard Code of Parliamentary Procedure, 4th ed. or some variation on Robert's Rules. Both of them disagree with your interpretation. Officers can be delegated certain duties by the board, and once delegated the officer has the implied power to do whatever is necessary to carry out the functions and duties of that office. But those duties must be specifically delegated in the resolution or bylaws that create the office. The Chair *is* an officer of the corporation, though, and that implies a lot more than what you've stated. An officer can make binding decisions for the corporation. In the case of a project VP (the Chair), they can effectively do anything necessary within the realm of their project that is appropriate for that project. Consider: RESOLVED, that the office of Vice President, Apache Labs be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Labs PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Labs PMC; and be it further The VP is delegated the duty of chair of a committee and primary responsibility for management of the projects. *Everyone* knows that the chair of a committee does not make decisions *for* the committee. The resolution does not say that the VP makes project decisions or is delegated authority over the project as a whole. The only reason for the four paragraphs above it is to state that the board is delegating that authority to a committee, not to a single person. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as Apache Labs, be and hereby is established pursuant to Bylaws of the Foundation; and be it further That is the operative authority and it is not vested in the chair. This specific type of delegation is defined by our Bylaws and is specifically intended to be in the form of a committee, which means that the decisions are made by committee decision. The chair is not delegated authority over the projects -- only responsibility to manage the committee, and thus the only decisions that a chair can go hog-wild on are the establishment of unusual project bylaws or appointment and removal of committee members (which requires an ACK by a board member). The only way that the VP can make unilateral decisions for the project is by first removing the rest of the PMC -- otherwise, it is the committee that is given authority to make project decisions, not the VP. Putting it another way: there would be no reason to establish a committee if decisions are to be made by the officer alone. Any officer is capable of creating their own committees to delegate their own duties (though not their responsibilities), so the board resolution to do what you indicate would just appoint an officer with both responsibility and authority and be done. The whole reason for appointing a committee, and further to retain control over the membership of the committee, is to have a committee duly consider and act on project decisions rather than an individual. All of our TLP resolutions have that paragraph. With that paragraph, and VP status, I consider the Chairs to be able to do just about anything that is in the best interests of their project (and not counter to other interests of the ASF). *shrug* I don't think that consideration is supported by either. We'd probably have to get Drew Wright to judge what it means, since he wrote the original paragraphs. The ASF Bylaws basically restate the above: ...the chairman of each Project Management Committee shall be primarily responsible for project(s) managed by such committee, and he or she shall establish rules and procedures for the day to day management of project(s) for which the committee is responsible. I've always interpreted the VP as the one to define the rules of the PMC. They are the actual hand of power, but the Board expects them to operate that power in a certain way. If they misuse it... well, that's the end of that. Those expectations are things like voting procedures, consensus rules, blah blah blah. There is a cultural definition of *how* the VP should act, but when push comes to shove, I've told Chairs
Re: release voting
On Dec 20, 2006, at 3:20 AM, Niclas Hedhman wrote: On Wednesday 20 December 2006 18:04, Roy T. Fielding wrote: On Dec 19, 2006, at 8:02 PM, Greg Stein wrote: That's how it works. No, that's not how it works. Isn't it a bit scary that two of the most respected members of ASF don't agree on how ASF operates when push come to shove ? No, it only proves that we aren't machines. The exact details of how it all works are not written down because people are expected to use their own judgement to handle exceptions gracefully and make the process more fluid when there is clear agreement. For example, most of the PMC decisions are not made by vote -- PMC members simply go along with what the other members are doing until there is a disagreement, and the formal process only kicks in when consensus is unclear or when the legal risk requires that a formal decision be recorded (as in release votes). In any case, the board does have the ability to delegate additional powers to an officer when that is believed to be good for the ASF. The process can also change over time if needed. However, I think we should operate on the principle that the power to make decisions is vested in the committees, and it is only the power to implement those decisions that the officers can wield as needed. If an officer believes that a release package should be vetoed for legal reasons, then they should inform infrastructure to remove the release from distribution. However, that doesn't change the fact that a release was cut, a version number assigned, and a decision made by the project to release. It may seem like a small twist on semantics, but I believe it to be an important one. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
release voting
On Dec 10, 2006, at 5:11 PM, Jason van Zyl wrote: On 10 Dec 06, at 8:02 PM 10 Dec 06, Martin Cooper wrote: On 12/10/06, Jason van Zyl [EMAIL PROTECTED] wrote: On 10 Dec 06, at 6:40 PM 10 Dec 06, Roy T. Fielding wrote: On Dec 10, 2006, at 5:47 AM, Karl Pauls wrote: We ask that you please vote to approve this release: [ ] +1 Approve the Felix 0.8.0-incubator release. [ ] -1 Veto the release (please provide specific comments) BTW, this Veto thing is wrong. I've been meaning to mention it since several podlings have used this template. It is not possible to veto a release -- all releases are majority votes. +1 just means yes and -1 means no. Really? I thought that would be considered a technical thing? If you know a release is getting pushed out when it shouldn't because it's premature that on technical grounds you could say that it doesn't meet the requirements of a beta say? Or that it has know flaws and shouldn't be released? No. The only things that can be vetoed are specific changes, and the veto must have a technical reason that is valid for that change. Otherwise, one stubborn person can effectively kill a project simply by vetoing every choice made by the group. See the section on Votes on Package Releases here: http://www.apache.org/foundation/voting.html Yow, more hopelessly vague wordings. Look at the original httpd voting guidelines for a better picture. Can a PMC chair veto a release? No. A chair only counts as one vote. A chair's only special powers are to receive things officially and ensure that the PMC does vote. They can stop a package from being published if it has not yet been released by vote of the PMC, but they can't unilaterally decide to release or unrelease a given package. If a chair wants such a thing, they need to convince a majority of those voting to support their position, just like any other majority decision. Under no circumstances does a chair have any other special powers. We burden the chair with infrastructure tasks just because we need to delegate some of that work, not because we think they are making decisions for the PMC. A project decision must be made by the project. The responsibility assigned to the chair by the bylaws is to give one person the responsibility to ensure that decisions are made by the project and maintain communication with the board -- it is the PMC that is given authority to make project decisions, not the chair. An RM can choose not to upload a release, but the package is released if the project votes to release it. Infrastructure or the Board can remove a release from our websites if that is in the ASF's best interests. There is no legal veto. If a legal problem is found with a package, the ASF expects the responsible PMC members to change their own votes in response to that discovery. If for some odd reason that does not occur, the Board can direct infrastructure to do anything needed, but it can't rewrite history -- the package has been released and the most the ASF can do is make it hard to obtain by stopping our own distribution mechanisms. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deploying Incubator Maven Artifacts [was Re: [VOTE] Apache Incubator CXF 2.0-M1 Release (RC 3)]
On Dec 7, 2006, at 3:00 PM, Dan Diephouse wrote: On 12/7/06, Daniel Kulp [EMAIL PROTECTED] wrote: I would say for now we just remove that jar if it's needed. However, how did the servicemix and other projects votes pass if it's a requirement? Is this another new requirement in the middle of a vote thing? *wonders the same thing* Additionally, I just realized there are some projects too that have been publishing Maven builds that haven't been approved. Most recently Abdera did this [1][2]. They voted for the release of their binaries, but not their maven artifacts which they created/deployed post vote as I understand it (sorry to cause trouble Abdera folks, I was the one pushing for those builds too!). FYI, traditionally, all release votes are for the source code package and only that package. Once the source code version is set in stone, binaries and assorted other release artifacts can be generated by individual committers without a vote if the group trusts them to do so and they have a signed key. Some groups might require a vote on binaries as well, but the ASF only requires a vote on the source. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deploying Incubator Maven Artifacts [was Re: [VOTE] Apache Incubator CXF 2.0-M1 Release (RC 3)]
On Dec 7, 2006, at 4:09 PM, Dan Diephouse wrote: I must be missing something. If they aren't voted on, how do you know if they're valid and meet release requirements? It is impossible to verify that in a binary. We have to trust the person building it to do so according to an approved script. If people want to push a given set of binaries through a QA process and vote on the results, more power to 'em -- anything posted to our webservers is subject to voting if desired. However, they are just fooling themselves if they think testing the binary is sufficient to verify that the binary actually matches the source version. Real open source developers build their own. ;-) Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] publish openjpa 0.9.6-incubating release
On Nov 16, 2006, at 4:30 PM, Marc Prud'hommeaux wrote: We'll correct these issues asap. Once corrected artifacts are uploaded, I assume it will necessary to re-start the vote on the open-jpa-dev list before re-starting the vote here. Please correct me if I am wrong. That is correct -- each release vote is on a specific sequence of bits. Also, be sure the other developers know what is being changed and why, so that the project as a whole learns how to make releases (and what they should be looking for before casting +1 votes). BTW, why distribute a zip package? Wouldn't it be more sensible to distribute as a jar? Just curious. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] publish openjpa 0.9.6-incubating release
On Nov 16, 2006, at 5:22 PM, Marc Prud'hommeaux wrote: BTW, why distribute a zip package? Wouldn't it be more sensible to distribute as a jar? Just curious. The zip contains documentation, examples, and the dependency jars required to run the examples. Yes, I know that -- the point was that the jar format, as in jar cvf mypackage.jar mypackage is a general archive format that uses ZIP compression and can be unpacked by anyone who has installed java. Is there a reason to use a separate packaging format that is specific to winzip? I use gzipped tar for C releases and jar for java releases, but I have also seen a lot of other java projects that distribute both a .zip package and a tar.gz package. I was wondering if you knew why. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] incubator voting process
On Nov 10, 2006, at 7:18 AM, Sam Ruby wrote: There seems to be a persistent delusion that [EMAIL PROTECTED] is where incubation happens. The reality is that all the real incubating happens on the PPMC private and dev lists. We can correct this in one of two ways: recognize what actually is happening, or make what we say is happening actually work. If we go the first route, then we should treat this list as an announcements list. Results of votes for releases and graduation are posted here, and incubator PMC members will be given 72 hours to raise an issue. If we go the second route, then we need to set the expectation that most PMC members participate in most votes. Sorry Sam, that is absolute nonsense. The reason why we have a minimal quorum requirement of three +1 votes is so that the vast majority of PART-TIME, VOLUNTEER open source developers can focus on what is important for them today. In particular, a +1 vote to release should never be given by ANYONE unless they are reasonably sure that the release is good for Apache. It is the responsibility of the people who want to make a release (on any project) to attract enough real review from responsible PMC members to generate the three +1 votes. If the product cannot attract that many votes with relative ease, then there is obviously something wrong with the release (socially or technically) and it should not be forced out. It should be left on the pile of almost-done releases, with a note to the effect of needs more review. If a podling has enough committers to vote for a release, the IP constraints have been cleared (a prerequisite), the mentors have voted for the release, and they *still* don't have enough binding +1 votes to actually make the release even when the rest of the Incubator PMC is off in the woods navel-gazing, then that podling SHOULD HAVE ALREADY GRADUATED. Apache Jackrabbit did only one release in incubator. It is not necessary for podlings to generate PUBLIC releases every few weeks just to hit a milestone. Just do one. A podling with an active community and proven IP-completion should prepare one release, seek out individual reviews if necessary, and then graduate. The last thing we need is for Incubator PMC members to be guilted into voting for a release that they care nothing about. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weirdness with the web site
On Nov 10, 2006, at 3:40 PM, Garrett Rooney wrote: So, I'm trying to finish off the job of removing lucene4c from the web site, since it's been retired it shouldn't be showing up in the list of podlings and what not, and when I'm generating the site I can't help but notice lots of changes in there that are totally unrelated to what I just changed. Somebody made a big change this morning. Probably platform differences. Are people just not checking in the generated files when they make changes? I mean is there some reason that the recent changes in guides/releasemanagement.html hasn't been pushed out yet? No idea there. Similarly, I'm seeing a number of files that show up with every single line changed, when AFAICT all that should change is the removal of a single line from the list of projects. What's up with that? Do you really want to hear my opinion of Subversion's lack of a centralized default for svn:eol-style=native? Maybe you could implement a variation on svn propget -R that returns the path to all files the do not have svn:eol-style=native. *sigh* I'll just use a find pipe. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wikis
On Nov 9, 2006, at 10:52 AM, Don Brown wrote: What exactly makes something a part of the official ASF infrastructure? I thought it was that a member of Infrastructure had volunteered to maintain it, and if that's the case, Confluence is indeed a part of the official ASF infrastructure since I, as a member of ASF and Infrastructure, have volunteered to maintain it. When infrastructure votes to maintain it for as long as the projects wish to use it, then it is infrastructure. Right now, Confluence is just an experiment and we made that abundantly clear. The first two people who promised to maintain it disappeared immediately after setup. One new person is not sufficient to maintain anything, even though the effort is appreciated. To be maintainable, it must be possible for the entire team to maintain the working instance. That means documenting what to do when it breaks, preferably somewhere that is accessible when it happens to be broken (like under the infrastructure subversion). Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [site] can someone fix the permissions...?
done. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket interim release
On Oct 29, 2006, at 5:37 AM, Upayavira wrote: The Wicket community is attempting to steer a difficult course between supporting its existing users and also entering Incubation. The community is committed to incubation within Apache, but at the same time wishes to make the transition for its users as manageable as possible. It has been decided that incubator releases will start with the 1.3 branch, as 1.2 is more or less in maintenance mode, but also contains some licensing issues that would make it difficult to release as an incubator release. Therefore, this email is to inform the Incubator PMC that the wicket community are planning to make a release, independent of Apache and the Incubator, for release 1.2.3. Great, no problems there. It isn't even necessary to mention Apache. The following notice will be included in the release. NOTICE.txt: Er, no, that's wrong. Assuming it is using the Apache License, the only things that should be in NOTICE are mandatory credit/notice items that you expect all downstream redistributors to include. In other words, the content of an About... style dialog, wherein the contents are required for redisplay by others. If a disclaimer is desired, just put it in the README file. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JiniProposal - BraintreeProposal
On Oct 27, 2006, at 9:21 AM, Jim Hurley wrote: On Oct 25, 2006, at 6:35 PM, Noel J. Bergman wrote: Greg Stein wrote: It doesn't matter whatsoever as long as you are VERY consistently calling it Apache Braintree as you should be doing _anyways_ Would that apply equally to the two names that were more highly rated by the JINI community than the one selected? What is the criteria? This topic comes up quite often. --- Noel Does this same criteria apply to any name? I'm questioning whether I understand the rules, so some clarification would really help. Ah, crap, more mystery advice. A trademark is still a trademark -- adding Apache on the front only makes the use possessive of the mark, which is even more likely to get us sued than just using it plain. As a general rule, consider what some big-angry-corp would do if we did the same with their name. For example, Apache Java or Apache Windows, both of which would result in a cease-and-desist letter in short order. I thought for a second that Braintree would be clear of trademark, but it isn't now: http://tarr.uspto.gov/servlet/tarr?regser=serialentry=78891872 which is a recent application. So, once again we are back where we started -- it is safe to go ahead and start the podling as braintree, but it is most likely to end up being renamed to jini before it graduates (assuming that Sun does transfer the mark). Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Harmony to TLP status (pending board approval)
+1 (travel delayed) Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] graduate harmony podling
On Oct 21, 2006, at 3:24 AM, Leo Simons wrote: This is *not* an actual vote. The vote is on harmony-dev; see Well, then, why did you call it a vote? This is what we call confusing the voters, ballot irregularities, hanging chad, and other fun things that cause unnecessary wars. I don't understand why the mentors are making this process so hard. At no time whatsoever during this entire discussion was it ever possible for Harmony to have failed a graduation vote given the number of PMC members who are involved in the project, yet you seem bound and determined to attract as many -1s as possible by dicking around with a fairly easy procedure. Look, this is what I did for Jackrabbit: http://mail-archives.apache.org/mod_mbox/incubator-general/ 200603.mbox/[EMAIL PROTECTED] There is no need for special events, no need for advance polls of consensus, no bizarre multi-list calls for non-voting votes, and no pissing and moaning about the questions asked by Incubator PMC. Just have the project vote on graduation FIRST and then use that as fodder for the vote by Incubator PMC, answer the questions as best you can, and be happy as individuals become satisfied and add their +1s. When that looks like a positive outcome, send the resolution to the board. If you don't do that, my guess is that the board will tell you to do it all again before the resolution is considered at the next meeting, because Harmony is not a special case. Roy [anticipating that this message will be delayed due to move] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to read and write e-mail @ apache (was: Re: [VOTE] graduate harmony podling)
On Oct 23, 2006, at 12:52 PM, Leo Simons wrote: Change the subject line when you change the subject...done. But you didn't change the subject, so that was a bad idea. On Oct 21, 2006, at 11:39 PM, Roy T. Fielding wrote: On Oct 21, 2006, at 3:24 AM, Leo Simons wrote: This is *not* an actual vote. The vote is on harmony-dev; see Well, then, why did you call it a vote? You know, that *was* explained in the parts of the e-mail you snipped, if briefly. Yeah, yeah, I know that part -- I snipped it because I am tired of the long, very annoying, pissing and moaning process that seems to require a larger quantity of email instead of simply doing the easy things that I (and others) have suggested. This is what we call confusing the voters, ballot irregularities, hanging chad, and other fun things that cause unnecessary wars. Hmm. I find this particular decision to hold a vote somewhere else from standard somewhat annoying (but understand the rationale), agree it is a confusing (lots of intelligent people around, hopefully they'll get what's going on), see irregularity but not with the ballot itself, have no idea what hanging chad means, and I don't understand how any of this is funny at this point. Being a pacifist, I certainly agree all wars are unnecessary. The point is: Harmony would have graduated last week if you had simply done a public vote on harmony-dev followed by a public vote on general at incubator. That's all there is to it. ALL OTHER COMMUNICATION beyond those simple two tasks are totally unnecessary and caused simply because the mentors are not doing what everyone else expects of a podling. I don't understand why the mentors are making this process so hard. It is clear by now that you don't understand or disagree with some of the decisions harmony's mentors have made or things they have done. I think I've made a big attempt at making a hard process (given the amount of e-mail the incubator regularly gets about its complex processes, I wouldn't say its easy) as easy as possible, so this comment frustrates me a lot, Roy. I hope you can qualify it so I may learn. Further down is a detailed POV with some specific questions on this. It is easy if you do it the way I did it for Jackrabbit. It would have been even easier for Harmony given the number of PMC members involved. How can I qualify it any better than that -- you had the votes already, and this interminable DISCUSSION-WITHOUT-VOTING is just costing votes. At no time whatsoever during this entire discussion was it ever possible for Harmony to have failed a graduation vote given the number of PMC members who are involved in the project, yet you seem bound and determined to attract as many -1s as possible by dicking around with a fairly easy procedure. joke type=badOh yeah, I'm very determined to attract -1s. As much as possible. The way the - can sometimes hug the 1 if you have the right font...so much prettier than girls.../joke Seriously, can we please stick to civil language, and not attribute motivation that's so obviously, well, a misattribution? That was a sarcastic view of your actions so far. Allow me to demonstrate ... Just have the project vote on graduation FIRST Once again, that has happened, on harmony-private (yes, I complained about the vote being private. Like a broken record). It says so in the first line of the first e-mail on this subject: http://mail-archives.apache.org/mod_mbox/incubator-general/ 200610.mbox/[EMAIL PROTECTED] QED. You do know my opinion on voting in private, right? You do realize this is a public decision that must be made by the project, not by the mentors or any individuals who happen to reside on the private list, right? So, you should understand that holding an important project discussion on the private mailing list, let alone a vote, is more than sufficient justification for everyone here to vote -1 on graduation. Right? Why isn't that clear? It is absolutely forbidden for any Apache project to manage the project from a private list, with special exceptions given for voting on personnel and non-disclosure security items. I reminded people of that when I changed the list names by including the full text of the board resolution. Everyone on the list is responsible for preventing its misuse and, if need be, request removal of the private list if the participants can't use it correctly. When someone misdirects a public discussion to a private list, the only appropriate response is to end that discussion and move it public. If they don't obey, terminate the project. Again, each reply I have received so far has made me less and less inclined to vote for graduation of Harmony. I had no reason to believe there was anything wrong with the project until this discussion started, and the project itself seems to be behaving correctly, but this whole graduation discussion is just one fatal mistake after
Re: Checkpoint on Harmony (Re: [discussion] Harmony podling to ask for vote for graduation)
On Oct 20, 2006, at 3:34 AM, Tim Ellison wrote: To be clear, our snapshots are more than a simple snap of Subversion -- we (the Harmony community) discuss the right time to create the development snapshot to accommodate known instability caused by work in flight, publish the snapshot with the required incubator disclaimers, license and notice files etc., and encourage people to test them and report problems before we announce them on our website news page. No, to be clear, a snapshot is (by definition) a simple snap of svn. What you are calling a snapshot would be what *we* call a developer release -- the only difference is that you haven't tagged the revisions (just using recorded revision numbers) and you haven't signed the packages. In other words, if you have a PGP/GPG key, it would take you less time to satisfy the Incubator PMC than it did for me to write this message. Conducting a release, even a faux release, is probably a make-work task -- I believe we can do it if that is the only concern, just don't move the goalposts until we get back ;-) You see, this is why the process is needed. You have apparently been doing developer releases all this time, minus the two tiny steps needed to make them complete. A full release is just a developer release plus formal vote, which is not necessary at this time given the roadmap. Becoming a TLP means that you already know this stuff and can enforce it without any worries from the board. If this is the last thing you needed to know, that's great. [And if the mentors would just shut up for a minute and let the project prove itself, maybe you can graduate. That is, if anyone ever bothers to call a vote.] Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Checkpoint on Harmony (Re: [discussion] Harmony podling to ask for vote for graduation)
On Oct 19, 2006, at 3:32 AM, Geir Magnusson Jr. wrote: I agree with the motivations behind asking for a release, but disagree that a release is the only way to satisfy IPMC's need for information about the health and capability of a podling's future life as a TLP. It isn't -- it is just one of the most obvious ways. We've had 4 reports from the 4 mentors of the project, 3 (Stefano, Leo and Dims) that I would argue are arms-length mentors who are not as closely invested in the project as I am, and are well- known for their directness, honesty and openness. I'd like to ask that those who have asked for a release to assuage concerns about community health and capability to please read those 3 testaments from the mentors (ok, in Leo's case, 71 or so...) and please consider withdrawing your request for a release. That's silly -- why would people who think a release (or at least the release process) is a useful learning process drop such a *request*? I could understand your concern if it was expressed as a requirement, but it most certainly wasn't. Felix was a slightly different concern because it was obvious that the code base hadn't been prepared for a release yet. If we can reach consensus (with the exception of Mads who doesn't want to see Harmony here, and Roy for other good reasons due to my stupidity), I'd like to then move to the ratification vote. I don't think you understood my concern. A random individual shows up and makes an idiotic statement about the Apache process, and the only response (aside from my own) was two private emails. You know how I feel about private emails, particularly unarchived private emails. What I wanted to see was someone from the project who IS NOT a mentor actually demonstrate that they comprehend the process by participating in it on the public list rather than just following your lead. The goal of a self-governing TLP is one that can still govern itself even if the annointed one gets hit by a bus. That may be true of Harmony, but I have yet to see an example that showed it. While I have a great deal of respect for the mentors and would have no reservations if they were the project community, they are not the project community. I trust that the mentors know what they are doing, but I also know that it is difficult to keep a perspective when you are close to the community. That is why I ask questions. That is why Jackrabbit did not graduate until after it made a release, and it was that release process that finally created a project that was independent of me because someone else had to step forward and take on the role of RM. In any case, the point here isn't to reach consensus. It would be nice to have, but creating such a high bar is truly a waste of time when it comes to graduating a project. People here need to be able to express their fears, uncertainties, and doubts about all sorts of issues and then we can all judge whether the benefits outweigh the FUD. That is what a vote is for -- votes that merely rubberstamp discussions are a waste of time. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discussion] Harmony podling to ask for vote for graduation
On Oct 18, 2006, at 11:14 AM, Don Brown wrote: Agreed. I don't think it is fair to be making up graduation requirements right when a project is about to graduate. The graduation requirement is that a majority of the PMC members agree that a podling should be graduated. Geir asked for a discussion and he got one, so I don't see any justification for complaining about the responses. I would have just explained the current status and asked for a vote. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discussion] Harmony podling to ask for vote for graduation
On Oct 18, 2006, at 1:25 PM, Grote, Judy wrote: He just never seems to give up--like a small child not knowing when to stop. No, more like an old grandpa who sees his grandkids grab a pair of scissors and then asks the parents whether they've taught them not to start running around the room doing acrobatics with scissors. A small child would just delete the repository and say oops. It is something I do by habit, after being exposed to so many clueless twits like yourself. I would like the ASF to survive its growth. Besides, I was about to vote +1. You just changed my vote to -1. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Mark lucene4c as dormant
+1 Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] approve the 4.0.2 (RC4) release of ActiveMQ
On Oct 9, 2006, at 2:59 PM, robert burrell donkin wrote: the source distributions unpacks to the same directory as the binary. this is inconvenient for users. it's better to unpack the source to incubator-activemq-4.0.2-src. I disagree with that. Usually, a source distribution should be the entire distribution tree before an ant/make/maven, and the binary distribution should overlay on top of that into new subdirs of the main tree. Some of the duplicate files get replaced that way, but it is better for the user to have one tree. I don't think there is a generally accepted Apache way of separating these things, since the really important part is the source tree. I think it is important to make it clear that the binaries are just a convenience layer and not a separate distribution (even if they are distributed separately). Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Policy on Initial Committership
On Oct 4, 2006, at 7:56 PM, Noel J. Bergman wrote: Roy T. Fielding wrote: The only question is what authority is granted to the PPMC by the Incubator, and every podling since Geronimo has acted according to the policy that all decisions are made by the PPMC with a minimal quorum of three PMC +1 votes. EXACTLY! A minimum of three PMC +1 votes. Because that's what we need, and those are the ones that are binding. Without that minimum quorum of three PMC +1 votes, you don't have enough binding votes. Every vote that counts toward the majority is a binding vote. If the PPMC members out-vote the PMC members on any issue, the majority still carries. If a committer can veto a commit, then they have a binding vote. Are you using the term differently? I really don't understand how you can expect a PPMC to make a decision on anything if they can't vote and be counted. I thought that is why we created PPMCs. I wanted to put everyone on the Incubator PMC and thus solve both problems, but others were satisfied by the delegation, based IIRC on the fact that the board resolution that created the Incubator is different from any of the TLPs. *shrug* Maybe we should just change the bylaws? Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy on Initial Committership
On Oct 3, 2006, at 7:08 AM, Newcomer, Eric wrote: As we have also seen in the discussions on this topic it is natural for a project to review and revise the committers list as it progresses. But let's at least get CXF off to a good start! Or kill it now and let the proposers compile a list of individuals that have actually earned commit rights on the project. My point was that the Incubator PMC approved a proposal. Thus, if any corrections are needed prior to initial set-up, the proposal would need to be voted on again (and I suspect would attract more attention the second time). Alternatively, set it up with a real PPMC consisting of everyone on the list and let that group decide an objective criteria (within the limitations imposed by the ASF) for who should have commit access. BTW, somewhere along the line people started calling this project CXF. That is a fine name, but isn't the one in the proposal. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Policy on Initial Committership
On Oct 3, 2006, at 11:46 AM, Noel J. Bergman wrote: Roy T. Fielding wrote: I don't care what the PPMC decides to do provided that it is the PPMC that makes the decisions and that decision is made on an Apache mailing list. Mentors have NO RIGHT and NO RESPONSIBILITY to make decisions on behalf of a project as if they owned the project. The Mentors are only there to help the project govern itself and, in some cases, be counted as one of the people on the PPMC. To be really picky, that is not quite accurate. I wholeheartedly agree that Mentors have no right to make decisions as if they owned the project. They are there to help and be part of the community decision making process. However, Mentors have the only binding votes. You have many times decried giving binding votes to people who are not on a PMC. That's why we created the PPMC == the entire set of committers of the podling and the Mentors. They do have binding votes on everything *except* releases because we delegated that to them, right? Fools may call it bureaucratic and too much overhead for open source, but it is that adherence to basic principles of cooperative self-governance that allows an Apache project to survive the passing of fools. We exchange the efficiencies of individual dictatorship for a less efficient process that requires more people to be involved (and thus buy into) whatever decisions need to be made. We cannot short-circuit that process while trying to instill it. I entirely agree, which is why you should re-read the proposed bootstrapping process. It is entirely about what you just wrote, above. It is entirely about a bootstrapping process so that the project can be more self-governing. No, your proposed bootstrapping process is nothing more than a bait-and-switch process with fancy clothing. You are assuming that the mentors will do the right thing once they have the right to make arbitrary decisions on behalf of the podling. That isn't why we have these processes. If we could all just assume that everyone is going to do what everyone else expects, then we wouldn't need these processes at all. The process exists both to set the proper expectation (committers == PPMC) and to enable the Mentors to help without making decisions *for* the project. Above all, the right process means people don't waste our time whining about it after the fact. The Incubator PMC (or any sponsoring PMC) should vote on a podling based on the contents of that proposal. It should not vote on a proposal and then tell someone we appoint to go ahead and do anything they want under the rubric of that project name. The podling-proposal has a list of people that are going to be governing the project and that list is the committers, not just the list of mentors. That is the only bootstrap process that has ever been documented. A project that wants a smaller group of people (or just its mentors) to be the sole source from which bootstrapping begins should not list any committers on the proposal. That way, when the sponsoring PMC votes to accept a podling, they do so knowing full well who is going to be making the next decision. Mentors are people we add to a project. They have nothing whatsoever to do with the initial committer process other than helping the podling make the appropriate requests to infrastructure. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Policy on Initial Committership
On Oct 3, 2006, at 1:55 PM, robert burrell donkin wrote: That's why we created the PPMC == the entire set of committers of the podling and the Mentors. this is not policy ATM Yes it is -- it was formally voted on during the Geronimo incubation. They do have binding votes on everything *except* releases because we delegated that to them, right? i don't understand how this can work with the current structure. AFAIK PPMCs have no organisational standing (they are no official committees) and are not recognized by the board. AIUI they cannot take decisions binding on apache. their main role ATM seems to be as a training exercise. How can they avoid making decisions that are binding on Apache? Importing code into subversion is a decision that is binding on Apache. It just isn't a very important decision. The PPMCs are making binding decisions every day -- the only condition we placed on them was that at least three +1 votes had to come from the PMC (whether or not those people happened to be Mentors) for releases and adding new committers. That does not mean the other votes are ignored. The only reason PMCs have organizational standing is because they are a group of named individuals on a committee that has been assigned a task by the board in accordance with the bylaws. A PPMC becomes an official committee as soon as the Incubator creates it, since its creation is well within the scope given by the board to the incubator project and the individuals are named in the status file. The only question is what authority is granted to the PPMC by the Incubator, and every podling since Geronimo has acted according to the policy that all decisions are made by the PPMC with a minimal quorum of three PMC +1 votes. bootstrapping is simply a description of the only process available ATM. the mentors (as incubator pmc members) are the only ones on the project who have the binding votes required to take decisions (such as appointed PPMC members). That just isn't true. Somebody took a thread out of context and applied it where it doesn't make any sense. The restriction that only a PMC can release software has very little to do with all of the other decisions a project might make. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Policy on Initial Committership
On Oct 2, 2006, at 5:28 AM, Jason van Zyl wrote: -1. Of the people participating in a new project, the Mentors are the least capable of selecting a PPMC. I don't think that's true. At least not in the case of CXF. You mean it isn't always true. I agree. In general, however, it is almost always true, and since we are talking about general incubation policy in this thread (not CXF), we should not assume that the Mentors have even the slightest clue about who deserves to be on the PPMC. The fact of the matter is that the proposal contains a list of initial committers, the people in that list agreed to lend their names to the proposal in an effort to make it more appealing for adoption by the Incubator PMC (or whatever other PMC is responsible), and thus it is the Incubator PMC that decides who will be on the PPMC. That's what I vote for when asked to vote on a proposal, and as far as I am concerned there will be no deviation from that list except by voluntary removal or formal action of the PPMC (including *all* of those people on that initial list as approved by the Incubator). Beyond that, I have no opinion on the specific conditions in CXF. I don't care what the PPMC decides to do provided that it is the PPMC that makes the decisions and that decision is made on an Apache mailing list. Mentors have NO RIGHT and NO RESPONSIBILITY to make decisions on behalf of a project as if they owned the project. The Mentors are only there to help the project govern itself and, in some cases, be counted as one of the people on the PPMC. This is really important. Fools may call it bureaucratic and too much overhead for open source, but it is that adherence to basic principles of cooperative self-governance that allows an Apache project to survive the passing of fools. We exchange the efficiencies of individual dictatorship for a less efficient process that requires more people to be involved (and thus buy into) whatever decisions need to be made. We cannot short-circuit that process while trying to instill it. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Policy on Initial Committership
On Oct 1, 2006, at 11:26 AM, Noel J. Bergman wrote: Taken from the Problem with commit rights on Celtixfire thread: - The Incubator PMC sets the Mentors, who form the initial PPMC - The PPMC (Mentors) elects additional PPMC members - The PPMC elects Committers This also implies changing the proposal's initial committers list to something suggestive not binding, allowing the the Mentors review and vote on comitters. -1. Of the people participating in a new project, the Mentors are the least capable of selecting a PPMC. They generally know nothing about the code or the community, but rather know how to get things done at Apache. The Incubator PMC is even less able than that when it comes to selecting Mentors in the first place. The people listed in the proposal as committers are the PPMC. If some project allows too many people to jump on the proposal at the beginning in order to make the proposal look better to Apache, then they are stuck with the results. Don't like that answer? Then dissolve the podling and start over. Have committers that haven't bothered to contribute? Then vote them off the island, just like a real PMC. Truth in advertising demands that you follow the process as described in the proposal and use the Apache mailing lists for all project discussions. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IRC Channel?
On Aug 15, 2006, at 2:38 AM, Ian Holsman wrote: It isn't the individuals who make the decision, but the community as a whole. If they feel more comfortable using X to communicate then fine. If a individual doesn't like the method the project is communicating with then it is up to him to convince the rest of the community/project to change. No. All Apache development decisions are done on public email lists. I don't think the board has ever allowed a project to adopt guidelines that differed from that fundamental requirement. probably.. i tend to exaggerate. but email is a *very* hard medium to communicate ideas. take this thread for example. If we were talking on the phone or on IRC it would been settled in 20minutes.. but now there are 20 messages over 4 days, and people like me jumping into the middle of it, using HTML mail and all that. How can it be settled in 20 minutes when less than 1/3 of the group is on-line? It is settled only in the minds of the clique that you are aware of at that time, which is precisely why it is not allowed as a decision-making method at Apache. Email communication is hard -- it forces most people to think before they write a lot of mindless drivel, or at least think before they press the send button on the drivel they wrote. IRC does not have that barrier, true, but that shows both in the quantity of drivel and the quality of the decisions made. I know of a solution that will bridge the gap, but it is still a cloaked start-up right now -- I'll send more info on that solution when there is something that we can use. Note that the fact that we use email to make project-level decisions doesn't mean we *do* everything by sending email messages and then waiting for responses. The vast amount of real work is simply done first and communicated later, prototyped/tested and then proposed as a complete concept, or discussed vaguely at some point in the past and then implemented by someone else off-line. I've seen a lot of discussions where people lead off with an open-ended question and then wait for a response, but that is usually for long-term issues or bike-shed topics that can't be settled quickly anyway. agreed... without experimentation we won't know if IRC or VOIP is better, and produces a better quality/amount. Hmm, IIRC, we already experimented on that issue and discovered the result. I think it was before your time, but APR was mostly designed on IRC and various in-person meetings. I only have one thing to say about that: http://www.utahphillips.org/stuff/mooseturdpie.mp3 Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)
On Aug 1, 2006, at 11:36 AM, Sanjiva Weerawarana wrote: On Tue, 2006-08-01 at 12:36 -0400, Carl Trieloff wrote: Brian, Just as in JCP, OASIS or W3C the real work happens on private channels, that said we are in the process of creating public pages, from which to link user and feedback lists for anyone to read, access and interact with the working group. Correction: W3C working groups do *all* technical work in public mailing lists that are open to all. That change occurred probably 5+ years ago. Umm, I don't think so. As a TAG member, I encountered many discussions that were in members-only areas, and they are still going on (XML Schema, for example). The TAG would refuse to participate in any such discussion, which often required permissions be obtained to move comments from a private forum to a public one. W3C decisions are all made in public. Maybe you are referring to working groups that have been initiated in the past five years? Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cayenne IP Clearance status: 4 icla's not obtained
On Aug 1, 2006, at 1:21 PM, Jean T. Anderson wrote: Cayenne has obtained ICLAs for all committers, including retired committers. They have also obtained ICLAs for any who submitted patches -- with the exception of 4 patch submitters whose contributions were minor, trivial, reworked or broken [1] ([1] is also included down below). 6 files/classes are involved and an example of trivial is at http://tinyurl.com/o9vpk [2]. Is this sufficient? Or does something more need to be done? A new file is not a trivial addition, even if it is simply filling in a template. A change only qualifies as trivial if it is a simple fix to an existing file (i.e., what the lawyers would call a repair as opposed to a new expression). I would just delete the one example of a trivial new file, especially if it doesn't work anyway. Also, reworked doesn't change the IP -- it just adds to it. It matters more how the IP arrived into the project. If the patches were all published by the original authors to a public list or bugzilla with the stated intention of being included in an open source product under non-copyleft terms, then that should be sufficient for the ASF. We just need to record the point of origin. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: piling on
On Jul 22, 2006, at 1:50 AM, robert burrell donkin wrote: no change is necessary - the current policy is sufficient. Well, no, the expectation is clearly being set that anyone can add themselves to the proposal on the wiki, and I for one vote to approve a proposal based on both the wiki and the emailed content. If the emailed version is different from the wiki, then that will get a -1 from me simply because they are inconsistent. ATM the proposal on the wiki is not normative. the sponsor votes on the proposal as submitted to the list. this proposal contains a number of names proposed as initial committers. the sponsor votes to accept the proposal submitted including the list of initial committers. so, the list of committers is specified by the proposer and approved by the sponsor. In theory, yes, In practice, no. A proposer should not be placed in the position of fighting a wiki-edit war for consistency when it is far easier for us to tell volunteers to be polite by asking the proposer for permission before editing *their* proposal. what other goals would any new policy have in the area? Just a small bit of documentation for people preparing a proposal to inform them that they don't have to accept additional committers during the proposal process. There is a serious social disconnect here: people who are making a proposal are extremely sensitive about pissing us off, and will tend not to reject an added committer even when they know that person is not qualified or is deliberately attempting to steer the project in a direction that it may not want to go. We need the policy to protect new proposals from being unduly influenced by our already established mindset. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: piling on
On Jul 20, 2006, at 7:56 PM, Sanjiva Weerawarana wrote: On Thu, 2006-07-20 at 15:00 -0700, Roy T. Fielding wrote: I think so -- an unwelcome mentor is a waste of everyone's time. I also think mentors need commit access, since I don't believe it is ^^ This is the documented practice; see http://incubator.apache.org/incubation/ Roles_and_Responsibilities.html: The candidate shall declare an initial set of committers. On acceptance of a candidate project, the assigned Mentor shall be given access to the Podling's cvs repository for the duration of the incubation process. This is to allow the Mentor to perform their incubation duties, and is for administrative purposes only. To be given full committer privileges, such as the right to add new code to the repository, the Mentor must earn them as would any other potential new committer. In some cases, the Mentor may be part of the initial set of declared committers, but this is not a requirement of the Incubation process. However, note the emphasis on administrative purposes .. you seem to indicate more access than that: No, I didn't. I indicated that the mentor needs to help do the work. Administrative work is a huge part of getting a project going. I include in that things like setting up accounts, helping infrastructure, making accurate infra requests, following up with root responses, setting up subversion directories, and developing a process for publishing a website. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: piling on
On Jul 20, 2006, at 7:30 PM, Sanjiva Weerawarana wrote: On Thu, 2006-07-20 at 14:54 -0700, Roy T. Fielding wrote: On Jul 19, 2006, at 3:39 PM, Noel J. Bergman wrote: This piling on behavior seems to have come from the notion that if you get on the initial vote, you're in, but otherwise you have to earn committership. And the justification for the first part seemed to be making sure that a company could not start with a lot of its own people, and keep out existing ASF committers and other interested parties. I think people just got in the habit and assumed it was policy. Please remember Roy that your mails do not make policy either. Which is, of course, why I said I think. Policies (for whatever level they exist here) have been set up established practice- and as you know the mode of operation here so far has been add yourself to the wiki. So for all practical purposes, it *was* the policy here until your email. No. Policies are set by agreement of the incubator PMC. What people do in the *absence* of policy is not policy. I have no problem with changing it but don't try to make it look like there's piling on when established practice has is followed. I'm absolutely +1 for changing the process and having the proposer control who joins the project as you recommend. The change would be adding policy where none existed before. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [UPDATE] CeltiXfire Project Proposal
On Jul 21, 2006, at 11:25 AM, Davanum Srinivas wrote: Yep, both ws and jakarta have single ACL's. So any committer on any sub-project can *CHOOSE* to participate in any other sub-project. So can anyone who isn't a committer. You don't need commit access to participate. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)
On Jul 21, 2006, at 6:39 AM, Carl Trieloff wrote: If you search many of the Apache project names, they are trademarked to gezoo, No they aren't, at least not within the software category. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: piling on
On Jul 19, 2006, at 3:39 PM, Noel J. Bergman wrote: This piling on behavior seems to have come from the notion that if you get on the initial vote, you're in, but otherwise you have to earn committership. And the justification for the first part seemed to be making sure that a company could not start with a lot of its own people, and keep out existing ASF committers and other interested parties. I think people just got in the habit and assumed it was policy. There is nothing wrong with the proposer asking for and accepting additional committers from the wide world of ASF. I did that for Jackrabbit, for example, specifically because I wanted a lot of experienced ASF folks to help mentor the project (even though I was the only official Mentor). However, that is significantly different from any wiki reader being able to add themselves just because they (or their boss) thinks it might be worth getting in on the ground floor of a project. My long standing proposed solution for this is embedded in my description of project startup: - bootstrap the PPMC from the PMC (assigning Mentors) - election by the PPMC of project contributors to the PPMC - election by the PPMC of Committers So the Mentors first task is to formally bring on board the key outside players, and then that PPMC elects Committers, both to start and going foward. I think that is okay when you have three Mentors who are currently active on the proposal. I think it is a waste of time if they are not already active, since the proto-PPMC you mention hasn't even earned that right yet. Sure, they have the responsibility for it as delegated by the ASF, but when an existing code base is involved the only person(s) who really know the community are the ones writing the proposal. It saves a lot of time for the Incubator PMC to approve both the proposal and the initial set of committers in one act. I don't think either method is perfect, so I prefer the one with less of an entry barrier. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: piling on
On Jul 19, 2006, at 3:34 PM, Ian Holsman wrote: I was more thinking of how mentors volunteer to guide the project should the podlings have a say on who gets to mentor them? for example I could become a mentor of Blaize (I actually like the project) but shouldn't the proposer have a say ? I think so -- an unwelcome mentor is a waste of everyone's time. I also think mentors need commit access, since I don't believe it is possible to mentor a collaborative project without showing by example. It is kind of like getting advice at a barn-raising from some bystander who isn't willing to lend a hand. The advice will be heard for about five minutes, after which the people doing the work will simply ignore the bystander (even if the advice is good). Community is more than just being in the same place at the same time. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: piling on
On Jul 20, 2006, at 2:54 PM, Paul Fremantle wrote: On 7/19/06, Roy T. Fielding [EMAIL PROTECTED] wrote: I believe that it is a bad idea to allow people to add themselves to a proposal as committers without first obtaining the consent of the person(s) making the proposal. Being a committer in the incubator is giving a person the right to veto code changes based on whatever technical reason they deem significant. We should not hand out that right like candy to anyone who happens to edit a wiki page. I agree. But I also think that making it very easy for existing Apache Committers to join an project is valuable. It is very easy -- ask the proposer. 1) Some incubator proposals include only the existing core development team on a project. However, some other incubator proposals include many new proposed committers, some of whom have never submitted code to the project. I don't have anything against this, but I think it is an important point that the proposed committers are not necessarily existing coders on that project. Sure, and that is up to the proposer. If the proposal does not gain sufficient support from Apache because of that fact, that's life. Nevertheless, it is wrong for us to force a new podling to accept arbitrary committers just because they happen to have been proposed as an incubator podling. 2) Apache Committers, from whatever different project, have at some point proved their worth in some way. In general I would expect them to be a welcome addition to an incubator project. If nothing else they have some idea of the Apache model and approach. Sorry, not a chance in hell. Each project at Apache has its own sense of what makes for a good contributor. Some of them hand out commit access to anyone with a vague idea of contributing. Some of those committers have proven to have no clue whatsoever when it comes to handling Apache-style decision making. I personally believe that it is good for Apache to have multiple competing projects trying to address the same technology space, particularly when their strategies appeal to different sets of users. Among other things, it allows communities to fork *within* Apache when a fundamental design choice cannot reach consensus, or when the burdens of backwards compatibility impede significant progress. So I fully agree it shouldn't be a matter of piling on or just editing the wiki page. On the other hand, sending a note to the mailing list, *as well* as editing the wiki page is not a crime. The wiki page can always been edited back again (and in fact I've had that happen to me when I've offered to mentor). The first few time I volunteered on an Incubator project, no-one bothered to add me to the wiki, simply through inaction. So I favour the active approach. I do not. Each community needs to construct itself and nobody here, including me, has the right to declare themselves part of a new community without being invited first. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Blaze and Openness of Standards (was Re: [Proposal] Blaze)
OTOH, experience has shown that an effective open source project can cause a previously closed standard to be forced into the open or be supplanted. In any case, BLAZE is one of the more over-registered trademarks in the USPTO with 329 applications, most of them live and at least one registered for web software. It is not an acceptable name for a podling. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
piling on
I believe that it is a bad idea to allow people to add themselves to a proposal as committers without first obtaining the consent of the person(s) making the proposal. Being a committer in the incubator is giving a person the right to veto code changes based on whatever technical reason they deem significant. We should not hand out that right like candy to anyone who happens to edit a wiki page. Podlings must be open to new contributors and should add contributors to the list of committers fairly quickly, at least when compared to more established Apache projects. However, the core team must be allowed to select other core members based on mutual consensus, since consensus is how code changes are approved. How a community exercises that consensus is one of the primary determinants for graduation. In contrast, letting anyone pile on to a podling while it is at the proposal stage is placing an unequal burden on a new podling that we would never place on a full project. If the community is not cohesive, no consensus will be possible and we effectively hamstring the podling before it is even started. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] Roles and Responsibilities Update Needed [WAS Re: Mentors - the more, the merrier?]
On Jul 14, 2006, at 11:20 PM, Noel J. Bergman wrote: We just voted to elect a non-Member ASF Officer to the Incubator PMC in order for him to act as Mentor for the projects sponsored by the PMC of which he is the PMC Chair. Do we wish to declare that election and process null and void? Or do you concur that the Incubator PMC has the right to elect whom it feels appropriate to execute the role, based upon its collective human judgement? The Incubator PMC decided that only an ASF member can qualify as being a Mentor, period. And has, on more than one occasion, voted in violation of that decision. No, it hasn't. Some people may have voted for a project proposal without realizing that the Mentor is not an ASF member, and that may have allowed an invalid proposal to pass. It should not happen. So at least some months ago, we started talking (more than once on this list) about Mentors being just the active Incubator PMC members involved in the project. But that is neither here nor there at this point. What matters is the consensus going forward. We have talked about a lot of things -- the policy has not changed. That has nothing whatsoever to do with who is able to be on the PMC. [anyone involved in the process should be on the incubator PMC.] So we would have people who have a binding vote on all decisions made within the Incubator, including all projects under Incubation, and yet not qualified to be Mentors? How would you care to differentiate the two? Every incubator project must have at least one Mentor who is an ASF member. The reason is because only an ASF member has access to everything in the ASF, which is sometimes necessary for a podling to know what it should be doing in any given situation. Incubator PMC members are, by definition in the Bylaws (http://www.apache.org/foundation/bylaws.html#6.3), the people responsible for active management of the Incubator project(s). The role of Mentor is strictly a construction of the Incubator PMC, which I believe ought to be able to select Mentors as the PMC sees fit. Especially since any criteria are of its own making. Yes, and we made it: a Mentor must be an ASF member. There are many more PMC members than Mentors. The fact that we trust these people implicitly doesn't make up for the fact that they do not have access to the private information needed to mentor a podling. That private information includes, among other things, the sum of all mistakes made by previous Apache projects. Is the Board wrong to permit Officers who are not Members? Just how far do you want to take this? Are you really going to hold the Incubator PMC's (and the Board's) decisions hostage to the voting schedule of the Foundation? Yes. The only way that we have for the ASF as a whole to validate that someone has sufficient clue and commitment to guide future projects is to elect them as an ASF member. No one else has the right to say they are qualified. No one else but whom? And why exactly does the Incubator PMC not have that right, when the Mentor role (and the necessary criteria) is one of its own creation? The Incubator PMC has made its decision. I have no idea what you are talking about when you say that the documentation needs to be changed when the policy HAS NOT CHANGED. And although I've made the comment that I put considerable weight on whether or not I feel that a nominee for Membership would make a good Mentor, the Membership as a whole has never identified having sufficient clue and commitment to guide future projects as a key criteria for Member election. So whether or not the Membership *should* be that judge, it certainly has not been to date, in that it has not made that a key criteria. If we are to take your statement in that light, it would be an important point to make clear to all Members that they should only nominate and vote for those whom they feel have sufficient clue and commitment to guide future projects. No, but once they become Members they do have access to a clue, whereas it is guaranteed that non-members do not. Well, that ought to slow down growth of the Membership. And there are those who would not be Members had that been a primary (or mandatory) basis. Regardless, this does reinforce my belief that the Incubator may well be the best place for someone interested in becoming a Member to invest time, since it is one of the few places were their participation would be visible to a wide range of existing Members. Alternatively, we can encourage the lazy bastards in underrepresented projects to nominate people on time, as I did for the last election. There are some people who should have been made an ASF member long before they became officers, but that is in the past. And yet they hadn't. Why not? And why would you therefore want to say that the Incubator PMC should preclude itself from selecting such people, whom
Re: [doc] Roles and Responsibilities Update Needed [WAS Re: Mentors - the more, the merrier?]
On Jul 14, 2006, at 1:14 PM, Noel J. Bergman wrote: To quote myself, but this is hardly the first time it has come up: --- Mentors are (MUST BE) Incubator PMC Members. ASF Members are automatically eligible for PMC membership; non-Members may be elected at the discretion of the Incubator PMC. The Incubator PMC is understandably selective, but we have had non-Members as Mentors, more than once. --- Since when, Noel? Mentors must be ASF members. It is absolute nonsense to have someone guiding newbies through the ASF process when they haven't even made it to the halfway point themselves. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] Roles and Responsibilities Update Needed [WAS Re: Mentors - the more, the merrier?]
On Jul 14, 2006, at 1:57 PM, Noel J. Bergman wrote: Roy T. Fielding wrote: It is absolute nonsense to have someone guiding newbies through the ASF process when they haven't even made it to the halfway point themselves. Membership is a half-way point? What's the full distance? ;-) I'll let you know when I get there. But I agree with you: It is absolute nonsense to have someone guiding newbies through the ASF process when they haven't even made it to the halfway point themselves. And so we should not elect them to the Incubator PMC. No, anyone involved in the process should be on the incubator PMC. You don't have to be a mentor to be involved. We just voted to elect a non-Member ASF Officer to the Incubator PMC in order for him to act as Mentor for the projects sponsored by the PMC of which he is the PMC Chair. Do we wish to declare that election and process null and void? Or do you concur that the Incubator PMC has the right to elect whom it feels appropriate to execute the role, based upon its collective human judgement? The Incubator PMC decided that only an ASF member can qualify as being a Mentor, period. That has nothing whatsoever to do with who is able to be on the PMC. Is the Board wrong to permit Officers who are not Members? Just how far do you want to take this? Are you really going to hold the Incubator PMC's (and the Board's) decisions hostage to the voting schedule of the Foundation? Yes. The only way that we have for the ASF as a whole to validate that someone has sufficient clue and commitment to guide future projects is to elect them as an ASF member. No one else has the right to say they are qualified. There are some people who should have been made an ASF member long before they became officers, but that is in the past. Right now, the people who are officers and not yet ASF members simply do not know what they need to know to do their job well, and we struggle from that quite frequently. That doesn't mean people need to be an ASF member to be involved in incubation of a project -- they simply don't meet the required need for a Mentor who is an ASF member. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Acceptance Vote Duration? [WAS Re: [VOTE] Accept Heraldry into the Incubator]
On Jul 11, 2006, at 10:21 AM, Ted Leung wrote: In this case, we had several weeks of discussion on Heraldry, including some F2F conversations at ApacheCon EU, so 72 hours doesn't seem like a big deal to me. If people want to extend the voting period, I've no problem with that. I guess the bigger question is whether we ought to change the 72 hour guideline for the foundation as a whole, or make incuabator votes a clearly noted exception. No. No vote at Apache should require more than 72 hours. Everyone does not need to vote. We are a distributed organization that cannot afford to be hamstrung just because a few people may happen to be busy or on vacation at the time. The minimal quorum constraint was specifically designed to prevent volunteer variances from effecting our ability to make decisions. Roy (+0 for acceptance of Heraldry) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Heraldry Identity Project
On Jun 29, 2006, at 6:50 AM, Recordon, David wrote: For the last IETF meeting, Dick Hardt of Sxip had created a mailing list called DIX (http://dixs.org http://dixs.org/ ) and had a BOF under the same name. It was focused on the Sxip 2.0 protocol as a way to move authentication and profile assertions. Sxip 2.0 is also based upon OpenID 1.1 at a protocol level. During the BOF it was clear that there was not consensus that the technology Dick was proposing would meet the needs of everyone at the IETF, nor did everyone really understand the problem they were trying to solve. After the BOF, Sxip documented a set of use cases as well as began investigating the use of SAML assertions for exchanging profile data. Their goal was to create a light-weight version of a SAML profile, though took it to the extreme that the current DIX proposal is not SAML compliant. For this upcoming IETF meeting in July, two BOF requests we're received, one from DIX and one from Sam Hartman called WARP. They have both been merged into a new BOF called WAE (Web Authentication Enhancement) chaired by Pete Resnick. In talking with Lisa Dusseault, ASF member and IETF Applications Area Director, Lisa is not an ASF member. it sounds like the IETF would not be interested in standardizing a protocol above the HTTP layer. Rather, they are looking at a 2-3 year process to modify something like TLS to support authentication. Then once that is complete, it is possible using the same assertion format to provide a solution above the HTTP layer with the appropriate security considerations documented. While this path certainly isn't set in stone, it seems to be the direction the WAE BOF is going. I am sure that is what some people in the IETF think they are doing. The IETF itself does no such thing -- it is just a bunch of mailing lists with a social hierarchy nudging from the top. In general, the security work within the IETF has failed miserably in every respect, especially in regards to HTTP, and I would encourage you to focus on finding solutions to actual problems instead of mythical frameworks that apply to every problem but don't actually solve any of them. The OpenID community is not interested in circumventing the formal standards process, I can say with my VeriSign hat on that we're also interested in a lower level solution, but the community sees the need for something like OpenID today. That's because OpenID solves a problem. Technology should be implemented first and standardized later. Phill Hallam-Baker can tell you how many times people have tried to solve a simple security problem in the IETF and been stymied by the it doesn't solve everyone's problem sillyness. You can learn from the discussion, but don't pay any attention to claims that the IETF working group process is any more standardized than collaborative development at Apache. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Branding of Incubator projects
On Jun 26, 2006, at 11:57 AM, Justin Erenkrantz wrote: So, the guide that I'm tackling is the Podling Branding guide. It would be nice to tackle the still-nonexistant Apache branding guide as well. That way you could link to it from this doc. Here's what I'm proposing after some feedback from others here in Dublin: Podlings are, by definition, not yet fully accepted as part of the Apache Software Foundation. Therefore, they are subject to additional branding constraints. 1. The podling MUST be referred to as Apache Podling AND mention that the project is under Incubation. Suitable mentions are: - Inclusion of the http://incubator.apache.org/podling URL - The statement that Apache Podling is currently undergoing Incubation at the Apache Software Foundation. These statements only need to be disclosed upon the first reference in a document. +1. Note that we used to be The Jackrabbit project of Apache Incubator prior to graduation as Apache Jackrabbit, but that led to a lot of documentation needing to be changed at graduation. On other notes, please spell out PRC as public relations committee. PRC and PMC are so similar that my eyes confuse the two while reading a bunch of acronyms. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] CeltiXfire Project
On Jun 24, 2006, at 10:56 PM, Alan D. Cabrera wrote: robert burrell donkin wrote: committing is just a privilage with no legal status. commit status can be easily revocated by This is interesting the board, I can see this the members, How can this happen? The members can do anything in the ASF by vote. They represent the public interest in the foundation. infrastructure Maybe they pull the trigger at the behest of the board or PMC but can they also make this decision on their own? Yes, the infrastucture team is responsible for the machines. They can be overridden by the board or members later on. or by the appropriate pmc. I can also see this. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Synapse
The Synapse incubator would like to ask the Incubator PMC to release the Synapse project into the Apache Web Services PMC. Synapse heavily integrates with other WS projects including Axis2, Axiom, Sandesha, Rampart. The Synapse status page is here: http://incubator.apache.org/projects/synapse.html +1 Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Heraldry Identity Project
On Jun 20, 2006, at 5:54 AM, Recordon, David wrote: This has obviously been something we've been looking at in order to do our own due diligence on XRI IPR before being willing to contribute the Yadis spec to be incorporated into XRI Resolution 2.0. That's great, but I wasn't just concerned about the XRI IPR. I understand Yadis and OpenID technology to the extent that it uses the existing URI infrastructure. I see no reason for either technology to use XRIs. However, just to be clear, I don't make technical decisions for other projects (just my own) -- my only concerns right now are that the stated scope of the proposed project is accurate and that Apache will have the legal right to redistribute whatever is contributed. Have all the individuals and companies with products that are included in this proposal looked at the CCLA text and agreed to participate on that basis? The reason I ask is because some have not agreed to do so in the past and we have had some optimistic proposers that wait until after the proposal is approved before actually getting buy-in from the supposed contributors. This is fairly important in this case because the URI-based identity proposals do fit well with Apache development philosophy, whereas XRI and OASIS does not IMO. If everyone is on board and understands the software grant/CLA conditions, then this seems to me to be a worthwhile project for the incubator. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MODERATE for lucene-net-user@incubator.apache.org
All of the cut and pastes you sent, and the addresses included in the messages, have whitespace near the end. e.g., apach e.org instead of apache.org You need to send to the entire address without any whitespace. If that is not the problem, then try adding a subject to the message. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
