Thursday, April 01, 2010

Git vs. IP provenance -- DVCS with a twist

With a Distributed Version Control System (DVCS) such as Git, there is no reliance on a central system.  This allows developers to easily pound out and exchange code amongst themselves.

This also causes an Intellectual Property (IP) nightmare for OSS foundations like Eclipse, where IP and IP provenance are keystones to the organization.

For a DVCS to work at Eclipse.org, we need to make some compromises. The Eclipse Foundation needs to know where the code comes from, and who wrote it. Picture this:



In the case above, Jimmy and Jina are not known to Eclipse.org, but they are working together to help Billy, an Eclipse committer, by contributing code.  Since Git does not maintain a "push" log, if Billy's push to git.eclipse.org was to succeed, we would have a git commit history that would contain entries of people that we do not know.  In fact, since the email address is configured by the user, Eclipse has no real way of determining the validity of the information.

In the above case, the push will fail.  So how does Billy make this work?



The correct workflow is seen above.  Jimmy and Jina implement a feature and wish to have it included in Eclipse.  They submit a patch to Bugzilla, where it is then reviewed by a committer by following the Eclipse Development Process and Due Diligence guidelines.  From here, the committer will submit the code contribution to IPZilla if need be.

If the code passes all the required reviews, Billy incorporates it into his local Git clone and pushes the code to Eclipse's Git server.  Since the Git commit log contains an entry for the Author name/email, Committer name/email and a commit comment, the names of the original authors, as well as the bug number can all be referenced for easy traceability.

This process does remove a bit of the "D" in DVCS, but if we follow a few simple rules, we can still take advantage of the benefits of Git while maintaining a clean IP trail.

0 Comments:

Post a Comment

<< Home