Re: Action regarding umbrella PMCs
From: "Roy T. Fielding" [EMAIL PROTECTED] That is, the PMC is supposed to be elected by the committers on the project, or include all of the committers on the project, because that's pretty much the only way to ensure that what we do remains a true collaboration and doesn't degrade into some sort of consortium or a mirror of our real jobs. This statement would seem to be in conflict with the PMC bylaws. "New members may be elected to the PMC. In order to be elected, a person must have served as a Committer and be nominated by a PMC Member. Once nominated, all of the PMC will vote and those receiving a 3/4 positive vote will become a member." Is the ASF board overriding the PMC bylaws just in this instance or does this principle hold for all PMC appointments? If it is the latter, then do the bylaws need to be amended to that effect? Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action regarding umbrella PMCs
Conor MacNeill wrote: This statement would seem to be in conflict with the PMC bylaws. The PMC bylaws are broken in a number of areas. Is the ASF board overriding the PMC bylaws just in this instance or does this principle hold for all PMC appointments? If it is the latter, then do the bylaws need to be amended to that effect? Roy is not overriding the PMC bylaws, he is simply describing the original intent of the board. That being said, I agree with Roy. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action regarding umbrella PMCs [long]
Conor MacNeill wrote: Is the ASF board overriding the PMC bylaws just in this instance or does this principle hold for all PMC appointments? If it is the latter, then do the bylaws need to be amended to that effect? Sam Ruby wrote: The PMC bylaws are broken in a number of areas. ... / Roy is not overriding the PMC bylaws, he is simply describing the original intent of the board. -- For reference: ASF BYLAWS RE: PMC's http://apache.org/foundation/bylaws.html snip Section 6.3. Project Management Committees. In addition to the officers of the corporation, the Board of Directors may, by resolution, establish one or more Project Management Committees consisting of at least one officer of the corporation, who shall be designated chairman of such committee, and may include one or more other members of the corporation. Unless elected or appointed as an officer in accordance with Sections 6.1 and 6.4 of these Bylaws, a member of a Project Management Committee shall not be deemed an officer of the corporation. Each Project Management Committee shall be responsible for the active management of one or more projects identified by resolution of the Board of Directors which may include, without limitation, the creation or maintenance of "open-source" software for distribution to the public at no charge. Subject to the direction of the Board of Directors, the chairman of each Project Management Committee shall be primarily responsible for project(s) managed by such committee, and he or she shall establish rules and procedures for the day to day management of project(s) for which the committee is responsible. The Board of Directors of the corporation may, by resolution, terminate a Project Management Committee at any time. Section 6.4. Election and Term. The officers of the corporation and the members of each existing Project Management Committee shall be appointed by the Board of Directors or appointed by an officer empowered by the Board to make such appointment. Such appointment by the Board of Directors may be made at any regular or special meeting of the Board. Each officer shall hold office and each member of a Project Management Committee shall serve on such committee for a period of one year or until his or her successor is elected and qualified or until his or her earlier resignation or removal. Section 6.5. Removal of Officers. Any officer or agent and any member of a Project Management Committee elected or appointed by the Board of Directors may be removed by the Board whenever, in its judgment, the best interests of the corporation will be served thereby. Section 6.6. Vacancies. Any vacancy, however occurring, in any office or any Project Management Committee may be filled by the Board of Directors. /snip ASF BOARD MINUTES RE: JAKARTA PROJECT http://apache.org/foundation/records/minutes/1999/board_minutes_1999_09_16.txt snip D) Jakarta Project Discussion was held on a proposal to create a project for development and maintenance of open-source Java Servlet-related software. Roy submitted a resolution based on Brian's request to establish the PMC, consisting of those people closely involved in the existing jServ project and related projects at Sun and IBM. Ben Hyde had some concerns about the last paragraph in the resolution, where it tasked the PMC with the creation of a set of bylaws. Brian clarified that the project bylaws specify how new developers are brought aboard, old ones retire, and the PMC chair elected by the project participants. Roy observed that the Server project has them, called project guidelines, and that the intent of the resolution is to encourage the PMC to set their own guidelines with the appropriate frame of mind. The following resolution was unanimously adopted by vote of the directors present (Brian, Ken, Roy, BenH, Sameer, Dirk): WHEREAS, the Board of Directors deems it to be in the best interests of the Corporation and consistent with the Corporation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source Java Servlet-related software for distribution at no charge to the public. NOW, THEREFORE, BE IT FURTHER RESOLVED, that a Project Management Committee, to be known as the "Jakarta Project Management Committee", be and hereby is established pursuant to Bylaws of the Corporation; and be it further RESOLVED, that the Jakarta Project Management Committee be and hereby is responsible for the creation and maintenance of Java Servlet-related software based on software licensed to the Corporation; and be it further RESOLVED, that the office of "Vice President, Jakarta" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chairman of the Jakarta Project Management Committee, and to have primary responsibility for management of the projects within the scope of responsibility of the Jakarta Project Management Committee; and be
Re: Action regarding umbrella PMCs
From: "Sam Ruby" [EMAIL PROTECTED] Roy is not overriding the PMC bylaws, he is simply describing the original intent of the board. That being said, I agree with Roy. Oh, I agree too. I am just wondering how all this fits together. For example the recent vote by PMC members on PMC nominees. Is that superceded by this statement? What is the plan from here? Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Action regarding umbrella PMCs [long]
Henri Gomez wrote: Pierpaolo Fumagalli is IBMer ? At the time he did accept paychecks from IBM. Now he accepts paychecks from Sun. In between he accepted paychecks from a company named Exoffice which changed its name to Intalio. Who you accept paychecks from and who you are can be quite different things. Pier is a perfect example. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action regarding umbrella PMCs
Conor MacNeill wrote: Oh, I agree too. I am just wondering how all this fits together. For example the recent vote by PMC members on PMC nominees. Is that superceded by this statement? What is the plan from here? My bias is towards evolution, so we'll try that first. If not, there always is plan B. The first order of business is to get adequate representation of the code bases in order to address the board's concern. Depending on the outcome of the election, this may take iterations. The next order of business is a radical overhall of the bylaws. Ted has been sheparding an effort to do that already. I'd like to consider some more radical changes than the one considered so far, starting with the election process. Other, equally important tasks are underway to make the various subprojects are interwoven into the quilt that is Jakarta. Gump takes a fairly coarse view, and needs to expand into testing. The emerging library/commons subproject attacks this problem from another direction, and focus on reuse. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
monthly pmc meeting?
when is it again? -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_java status
It is possible to write Apache modules with mod_jk (the original goal of mod_java) ? Besides the main use of mod_jk is interacting with Tomcat, the Ajpv13 protocol could be used to communicate with other programs, right ? If so, some description/documentation of the protocol would be fine. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 05, 2001 6:14 PM Subject: Re: Mod_java status On Mon, 5 Mar 2001, Robson Ribas wrote: What happened to mod_java ? There is no link to it on java.apache.org neither on jakarta.apache.org. Was this project closed or discontinued or something ? Most of it is implemented in mod_jk, part of tomcat 3.2 and 3.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action regarding umbrella PMCs [long]
GOMEZ Henri [EMAIL PROTECTED] wrote: Elias Bayeh, IBM[EMAIL PROTECTED] Hans Bergstein [EMAIL PROTECTED] James Davidson, Sun [EMAIL PROTECTED] Pierpaolo Fumagalli, IBM[EMAIL PROTECTED] Craig McClanahan, MyTownNet [EMAIL PROTECTED] Stefano Mazzocchi, Independent [EMAIL PROTECTED] Jon Stevens, Clear Ink [EMAIL PROTECTED] James Todd, Sun [EMAIL PROTECTED] Pierpaolo Fumagalli is IBMer ? Used to be one... Then I moved to a startup called Intalio and finally (thank god) I landed at Sun... And I'm not going to move from here for quite a long time... Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Action regarding umbrella PMCs [long]
Sam Ruby [EMAIL PROTECTED] wrote: Who you accept paychecks from and who you are can be quite different things. Pier is a perfect example. Meaning that no-matter who "owned" me, I've always been the usual pain in the ass :) :) :) :) Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The Commons
Ted, Sounds good to me. I think it would be better to start with one mailing list so ensure there is enough "mass" in discussions. Also, I am a bit dubious about the name "commons" (Don't know if there has been much discussion about that). The concept of a Commons is often used as an example of things that get abused because there is no ownership. If the name is up for discussion, can I suggest the name "substrate"? Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] The Commons
Nice initiative. Sharing code is allways great and there are in jakarta projects some fine pieces of code which could be used outside their 'original' project. A suggestion will be to ask all of you to do your best to organize this subproject in many smaller sub-subprojects just to avoid finishing with an UGLY library ( la GLIBC). (4) identify the initial set of committers Morgan Delagrange Ted Husted Geir Magnusson Jr. Costin Manolache Remy Maucherat Craig R. McClanahan Ignacio J. Ortega Rodney Waldhoff David Weinrich Count me on RPM packaging (will help check/specify cross dependencies) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
The archive for the interim "library-dev" mailing list is at mail-archive.com There is also a page linking the working documents at http://husted.com/about/jakarta/library.html . My own preference is that it be called something simple and generic. (I was good with library.) Conor MacNeill wrote: Ted, Sounds good to me. I think it would be better to start with one mailing list so ensure there is enough "mass" in discussions. Also, I am a bit dubious about the name "commons" (Don't know if there has been much discussion about that). The concept of a Commons is often used as an example of things that get abused because there is no ownership. If the name is up for discussion, can I suggest the name "substrate"? Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] The Commons
on 3/6/01 2:03 PM, "Ted Husted" [EMAIL PROTECTED] wrote: Proposal for "The Commons" - A Jakarta Subproject version 1.0 - 5 Mar 2001 (0) rationale Apache-Java and Jakarta originally hosted product-based subprojects, consisting of one major deliverable. The Java language however is package-based, and most of these products have many useful utilities. Some products are beginning to break these out so that they can be used independently. A Jakarta subproject to solely create and maintain independent packages is proposed to accelerate and guide this process. (1) scope of the subproject The subproject shall create and maintain packages written in the Java language, intended for use in server-related development, and designed to be used independently of any larger product or framework. Each package will be managed in the same manner as a larger Jakarta product.To further this goal, the subproject shall also host a workplace for Jakarta committers and a master index of reusable packages related to Jakarta products. (1.5) interaction with other subprojects (1.5.1) the sandbox The subproject will host a CVS repository available to all Jakarta committers as a workplace for new packages. Before releaseto the public, a sandbox package must be accepted to the library, or sponsored by another Jakartasubproject. (1.5.2) the directory The subproject will also catalog packages and other resources available to the public related to other Jakarta subprojects and ASF projects. This will be a dynamic catalog, like Bugzilla and Jyve, similar in functionality to download.com, cpan.org, or SourceForge.net. New entries may be added by Jakarta committers, developers, and users. Entries by developers and users will be approved by a committer before being made public. (2) identify the initial source from which the subproject is to be populated The initial packages would be based on existing ASF codebases, including those that provide services for DataSource/Database Pools, XML Configuration, Message Resources and i18n, JNDI and Naming, and Testing Suites. The initial committers have agreed to first create and maintain a Database Connection Pool package, along with related testing suites and subproject infrastructure. Comments: You haven't covered what happens with regards to management of these projects. Is it the initial committers responsibility to maintain each of these products? What is the long term outlook on these code bases? For example, in the Java Apache project, we had a java-whiteboard CVS tree (look at the /site/cvsindex.html page for the CVS tree). This was quite a bit of code that was abandoned over time. I would suggest maintaining the current feeling that all projects should have a minimum of 3 responsible people who oversee each of the projects. You also have not covered the possibility of competing implementations. For example, what if someone doesn't like the existing database connection pool and wants to contribute another product that duplicates the functionality? You also have not covered the possibility of an existing Jakarta project which has a competing implementation of something that exists in the commons. Is there some sort of policy that is being proposed at the higher Jakarta level that requires sub projects to become part of this project? [I actually think that this might be a good thing in order to help foster the community]. Other than the above comments (which are really asking more for clarification rather than being negative) I am +1 to see this happen. thanks, -jon stevens -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
