Community
Participate
Working Groups
This is a request to amend Eclipse Development Process to allow components to be created in persistent incubator projects without requiring committer elections for the initial set of committers. More in depth discussion can be found here: http://lt-rider.blogspot.com/2010/08/inconvenient-process-lets-fix-it.html And also in the archives of wtp-incubator-dev mailing list.
(In reply to comment #0) > This is a request to amend Eclipse Development Process to allow components to > be created in persistent incubator projects without requiring committer > elections for the initial set of committers. What are the remaining requirements if the committer election requirement was to be dropped? > And also in the archives of wtp-incubator-dev mailing list. For easy referencing purposes, the link can be found here: http://dev.eclipse.org/mhonarc/lists/wtp-incubator-dev/maillist.html
> What are the remaining requirements if the committer election requirement was > to be dropped? The PMC should still be on the hook to approve/reject a component proposal. Really, what we need is a lighter weight project. Part of the reason why many projects haven't followed the modeling route and created sub-projects under the incubator for every proposed component is the length of time it takes to start one of these up. The delays make it impractical to start projects for transient work (something that will eventually merge into an existing project). Just brainstorming here... What if we created a concept of a temporary project that would only require PMC and EMO approval and could be started in a matter of days? In particular, temporary project would be exempt from: 1. Mandatory wait period between proposed and created. 2. Creation review (or in particular, the need to wait for the scheduled slot). 3. Need to find mentors. 4. Trademark review of the name. Similar to incubating projects, a temporary project would not be allowed to issue releases, etc. A temporary project would only be creatable under a mature project's PMC. If during course of development, the team decides to make a temporary project into a permanent one, a transition review would be held with all the regular project requirements now applying.
Why not use Eclipse Labs for "lighter weight" projects? A "Labs" project could later be absorbed into an existing Eclipse project or morph into its own.
Eclipse Labs lack in two important ways: 1. No IP safety. This makes these projects a problem for many early adopters. 2. Drastically different infrastructure. New committers don't get the experience of what it will be like working on an Eclipse project. Eclipse Labs is a good solution for features driven by independent developers, especially those features that don't fit into an existing top-level Eclipse project or cannot pass IP review.
Reassigning to AC for their input. My personal opinion is that incubators seem to be working in their current form (Orion grew out of an incubator, for example). Regular projects, like CDT seem to be very successful in managing access by a single group of committers to multiple functional areas. Further, we removed the formal notion of components from the EDP several years ago because they just made things more confusing and complex than they need to be. I recommend marking this as WONTFIX.
(In reply to comment #4) > [...] New committers don't get the > experience of what it will be like working on an Eclipse project. So how does taking away important parts of that experience help to create projects that are successful in a long term?
The goal of persistent incubators is not to create a project, but to provide a playground for experimentation and growing new committers for regular projects. Placing barriers to entry to the playground is counter-productive to that goal. A committer merit will be evaluated again if/when the feature in question merges into the parent project or forms its own project. But that's not even the point of this thread... Persistent incubators tend to be amorphous and divided up into many components with little or no relation to each other (besides being related functionally to the parent project). In effect, each component is a mini project. We don't ask committers on an existing project to vote on committers of an incoming new and unrelated project, yet this is effectively what happened that led to this thread.
In many ways, we could simplify things considerably if we shifted the process emphasis from project creation to project graduation. If creating a new project was quick-n-easy, there would be no need for persistent incubators and the concept of a component would not keep re-surfacing.
So what would be the alternative to the current election process? The project leads decide alone? The prospect committers just chime in as they want? And then, at graduation time, there will be new elections/decisions? Maybe not for the initial committers as declared in the proposal?
Same thing as what happens for projects... The PMC gets to review and approve scope and committer list. There is no per-committer elections during project formation, so I see no point to having committer elections when forming new components in a persistent incubator. Note that I am not arguing that there should not be committer elections if someone wants to join an existing component. Even in incubators, once work has started on a feature, the existing set of committers should be able to decide who else joins the effort. Note that persistent incubators don't graduate. Pieces are either merged into other projects (with committer elections) or a new project is formed based a chunk. In both of those cases, we already have process in place.
(In reply to comment #10) > Note that persistent incubators don't graduate. Pieces are either merged > into other projects (with committer elections) or a new project is formed > based a chunk. Oh, I really missed that point.
(In reply to comment #10) > Same thing as what happens for projects... The PMC gets to review and > approve scope and committer list. There is no per-committer elections during > project formation, so I see no point to having committer elections when > forming new components in a persistent incubator. New project proposals act as the committer election. Historically, we've required that the creation review documentation contain election criteria for each committer. A few years ago, I started accepting the proposal document as the creation review document and relaxed the requirement for an explicit nomination criteria (making the reasonable assumption that the specified committers were involved in the creation of the initial contribution). Note that we do not have any formal notion of "components" within projects. Everything is a project. If you add committers to a persistent incubator, they get lumped into the single group of committers and have uniform access to all of the project's resources. Is the more general problem that we need to have a means by which a project can decide how to onboard new committers? e.g. a persistent incubator should be able to decide (perhaps with PMC approval) that formal elections are not required. Or perhaps a project might decide that three days is enough time for an election... Or am I off on a tangent?
> New project proposals act as the committer election. Except that no actual election takes place. The only one impacted by having sub-standard committers on the project is the project, so we smartly leave the initial committer list to those behind the proposal. > Is the more general problem that we need to have a means by which a project > can decide how to onboard new committers? That's an unrelated question and would not do anything to address the issue that started this thread. It assumes uniformity across a persistent incubator that typically doesn't exist. In this case, committers on a more established component wanted to see proof of merit from incoming committers on a brand new component in a completely unrelated area. > Note that we do not have any formal notion of "components" within projects. Indeed, but unless we minimize project creation barriers, we will continue to encounter developers working around the process via other constructs such as components and persistent incubators. This is sub-optimal.
Bug 416188 tracks another way of approaching this problem, which would eliminate the need for components and persistent incubators.
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/135.
