Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Development Process 2006 New Incubation"

(Project Lifecycle)
(Project Lifecycle)
Line 27: Line 27:
  
 
Many Eclipse Projects are proposed and initiated by individuals with extensive and successful software development experience. This document attempts to define a process that is sufficiently flexible to learn from all its participants. At the same time, however, the Incubation phase is useful for new Projects to learn the community-defined Eclipse-centric open source processes.
 
Many Eclipse Projects are proposed and initiated by individuals with extensive and successful software development experience. This document attempts to define a process that is sufficiently flexible to learn from all its participants. At the same time, however, the Incubation phase is useful for new Projects to learn the community-defined Eclipse-centric open source processes.
 +
<div style="border: 2px solid #8E87EB; padding: 6px;">Jochen, what is the reasoning behind this proposal? Are you trying to have the projects commit to an architecture early in their lifecycle? Are you trying to separate the existence of IP cleared code from the existence of a functioning community? If the proposal has Eclipse-based infrastructure for everything expect the code, aren't there IP issues around that as well (e.g., what if a project discusses a GPLed contribution to their external repository but does so on the Eclipse newsgroup; the newsgroup explicits defines all postings as EPLed, so ...)? And wouldn't this proposal have the side-effect of making it more convenient to propose a project with no initial code (because then you wouldn't have to discuss the architecture in advance)? <br>I believe you have a goal in mind for this proposal, but I'm not clear what that goal is. Thanks.''--Bjorn Freeman-Benson''</div>

Revision as of 18:05, 18 November 2006

Project Lifecycle

Eclipse dev process jk.png

Strike through means striked from original, underlined means new.

Projects go through sixseven distinct phases. The transitions from phase to phase are open and transparent public reviews.

Pre-proposal - An individual or group of individuals declares their interest in, and rationale for, establishing a project. The EMO will assist such groups in the preparation of a project Proposal.

  • The Pre-proposal phase ends when the Proposal is published by EMO and announced to the membership by the EMO.

Proposal - The proposers, in conjunction with the destination PMC and the community, collaborate in public to enhance, refine, and clarify the proposal. Mentors for the project must be identified during this phase.

  • The Proposal phase ends with a Creation Review Proposal Review or a Termination Review.


Proposal review - The reviews are not described in the original project lifecycle, it is added here anyway for providing info about the purpose of this review. The proposal review checks whether the proposal is in compliance with the Eclipse Bylaws and if the required number of Mentors have been found.


Proposal Validation - After the proposal has been accepted for validation, the purpose of the proposal validation phase is to establish a basic (documented) architecture and to validate this architecture with a working implementation. The proposal team should make all planed code contributions available during proposal validation. It should be able to instantly use the code contributions. The contributions need to be worked to eclipse quality requirements (tests, api, documentation) during Proposal Validation. The proposers need to create an easily consumable build of the implementation. As there are legal requirements for ip compliance at Eclipse.org, I propose that we use an infrastructure (e.g. from a partner) where the code can live, where we do not have the ip compliance requirement. Eclipse.org would provide newsgroup, mailing list and web space during proposal validation, but the sources and builds would be provided from a different site. IMPORTANT: Mentors would be available to the proposers in the proposal validation phase, but we would not speak of an Eclipse project at this phase.

  • The Proposal Validation phase ends with a successful Creation Review or a Termination Review.


Incubation - After the project has been created, the purpose of the incubation phase is to establish a fully-functioning open-source project. In this context, incubation is about developing the process, the community, and the technology. Incubation is a phase rather than a place: new projects may be incubated under any existing Top-Level Project.

  • The Incubation phase ends with a successful Graduation Review or a Termination Review.
  • The Incubation phase may continue with a Continuation Review.
  • Top-Level Projects cannot be incubated and can only be created from existing Mature-phase Projects.

Many Eclipse Projects are proposed and initiated by individuals with extensive and successful software development experience. This document attempts to define a process that is sufficiently flexible to learn from all its participants. At the same time, however, the Incubation phase is useful for new Projects to learn the community-defined Eclipse-centric open source processes.

Jochen, what is the reasoning behind this proposal? Are you trying to have the projects commit to an architecture early in their lifecycle? Are you trying to separate the existence of IP cleared code from the existence of a functioning community? If the proposal has Eclipse-based infrastructure for everything expect the code, aren't there IP issues around that as well (e.g., what if a project discusses a GPLed contribution to their external repository but does so on the Eclipse newsgroup; the newsgroup explicits defines all postings as EPLed, so ...)? And wouldn't this proposal have the side-effect of making it more convenient to propose a project with no initial code (because then you wouldn't have to discuss the architecture in advance)?
I believe you have a goal in mind for this proposal, but I'm not clear what that goal is. Thanks.--Bjorn Freeman-Benson

Back to the top