Index
Links: 2002 - All years
- Original
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.
Index