Bugzilla – Full Text Bug Listing
| Summary: | Parallel IP - Where to draw the line on risk vs. speed | ||
|---|---|---|---|
| Product: | Community | Reporter: | Mike Milinkovich <mike.milinkovich> |
| Component: | Architecture Council | Assignee: | eclipse.org-architecture-council |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | caniszczyk, greensopinion, gunnar, janet.campbell, matthias.sohn, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | |||
| Bug Blocks: | 361287 | ||
|
Description
Mike Milinkovich
(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. |