Hi Gustavo,
My first question is why there’s not a public API for
access the StatusInfo dialog. You should probably look into that first. If
there’s no public way to get at this, here’s my general advice for
this situation:
1) I would avoid dependencies to internal classes in other
projects. If it’s something small, duplication is a better choice - as Sybase
has done. If it’s something big, then a discussion about making the API’s
public is the right way to go.
2) When you copy and modify EPL code from another project, you’ve
created a derivative work. You need to retain the original copyright from IBM and
add Sybase’s copyright.
3) Given that there are no sybase committers on MTJ, then this
is an external contribution. Looking at the Due Diligence process flowchart,
you start on Figure 3. When you get to Figure 12, there’s the magic
question, “is this 250 lines of code or less”? This is a somewhat
arbitrary metric for determining if we think the contribution is “significant”.
I don’t like relying strictly on a LOC metric, though. Rather, I would
say that if the contributor is introducing new functionality, then it’s
probably a significant contribution and a CQ is required. But as the committer,
it’s your call. In either case, you need to log this in the IP log.
Doug
From: Paula
Gustavo-WGP010 [mailto:wgp010@xxxxxxxxxxxx]
Sent: Tuesday, June 24, 2008 6:22 PM
To: Gaff, Doug
Cc: Mobile Tools for The Java Platform mailing list
Subject: Question about external contribution
Hi
doug,
On
MTJ we just had some contributions from sybase. In one of the contributions, a
class from JDT (org.eclipse.jdt.internal.ui.dialogs.StatusInfo) was added to
the patch (a new class was created on MTJ with the same code and copyright -
IBM). The reason for adding the class directly to MTJ is that it is an internal
class and that we are not suppose to access it directly (but i think that the
package is exported). From the ip review process, i think that all code from a
patch is suppose to have the copyright of the contributor, isn't?
One
additional information, the contribution itself is small. Since that, i wasn't
initially planning to submit a CQ for it.
My
first question is:
-
Can we keep the approach they implemented or can we just add a dependency with
JDT in an internal JDT class? It seems to me that it would be dangerous to add
this dependency, but maybe it is common to do that on other eclipse projects.
If
we keep their approach, i need some advice on how to proceed. I saw the below
options
-
submit a CQ to all the code
-
ask them to break the contribution into their code and IBMs code
-
leave it in the way that it is and commit the code. There is actually no
problem on that approach.
Thanks
:)
gustavo