Re: Clearing the air round Incubator and Ruper (was Re: projects incubated by the incubator PMC)
Sander Striker wrote: On Wed, 2003-12-10 at 18:49, Brian Behlendorf wrote: On Wed, 10 Dec 2003, Nicola Ken Barozzi wrote: First of all, we are in the process of deciding and clearly documenting that only TLPs are to be incubated. Why? Because in Apache there are only TLPs. Thus, Ruper is incubated on the premises that it wants to become a TLP for artifact handling. Are you "in the process of deciding", or is this a decision? Where is the decision being made? I'm happy you asked :-) There was a discussion on the thread '[RT] Incubator Reorg', and then I posted a proposal as '[PROPOSAL] Incubator Reorg', to which only Sam replied. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=2867 I don't feel strongly pro or con, but if this is the case, then don't be surprised if the amount of confusion about "when should some non-trivial amount of code coming into the ASF go through the incubator?" increases. Many of the edge cases I've seen discussed (such as Wagon) have been natural extensions of or adjuncts to products released by an existing TLP. There was a discussion on the board list at the end of 2002. What was basically the point was that every external codebase would come through Incubator. No exceptions (for obvious reasons). IIRC the conclusion was that no PMC was to accept new projects on their own anymore. Maven is in the process of adding Wagon and other codebases, and they are not passing by the Incubator. Hence in my proposal all PMC chairs are to be in the Incubator automatically to be able to do IP clearance. There is ofcourse always the question between when a trivial patch becomes non-trivial enough to warrant going through incubator. I personally think that when you have to ask, you've got a incubator candidate. Seems good enough for me, as checking things that other PMCs are doing is IIUC only a board prerogative. Often it'll even be a proposal for a next-dot-oh of an existing release. Or another module for Apache httpd written by a company interested in donating it to the httpd project for inclusion into the core or as part of a contrib-modules release by the httpd project. So this could have a chilling effect on existing TLPs when confronted with the question, "has this contribution surpassed a threshold and should be sent through the incubator?". The reason to get Incubator involved is to be sure the paperwork is in order. If a new mod_whatever is to be donated we need a software grant, for instance. To not have to put the burden of knowing what paperwork is needed on each TLP, this knowledge is bundled in Incubator (at least, that's the idea). Then we have a process and policy issue, as we currently don't cater for this scenario. @see the '[PROPOSAL] Incubator Reorg' thread. I don't think you're going to see the board mandate that each TLP have only one product. A single "community" can easily manage/oversee the release of multiple products. Even semingly single project TLPs have multiple projects. HTTP Server has httpd, httpd-test, flood, apreq, just to name a few. I agree that we don't want every project to be a TLP. But maybe Nicola meant that from a legal standpoint there are only TLPs. I mean that the legal and actual *responsibility* of the well being of a community (not product) is of TLPs, which are the only ones legally recognized. I'm talking of recognized communities here, not products. A community can make more than one product. In essence, I could say that all *products* entering Apache have to pass by the Incubator, but only *communities* that want to go top level must enter the Incubator. If the PMC requires community incubation, we may as well help them, but it's not compulsory. First of all, we are in the process of deciding and clearly documenting that only TLPs are to be incubated. Why? Because in Apache there are only TLPs. I don't agree. The Incubator has a dual role. One is the building of new Projects, but the other is vetting all incoming codebases. Some confusion comes from applying the term "incubation" to both aspects of its role. Exactly. Since currently we only incubate communities, I use this meaning here. Please review the thread in the Board archives that I pointed out to Jason. As Sander noted as well, it was clearly stated that the Incubator is responsible for all incoming codebases developed outside of the Foundation. No, patches don't need to come through the incubator, and yes, there are grey areas, but the clearly stated intent was that the Board had designated the Incubator as the sole place through which an externally developed codebase could enter the ASF. Where the confusion comes from is related to the Community building usage of the term "incubation." The other PMCs have expressed that they want to do the Community Building when a codebase and a community is merging into their larger community. That is fine, but it does not change the Board's mandate regarding oversight of externally developed code
Re: [PROPOSAL] Incubator Reorg
Adding the changes suggested by Sam. Still need input from AltRMI and FTPServer. Nicola Ken Barozzi wrote: I believe that the Incubator Reorg RT has brought us to very interesting conclusions, that I'd like to summarize here as a proposal, for which I'd like to ask a vote after some discussion. Feel free to add items you regard as important WRT Incubator Reorg. Prolog There are no subprojects in Apache, only Projects that are usually called Top Level Projects or TLP. Thus the Incubator should reorg itself around incubating Projects. Incubator Scope The Incubator shall better define its scope as: 1 - incubation of projects, intending incubation of external codebases and communities that wish to become Apache Projects (TLP) 2 - assistance of projects that are importing new codebases and new sets of committers that formed an outside community, when requested by the project doing the "import" 3 - a place where projects should record the import of external codebases, therefore creating a clear audit trail for all donations 1 - Incubation of projects = To assist the incubation of projects, that will thus become Top Level Projects in Apache, it has been proposed that PPMCs will be created, that are basically test PMCs. Since the proposal is quite long, here it is on our wiki: http://wiki.apache.org/incubator/PpmcProposal 2 - Assistance of Projects that are importing new codebases = With new codebases, projects have to deal with new community integration and code import IP issues. The Incubator would be a place where they can find documentation about what to do and seek help on the lists. 3 - Code Audit Trail = This proposal would make all PMC Chairs automatically members of the Incubator, so that they can accept code donations to their projects on behalf of the ASF and record that a simple checklist is done in the Incubator CVS. This is to create a trail that clearly shows what has been done in the import of the new codebase, all in a single place. - 0 - NOW WHAT? Where would we go from here? We have to reasses the status of all incubating projects WRT the new rules, and add the needed PPMCs. Proposal: - AltRMI: decide where it wants to land - FTPServer: decide where it wants to land - Geronimo: make PPMC - JaxMe: pass it on to the Webservices PMC - Juddi: pass it on to the Webservices PMC - Lenya: pass it on to the Cocoon PMC - Pluto + Wsrp4j: propose a TLP with Jetspeed and move all there - Pluto + Wsrp4j: move to their sponsoring PMCs and suggest them to form a TLP when possible - XmlBeans: move to Xml PMC - Directory: create PPMC - Ruper: create PPMC We also need to create additional documentation for point (3), and add all PMC chairs to the Incubator PMC. Fire at will. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Clearing the air round Incubator and Ruper (was Re: projects incubated by the incubator PMC)
Nicola Ken Barozzi wrote: > Sander Striker wrote: > > There was a discussion on the board list at the end of 2002. What was > > basically the point was that every external codebase would come through > > Incubator. No exceptions (for obvious reasons). IIRC the conclusion > > was that no PMC was to accept new projects on their own anymore. > Maven is in the process of adding Wagon and other codebases, and they > are not passing by the Incubator. Hence in my proposal all PMC chairs > are to be in the Incubator automatically to be able to do IP clearance. How does that help? Where is the oversight? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clearing the air round Incubator and Ruper (was Re: projects incubated by the incubator PMC)
Noel J. Bergman wrote: Nicola Ken Barozzi wrote: Sander Striker wrote: There was a discussion on the board list at the end of 2002. What was basically the point was that every external codebase would come through Incubator. No exceptions (for obvious reasons). IIRC the conclusion was that no PMC was to accept new projects on their own anymore. Maven is in the process of adding Wagon and other codebases, and they are not passing by the Incubator. Hence in my proposal all PMC chairs are to be in the Incubator automatically to be able to do IP clearance. How does that help? Where is the oversight? "They are not passing the incubator" is not part of the proposal but what is actually happening. The proposal is that all Project Chairs are automatically under this PMC, and are responsible for telling us that the code is coming in, documenting it in our CVS with a simple checklist (a stripped-down version of the one we use for community incubation), and thus leave an audit trail and have us possibly help in checking. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Incubator Reorg
On Thu, Dec 11, 2003 at 08:36:20AM +0100, Nicola Ken Barozzi wrote: >... > > 3 - Code Audit Trail > > = > > > > This proposal would make all PMC Chairs automatically members of the > > Incubator, so that they can accept code donations to their projects on > > behalf of the ASF and record that a simple checklist is done in the > > Incubator CVS. This is to create a trail that clearly shows what has > > been done in the import of the new codebase, all in a single place. PMC Chairs are officers of the ASF. They can do a lot of things because of that, which also includes accepting code donations. They don't have to be part of the Incubator PMC for that. I don't think adding them to the Incubator PMC is the right approach. The end goal is the "code audit trail" as you mentioned. To that end, the Incubator can provide PMCs with a "short form" for them to use a checklist and/or "one pager" to deposit (say) in cvs:committers/something. Ideally the doc would go into cvs:foundation/something, but some PMC chairs are not Members, so they couldn't drop the audit checklists in there. I'd suggest setting up cvs:committers/audits/ and putting the checklist in there, maintained by the Incubator. Each PMC can then refer to it for their work. The Board can monitor what the PMCs are doing. If it looks like they're taking in code that should have hit the Incubator first, then we can deal with that. Cheers, -g -- Greg Stein, http://www.lyra.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Incubator Reorg
Greg Stein wrote: ... I'd suggest setting up cvs:committers/audits/ and putting the checklist in there, maintained by the Incubator. Each PMC can then refer to it for their work. The Board can monitor what the PMCs are doing. If it looks like they're taking in code that should have hit the Incubator first, then we can deal with that. I like this. IIUC it would also mean that the Incubator project members should subscribe to the committers-cvs list, to help monitor and maintain the checklist. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
