At 07:27 PM 2/8/2007, Curt Arnold wrote:
The current Logging Services bylaws effectively make the project an
umbrella covering several self-governing subprojects (log4j,
log4cxx, ...). The current bylaws mandate a two-stage vote for many
actions, an advisory vote at the subproject level followed by a
binding vote at the PMC level. For the log4j subproject, the two
stage vote is a time-consuming annoyance as the PMC and log4j
committers are very close to being the same set of people. For
log4cxx and log4net, reaching a quorum for the advisory vote can be
at least an obstacle.
If I understand correctly, the idea is to circumvent the quorum
requirement, i.e. collecting three +1 votes, so that the Logging TLP
can vote instead of the people who are actually familiar with the
work?
For chainsaw, it has resulted in a weird
hybrid where chainsaw has its own project in the SVN and releases,
but is part of the log4j project for quorum issues (and potentially
other issues).
That was by volition of Scott and Paul. At the time, I invited
them to form a separate project and they declined. You should perhaps
ask Scott and Paul whether they would like to become a separate
sub-project.
In addition, there are some definitions in the bylaws
(IIRC some of the voting definitions) that conflict with other
definitions in more authoritative Apache documents.
There ASF is based on delegation. Therefore, as long as the LS bylaws
are in agreement with rules of the ASF, they are authoritative as far
as the LS TLP is concerned.
There have been previous discussions on bylaw changes to address
these issues, for example on [email protected] on 2005-07-01
(http://marc.theaimsgroup.com/?l=apache-logging-
general&m=112024592311861&w=2) which referenced earlier discussion on
the private pmc list, but there was no action taken.
The Board Resolution forming the LS PMC mandated the initial PMC
create a set of bylaws for the project (http://logging.apache.org/
site/mission-statement.html). The term "guidelines" appears to be
currently preferred for project level statements to avoid the legal
implications of bylaws. For example, the ASF Bylaws (http://
www.apache.org/foundation/bylaws.html) are a legal document that
governs the corporation and has to conform to corporate governance
laws in the State of Delaware.
The LS bylaws (see http://logging.apache.org/site/bylaws.html )
mentions the word "guideline" once.
Section 6.3 of the ASF Bylaws (http://www.apache.org/foundation/
bylaws.html) places responsibility to establish rules and procedures
on the PMC chair.
The foundation bylaws mandates the project chairman to establish
project bylaws. However, once the bylaws are established, they should
not and cannot be changed at the whim of one person. We already have
bylaws. They can be changed as long as there is a 2/3 majority of the
active PMC members. The 2/3 rule is there precisely to prevent the
chairman from making arbitrary changes.
Are you suggesting that the chairman has the power to change the LS
project bylawys without approval of the PMC?
There was an discussion on [email protected] on 2005-09-12
that discussed the confusing state of ASF project bylaws (http://
thread.gmane.org/gmane.comp.apache.incubator.general/6144/focus=6147).
I thought that I recently saw a thread on
[email protected] that argued against projects having
bylaws (or guidelines) of their own as the ASF bylaws and other
documents were sufficient, but unfortunately I have not been able to
find that thread.
As an open group, people are welcome to argue for or against any
topic. The existence of a con argument does not mean it should be
adopted here.
I would like to take steps that result in:
The LS project to be a single project with any number of products.
The PMC being the only decision making body.
Either no project guideline document or one that heavily defers to,
not duplicate or conflict with, http://www.apache.org documents.
A set of evolving process documents that describe best practices on
the project.
I would appreciate comments and will try to work on a draft. A board
report is due for the Feb 21st meeting. It would be great to get
this and several other issues resolved in the next week or so in
order to clear out some long pending issues.
The idea behind the current structure is to delegate responsibility to
the people actually doing the work. I still think that delegation is
one of the core tenets of the ASF. Thus, after a given LS sub-project
votes, and then makes a recommendation to the PMC, the PMC is very
likely to endorse the recommendation. As far as I know, the LS PMC has
always endorsed recommendations made by sub-projects.
Instead of undoing the existing bylaws, I would suggest to expedite
the PMC voting process. Moreover, nothing prevents a sub-project from
granting committer access to an existing PMC member (hence mitigating
the difficulty of reaching quorum.)
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
