The Apache Software Foundation Board of Directors Meeting Minutes December 18, 2002 1. Call to order The meeting was scheduled for 10am PST -0800. It began at 10:06 when a sufficient attendance to constitute a quorum was recognized by the chairman. The meeting was held by teleconference hosted by Jim Jagielski (Covalent): IRC #apacheboard on irc.openprojects.net was used for backup purposes. 2. Roll Call Directors Present: Ken Coar Roy T. Fielding Jim Jagielski Sam Ruby Greg Stein Directors Absent: Brian Behlendorf Ben Laurie Bill Stoddard Dirk-Willem van Gulik Guests: Chuck Murcko 3. Minutes and supplements from previous meetings A. The meeting of October 9, 2002 By general consent, minutes 'board_minutes_2002_10_09.txt' were approved. B. The meeting of October 16, 2002 By general consent, minutes 'board_minutes_2002_10_16.txt' were approved. C. The meeting of October 30, 2002 By general consent, minutes 'board_minutes_2002_10_30.txt' were approved. D. The meeting of November 18, 2002 By general consent, minutes 'board_minutes_2002_11_18.txt' were approved. 4. Officer Reports A. Chairman [Greg] Greg reported that current ASF status was OK. He was pleased with the start of Ant and the "restart" of Avalon. He expressed some concern over the status of the Incubator project. Jim noted that he had sent out an email to Incubator that the general consensus of the PMC was that they were at a stage where they could start accepting new products, with Tapestry likely being the first one. B. President [Dirk] No report since Dirk was not present. C. Treasurer [Chuck] Chuck reported on invoice from Duane Morris for legal services rendered. Chuck had requested and received a detailed invoice listing of charges, and they all appeared valid. Chuck reported that he had sent payment to Duane Morris and CSC for services rendered. Chuck also reported that he had scheduled a meeting with Wells Fargo regarding the ASF obtaining a merchant account (for accepting credit card donations) but also noted that this would involve some infrastructure on our part to implement and use. PayPal was discussed as another more viable alternative. The Jinx contract was also mentioned as a source of revenue available to the ASF. D. Exec. V.P. and Secretary [Jim] Jim reported that various invoices (sent to the ASF offices) had been sent to Chuck who reported receiving them. Jim also noted that CSC was informed of the board changes to the ASF but that, as of this date, the changes had not been implemented yet. There was some discussion on the 'apache.org' domain name and how the DNS records should be changed to reflect current reality. 5. Committee Reports A. APR Project [Cliff Woolley] See Attachment A B. Commons Project [Ken Coar] Ken reported that there was nothing to report. C. Jakarta Project [Sam Ruby] See Attachment C D. PHP [Rasmus Lerdorf] A report was not received by the time of the meeting. E. Avalon Project [Nicola Ken Barozzi] See Attachment E F. Incubator [Jim] See Attachment F G. Security Team [Ben Laurie] A report was not received by the time of the meeting. H. Ant Project [Conor MacNeill] See Attachment H 6. Other Reports A. Sam Ruby -- discussions with the PHP Group Sam reported that he would send an email this week to address the issue of the PHP becoming a more "formal" ASF project. This included the assignment of copyright to the ASF as well as the use of the Apache License. It was noted that many PHP members have no issue with v2.0 of the AL. B. Status update on Peter Donald's suspension. It was reported by the Jakarta Chair that discussions with Peter Donald had somewhat broken down. At core is the question on whether Peter accepts all members of the PMC as peers. The suspension is thus still active. 7. Special Orders None. 8. Unfinished Business A. STV instead of FPP for members meeting votes Tabled until further action by Ben Laurie. 9. New Business Empower PMC chairs to change the membership of their PMCs without requiring ratification by the board. This changes a previous resolution which specifically defined which PMCs had this power and authority. The new resolution is crafted to allow any and all ASF PMCs. The following resolution [R1] is proposed: WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to delegate the ability to appoint the membership of Project Management Committees to the officers of the corporation given charge of them, NOW, THEREFORE, BE IT RESOLVED, that the Vice President positions charged with the management of each of the Project Management Committees of the Apache Software Foundation are hereby assigned the further authority to and responsibility of appointing the membership of their respective Project Management Committees, which will be effective 72 hours after a Director of the Board acknowledges receipt of a notification from the Vice President to the Board specifying the change in membership of the committee. By unanimous vote, Resolution R1 was passed. Sam noted that a potential new project, focusing on "Web Services" might be proposed in the near future. Roy expressed some concern over use of the marketing phrase "Web Services" as a project name, since most ASF projects, including HTTPD, would be in that scope. 10. Announcements 11. Adjournment Adjourned at 11:01 PST -0800. ============ ATTACHMENTS: ============ ----------------------------------------- Attachment A: Status report for the APR Project The APR Project continues to press toward a 1.0 release. Our most recent "official alpha" (0.9.1) was released at roughly the time of our last report; since then, we have introduced versioning and backward- compatibility guidelines and have been stabilizing our API. Also at the time of our last report, we were in the process of redefining our mission statement (which is still being fine-tuned) and of electing a new PMC Chair (this is my first report in that role). As a side note, we wish to congratulate our outgoing Chair on the Thanksgiving-day birth of his daughter, Abby. The entire family is doing well. We are in the process of building a comprehensive test suite to ensure cross-platform consistency, and this combined with user reports have helped us to shake out a number of pre-1.0 bugs. Given the increasing number of user bug reports and API inquiries, the project seems to be gaining wider interest throughout the development community; http://apr.apache.org/projects.html now lists a several significant applications besides just HTTPD and Subversion that are using APR, and there are several other projects that have expressed an interest in doing so. ----------------------------------------- Attachment B: Status report for the Commons Project Placeholder -- there is no Attachment B. ----------------------------------------- Attachment C: Status report for the Jakarta Project The status report for Jakarta project is available at http://jakarta.apache.org/site/news.html and http://jakarta.apache.org/site/news/index.html. These summaries are community developed, monitored, and maintained. Feedback on their contents should be directed to mailto:general@jakarta.apache.org. I tried unsuccessfully to summarize the summaries without looking like I was trying to prove a point about it not being a good idea. Of course, this begs the question about what happens when Jakarta is split up and all this data feeds directly into the board, but I digress. Overall, the imperialistic expansion phase of Jakarta has been put on pause. No new code bases have been accepted. Two colonies, Ant and Avalon, have split off successfully. The only issue in this area is Tapestry which unfortunately has been left in limbo in the process, neither accepted by Jakarta nor by the Incubator. The biggest unresolved issues in Jakarta deal with codebases on either end of the maturity spectrum. There are code bases which seem to be perennially in alpha, and therefore feel the right to change interfaces on a whim and without regard to the community impact of such changes. Unfortunately, the existence of a sandbox seems to have institutionalized this policy. Unquestionably, code bases in alpha should be allowed to experiment, but the establishment of a playground where this takes place indefinitely is not in the best interest of the ASF. On the other end of the spectrum are codebases which have matured to the point where there aren't enough itches to scratch to maintain a development community. Such codebases (for example, regexp) are heavily depended upon and so interwoven into the fabric of many Jakarta subprojects that it is hard to imagine removing them from the ASF despite the somewhat different community dynamic one sees there. There isn't even a quorum to hold a proper release vote or people actively monitoring the bug reports and commits. This is a problem. ----------------------------------------- Attachment D: Placeholder -- there is no Attachment D. ----------------------------------------- Attachment E: Status report for the Avalon Project Our project STATUS file ------------------------- http://cvs.apache.org/viewcvs.cgi/jakarta-avalon/STATUS.txt?rev=HEAD&content-type=text/vnd.viewcvs-markup Additional info for the board ------------------------- * What code releases have been made? None yet. It's possible that we shortly will release Fortress to support our ECM users till the discussion and coding of the new Avalon is completed. Phoenix will still be actively maintained and developed within the scopes of the Avalon Project in the same way. * Any legal issues to bring to the board? Microsoft has called an API "Avalon", as our project. As with other Apache projects, the "fix" would be to reference Avalon always as "Apache Avalon". Also, we still have some files that contain the short Apache license. It has been said that we should use the full license till version 2.0 comes up, but there has been some resistance by some committers in the past. I want to address this now and have all files use the long version. *Any cross-project issues that need to be addressed? Avalon is a framework based on components, and thus we have many other projects that have Avalon components. We polled the Jakarta Turbine project to know if they were interested in a common space where to have a Avalon component repository, and the response was positive. Also in Avalon it was positive, and other projects like Jakarta James and OJB (a developer contacted me directly) seem interested. What we need to define is where to have this repository. Originally we were thinking of having it in Apache Commons, but we are trying to decide if it's better to have it under the Avalon project, with its own set of committers. There is also a project called EOB (enterprise object broker) based on Avalon and coded by Avalon committers on sourceforge that could move to Apache. We are thinking if it would make sense to have it under the Avalon project or not. Similarly for Jesktop and Monarch, GUI frameworks based on Avalon. There can be concerns that this could split the community again, but in fact these are efforts build using Avalon and not to be Avalon implementations. *Any problems with committers, members, etc? None, fortunately. The recent things that have happened have created unrest in the beginning, but now also the ones that originally were resisting change are not part of it, in an active way. This is about all committers/members except Peter Donald, who is in a particular situation having the privileges suspended. * Plans and expectations for the next period? We are seriously discussing and making concrete progress on the definition of a new codebase. We have decided that we should maintain legacy codebases, so in the next months we will continue maintenance and discussions. Once the new system is done, we will deprecate all other systems and focus solely on that. We still need to decide what to do with our components, as the above discussion deals with the container. * etc (your own thoughts on what is important would be helpful!) The suspension of Peter Donald's rights has evidently disrupted the community. This is not a negative comment, just a constatation. The combined efforts of Sam Ruby, Stefano Mazzocchi, Greg Stein and I, especially in the initial period, have helped in making other committers more confident in the future of Avalon and in stabilizing the situation. The main fear was that the Phoenix codebase would have been declared dead without proper deprecation and all Avalon based on an Alpha system. I had to reassure more than once to explain it was not the case. I don't know where this fear came from. IMHO this disruption has made committers aware of what was actually happening and about the negative mechanisms that had become the norm in the community. Now the situation is much better and the community is restarting with renewed force, slowly but steadily understanding the value of peer review on all the codebase and respect. Of great help has been the intervention of two Jakarta James committers. James uses Avalon, and they are interested in making the outcome be positive. Other knowledgeable Avalon developers have also chimed in, and this has finally made us get a feel of the situation. Seeing this, we are now deciding to make non-Avalon committers that are part of active Avalon-using projects be voted in the Avalon PMC by existing members. Peter Donald has mixed positive attitude with the same disruptive patterns seen before. Things seem to be moving, but slowly and not always in the same direction. Overall, here are some of the measures taken that had a positive effect. They are to be remembered for how to deal with similar cases in the future. o The unification of the development mailing list has stopped immediately the divide in development effort responsibility. o The creation of the avalon-sandbox CVS module has stopped the problem of making sandbox code appear and act as de-facto released. The future use of the sandbox will have to be voted for internal forks too, so that they are done only in a spirit of cooperation. o The creation and maintenance of the STATUS file in CVS has made developers aware of the common goals and situation, and finally gives a reference for the issues being discussed. It helps in bringing us together. ----------------------------------------- Attachment F: Status report for the Incubator Project There has been no real additional news to report regarding the Incubator PMC since the last report on Nov 20th. One item, however, is significant. It was reported that the Incubator was spending time in detailing aspects of the ASF and "The Apache Way" to ensure that everyone was on the same page as it were (and that everyone understood the concepts in the same way). It is currently felt that this effort is complete enough for the Incubator to actually start accepting new products/projects. It's expected that the few product(s)/project(s) will be formally accepted and started (most likely) early Jan. 2003. ----------------------------------------- Attachment G: Placeholder -- there is no Attachment G. ----------------------------------------- Attachment H: Status report for the Ant Project Status Report for the Ant project o Ant 1.5.1 Ant 1.5.1 was released on October 3, 2002 o Ant 1.5.2 A number of bugs have been fixed against the current 1.5 code base, including upgrading to Xerces-J 2.2.1. We expect to release Ant 1.5.2. sometime in early 2003 (Jan/Feb) but no release plan has been agreed at this time. I expect this to be the final release from the 1.5 branch. o Ant 1.6 1.6 is the current development codebase (CVS head). No release plan has been considered for this release. I would expect a release around June 2003. Features which are candidates for this release: * Some form of task library support, allowing third-party tasks to be more easily packaged, distributed and integrated with Ant. * Support for polymorphic types * Delayed Task construction, Top levels tasks, etc o ant.apache.org site The virtual host and initial content have been established. This site is live but not actively advertised at this time. We will be fleshing out the site with more content (bylaws, roles, etc). At that time we will redirect jakarta.apache.org/ant to the new site. Stefan Bodewig worked with Justin Erenkrantz to have Ant's distributions supported by the Apache mirrors. From this work, Stefan has put together a how-to for other projects to use to get their distributions mirrored. o Bylaws An early draft of the Ant bylaws has been put together based on content from the httpd and Jakarta projects. Feedback has suggested changing "consensus" to "lazy consensus" to make PMC decision making more workable. In working on this, it seems to me that as more top level projects come on-line the duplication in bylaws might not be useful. Perhaps we could define some standard set of Apache project bylaws, potentially versioned and maintained in the incubator project. Each project could refer to these bylaws and append additional and/or overriding bylaws. Bylaws should be completed by end Jan 2003. o Legal Issues Software grants are in place or in progress for all code which has been donated to Ant over its lifetime. One code component, the tar classes, is based on public-domain code and is not covered by a grant. o Outstanding bugs and patches There is currently a large number of bug reports and code enhancements posted to BugZilla which have not been processed. I will be looking to greatly reduce these in the new year. o Community The Ant community seems pretty relaxed at the moment. There are no major disputes or issues. Discussion on the dev list centers around the issues for Ant 1.6, such as polymorphism, top level tasks, etc. The user list remains quite active. __________________________________________________________ End of minutes for the 18 Dec 2002 board meeting.