[eclipse.org-architecture-council] [Bug 360994] New: Parallel IP - Where

[bugzilla-daemon@xxxxxxxxxxx]

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[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

-- 
Configure bugmail: https://bugs.eclipse.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.