Community
Participate
Working Groups
The EMO would like the guidance of the Architecture Council on where to draw the line when approving 3rd party packages for new incubating projects. This question is being driven by the current wait state of large new projects such as Hudson and Stardust. Section IV(C) of the Eclipse IP Policy[1] allows for parallel IP. This was intended to help with new project start-up, by speeding up the initial approvals required for a project to check-in its code and its dependencies and start to really work as a project at Eclipse. There is, however, an inherent risk with parallel IP: a 3rd party dependency could be tentatively approved, a project could work for quite some time based on that code and then be forced to remove it. This scenario would obviously be very disruptive for any project. As a result, the EMO actually does a fair bit of work before approving a 3rd party dependency for check-in. We scan the package, check for licensing issues, and check the authoring project for how they track the provenance of contributions going into the code base. As a result, generally speaking the risk of a dependency being pulled later is actually quite low. However, the cost of doing this is time. This work takes time, and it delays the ability of a new project to get the code into Eclipse and start running builds, etc. We have been debating internally at the EMO if we should move the line towards taking on more risk with the advantage of getting new projects operational faster. To put the risk in perspective, the EMO's SWAG is that about 5% of 3rd party dependencies are rejected outright. About 25-30% more require remedial work to mitigate identified risks. (E.g. portions of the 3rd party library need to be removed.) If a component must be removed later, this involves a non-trivial expenditure of effort on the part of both the project team and the webmaster team. The latter is involved because offending packages need to be completely removed from git. My strawman proposal would be to take on more risk. Specifically, I think we should check for license and license compatibilty and that's it before approving for check-in. All of the provenance checking, deep code analysis, etc. would happen later. Your feedback and guidance would be very helpful. Hopefully we can reach a consensus on the best balance for the community. [1] http://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf
(In reply to comment #0) > To put the risk in perspective, the EMO's SWAG is that about 5% of 3rd party > dependencies are rejected outright. About 25-30% more require remedial work to > mitigate identified risks. (E.g. portions of the 3rd party library need to be > removed.) If a component must be removed later, this involves a non-trivial > expenditure of effort on the part of both the project team and the webmaster > team. The latter is involved because offending packages need to be completely > removed from git. For completeness, I'd like to call out the potentially devastating effect on a project to recover from the rejection of a dependency following the more rigorous check. It's entirely possible, for example, that a project could receive parallel IP check-in approval for a library, work for six months on code that builds on that library while due diligence checking occurs in parallel, and then be required to pull that library if the due diligence check finds something amiss. As project mentors, we will need to assist in the process of making sure that projects are aware of what they're getting into with parallel IP.
(In reply to comment #1) > For completeness, I'd like to call out the potentially devastating effect on a > project to recover from the rejection of a dependency following the more > rigorous check. It's entirely possible, for example, that a project could > receive parallel IP check-in approval for a library, work for six months on > code that builds on that library while due diligence checking occurs in > parallel, and then be required to pull that library if the due diligence check > finds something amiss. I wonder if we can separate the case of a project creation from the case where an existing project wants to add a new dependency. For an existing project, your argument makes sense. Of course there are always techniques to factor out the dependency to make it easy to drop if a project is careful about it. For a mature project moving to Eclipse, I don't think you are helping them by requiring them to wait. They already have that dependency, and delaying checkin just completely delays them moving their code to Eclipse. What typically happens in this case is that they continue their development outside of eclipse.org while they wait for all the approvals. I've seen a few cases over the years where a new project was announced, but the code didn't show up at eclipse.org for a long time. This slows down the community building process for that project at Eclipse.
I think it's in our best interest to take on more risk as the initial barrier for projects joining/moving to eclipse.org is really high. I'd rather pay the penalty later on then upfront and stalling the project. When a project is first announced, there tends to be buzz and I think it's important to get things moving quickly. Another underestimated value of the IP process is that it allows projects to take a critical look at their dependencies and fix dependencies that may not be really needed (take a look at Alex's post awhile ago about Tycho... http://akurtakov.blogspot.com/2011/05/awesomeness-of-eclipse-development_27.html) Also, in response to Wayne's concerns, the nightmare scenario sucks but it should be up to the mentors of the project to ensure that doesn't happen.
(In reply to comment #2) > (In reply to comment #1) > For a mature project moving to Eclipse, I don't think you are helping them by > requiring them to wait. They already have that dependency, and delaying checkin > just completely delays them moving their code to Eclipse. That is a very good point, and one that we hadn't thought of. I would add that all new projects at Eclipse need to be coming with source code. So this scenario, and the point you're making, is really the general case.
(In reply to comment #0) > About 25-30% more require remedial work to > mitigate identified risks. I opened bug 361019 to discuss a possibility of reducing that work. > My strawman proposal would be to take on more risk. Specifically, I think we > should check for license and license compatibilty and that's it before > approving for check-in. All of the provenance checking, deep code analysis, > etc. would happen later. I think that if a project understands and is willing to take the risk then we should support this. However, we do think we need a better indication libraries pending final IP review. I'm think of something like an Orbit incubator.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Several of us gave feedback here. I am going to consider this done, but feel free to ask more follow up questions, Mike.
