On 31/05/2011 19:24, ant elder wrote:
The board resolution that created Labs said:
"...establish a Project Management Committee charged with the creation
and maintenance of innovation labs where committers of the foundation
can experiment with new ideas without the burden of community
building..."
and also:
"...RESOLVED, that Apache Labs is responsible for promoting innovation
without discrimination of purpose, medium or implementation
technology..."
The full minutes are here:
http://www.apache.org/foundation/records/minutes/2006/board_minutes_2006_11_15.txt
So nothing at all in there really limiting what the project can do WRT
whats being discussed on this thread.
Further on in the minutes in Attachment W are the Labs project Bylaws,
usually projects are free to change bylaws as they see fit as long as
it stays within the project scope, this resolution does mention the
bylaws and says the project "...will continue to maintain and adapt
such bylaws to maximize its goals and minimize eventual negative
impact on the rest of the foundation."
So it sounds like there is a lot of scope for making whatever changes
to the Labs bylaws might be felt necessary to help revive the project.
Yes, but also remember that some aspects of managing ASF projects are
set in stone. One of these is the need to provide due diligence on any
releases in order to protect the foundation and its users from any legal
"uncertainty" (see "maximize its goals and minimize eventual negative
impact on the rest of the foundation" in the resolution as quoted above).
It's certainly true that this, and any other PMC, can change the
majority of its byelaws. But to change the no-release byelaw requires
the original reasoning behind that decision to be addressed.
Thanks for the link above I draw peoples attention to Attachment W,
"Guidelines Rationale", specifically:
"The reason why Labs are prohibited from making releases is to simplify
operation and avoid the legal oversight associated with the release
process and to avoid labs from becoming ways to 'route around' the
incubator."
This is slightly different to the "scaling" point I made earlier in this
thread and is, in fact, even more important.
(there are other important reasons for the rules in there, people
interested in change really ought to read this in detail)
As a slight aside i notice that there are a lot of those PMC members
still on the PMC almost five years later but who don't seem active, i
don't recall seeing much email from them anyway. I wonder if some
updating of PMC members could help, just as with any other Apache
project, adding new PMC members can help keep things alive and bring
new ideas.
+1
I'm surprised to find I never volunteered for the PMC. I do remember
now, I decided I didn't have the time, yet I'm still here causing
trouble, even if not a PMC member ;-)
I'd use this as an opportunity to invite ideas. We've heard a few people
say "make releases", but we've not heard anyone say how we can make that
possible.
Personally I think there is nothing wrong with labs as is. It is
supposed to be a play area with no overhead. There is code in here that
I occasionally pick up and use, but I'm not about to take ownership of
that code. Having it here in the ASF where my commit rights on other
projects allow me to play with it is, in my opinion, just what is
needed. the fact that very few projects ever come out of labs is not a
concern, in fact it was expected and codified in the original resolution:
"WHEREAS, the Board of Directors understands that research
efforts are intrinsically associated with a higher mortality
rate that don't match the already established
incubation and development practices."
If there are labs that want to make releases then I believe the labs PMC
has two choices:
a) it addresses the scaling and "incubator bypass" issues (I have no
suggestions about how to do this)
or
b) it encourages such labs to move out to apache-extras where releases
can be made and accepts that the goal of labs is to *just* provide a
place where code is allowed to be dropped so that other committers may
pick it up
Ross
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
