Rahul Akolkar wrote: > On 6/20/06, Phil Steitz <[EMAIL PROTECTED]> wrote: >> Rahul Akolkar wrote: >> > On 6/16/06, Felipe Leme <[EMAIL PROTECTED]> wrote: >> > <snip/> >> >> >> >> I think these statements are a good start for the next meeting's >> >> proposal - could someone write an wiki entry for it (or even update >> >> the current resolution)? I'm traveling until Sunday and my internet >> >> connection is pretty bad here, so it would be hard for me to do it... >> >> >> > <snap/> >> > >> > Thanks for putting it all together as a summary, I've put the closing >> > statements from that email, verbatim, on a wiki page [1]. Its open to >> > edits (I might make some minor edits myself in a day or two). >> This is good. Here are a few additional things that we might want to >> think about adding, assuming all are OK with these commitments. > <snip/> > > This (below) is generally in line with my expectations of how things > should work, and aligned to what we've said previously in these > threads, IMO. > > Ideally, there'd be a mechanism to get some feedback, even in your > absence (thanks for volunteering though). > > -Rahul > > >> This >> list is designed to address some of the concerns that have been raised >> in the past about umbrella projects. Obviously, not all may agree with >> the points below, and even with these provisions, the board may not >> approve the Testing proposal. I just thought it would be a good idea to >> get these ideas out for discussion for this and the other >> "umbrella-like" things that we may be splitting Jakarta into. >> >> 1. The PMC members named in the proposal are signing up to provide >> oversight for the *entire project*, not just "subprojects" that they >> participate in. In fact, there are formally no subprojects, just >> products or code bases that are versioned / released separately. I >> would recommend that we avoid the use of the term "project" other than >> for the TLP itself and avoid "subproject" altogether. >> 2. As new components are incorporated, the PMC will grow and will >> always include the (the majority of) active committers working on each >> of the components. Ability to make decisions on behalf of the whole >> project will be considered when granting commit access. >> 3. A necessary condition for adoption of a codebase or creation of a >> new component will be commitment from a minimum of 3 PMC members >> (possibly existing ASF committers, joining with the codebase) agreeing >> to review / apply patches, review commits, serve as RM, etc. for the new >> component. >> 4. If one or more of the components, or the entire project, grows in >> complexity or community size <this number intentionally left blank> to >> the point where effective oversight / active involvement by the Testing >> PMC on all components is no longer possible, the project will be split >> (just as Jakarta is being split now, per this proposal). Note that this >> is a statement of intent, not an administrative mandate (i.e., the >> somewhat painful, consensus-driven process that we are following now in >> Jakarta is our *intention* to improve and maintain). >> 5. Inactive components, or components without a sufficient number of >> active PMC members, will be regularly archived. >> >> One more personal thing: >> >> I just learned that the board meeting has been postponed until next >> Tuesday. Unfortunately, I will not able to attend that day. Therefore, >> it would be great if one of the other members supporting this proposal >> could step up to attend. >> >> Phil With his permission, I am forwarding an excerpt from a recent post from Roy Fielding, in response to questions about a proposed "Security" TLP originating out of the XML project. The concerns he raises below all pretty much apply directly to Testing. Could be the right approach here is to limit it to Cactus + Jmeter, or even have them each TLP separtately. I think the key is really point 1. above as well as Roy's argument below about not claiming dominion over a topical area.
Roy Fielding on 6/22: "When a project "owns" a category, such as security, the participants think that they are responsible for all Apache products in that space. Meanwhile, what they are actually working on is a fairly small project that addresses the specific requirements of a given set of users, such as xml-security. People don't try to make products that are applicable to every possible consumer in a given category, and volunteers cannot oversee projects in which they do not actually participate. What is left is either a single project that rejects all new target audiences or an umbrella project that creates an artificial barrier to oversight. There is no way to broaden the perspective of a project -- people simply don't wake up one day and discover a need to be aware of everyone else's work in similar projects, and most people don't have the bandwidth to do so anyway. That is why each project has to be self-governed. When someone else comes along and says an obvious thing like "XML is inherently non-secure, I want to work on a security project that demonstrates a better way of securing blah", the developers in this so-called "security" project are likely to be offended and make it socially impossible for that person to participate. Even if that is not the case, the perception that it might be the case will cause potential contributors to go elsewhere rather than express their ideas for a new project. The bureaucratic mentality of committees needs to be actively offset by the board and the only real mechanism the board has to do that is to make sure the committees don't own categories. Instead, a PMC owns a particular product-line and decides for that product-line the design trade-offs to fit its target audience. If someone else comes along with a different audience in mind (but the same category), they don't have to be compelled to merge with the existing project and we don't have to abuse users with major incompatible changes -- we just set up a new product line with its own set of developers. If the two projects decide to merge later on, everyone wins. If not, nobody loses. Any given problem at Apache can be solved at least a dozen different ways, satisfying different sets of consumers, and reaching independent levels of perfections in the minds of their own designers. We should not fear internal competition. A federation is simply an umbrella project with no significant responsibilities of its own -- all of its projects report directly to the board and simply view the federation as a communal thing. I think XML and Jakarta should already fall into that category. Starting one is just like starting a project, except that the purpose is limited to community/commons like things and not actual products. " > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
