|[eclipse.org-architecture-council] [Bug 360994] New: Parallel IP - Where to draw the line on risk vs. speed|
https://bugs.eclipse.org/bugs/show_bug.cgi?id=360994 Product/Component: Community / Architecture Council Summary: Parallel IP - Where to draw the line on risk vs. speed Classification: Eclipse Foundation Product: Community Version: unspecified Platform: PC OS/Version: Windows 7 Status: NEW Severity: normal Priority: P3 Component: Architecture Council AssignedTo: eclipse.org-architecture-council@xxxxxxxxxxx ReportedBy: mike.milinkovich@xxxxxxxxxxx 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 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.  http://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf -- Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
Back to the top