Re: [technology-pmc] CodeMatch code snippet search engine considers movi

[Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>]

Thanks Gunnar. I split the discussion for CodeMatch and a general approach for code recommenders here. This email is about the move of CodeMatch.

I continued the conversation with Doug and we discussed a few things by email such as future plans, copyright, common technology stack etc. It looks good to me and we would like to continue now :) 

CodeMatch is developed by two people: Doug Wightman, and Zi Ye. Since this is my first time I do this: What is the common way how to move a project to Eclipse? The approach I have in mind is as follows:

1. They move the code to a new namespace and add EPL license headers to their files.
2. They contribute their tool via Eclipse Bugzilla.
3. I start the committer election for both.
4. When IP check and committer election pass we move the code to Eclipse Recommenders and continue development here.

Is this approach OK/correct?


On 21.08.2011, at 08:57, Gunnar Wagenknecht wrote:

> Hi Marcel,
> 
> Am 20.08.2011 14:49, schrieb Marcel Bruch:
>> Doug Wightman contacted me yesterday. Their research group likes to move
>> their code snippet search engine "CodeMatch"
>> (http://languageinterfaces.com/) over to Eclipse. Mike Milinkovich
>> suggested Doug that Code Recommenders may be a good place for this. 
> 
> +1
> 
>> The overall question is:
>> 1. Can we offer these services as part of Eclipse(!) Code Recommenders
>> project?
>> - or -
>> should we skip vendor-neutrality and let every subproject use it's own
>> server and deliver its tools without any association to Eclipse?
> 
> I think you have two things to consider.
> 
> You can ask the web masters for your own virtual server. For example,
> the EGit project does that to run Gerrit. However, this consumes
> Foundation resources. Thus, *IMHO* I think at some point in time it
> would be nice to have some funding for it (eg. FoE sponsorship).
> 
> On the other hand, what you guys are doing is valuable not only to open
> source developers. Thus, you might consider developing the collection
> server and reporting engine as part of your project too. Companies
> should be able to download it and run it within their networks for
> closed-source projects.
> 
> Thus, you should allow people to configure multiple "connectors". IMHO
> it's also great if there are public usable 3rd party connectors. Because
> the protocol is developed within your project and EPL licensed everbody
> can review it and see what's transfered over the wire.
> 
> Of course, you should consider implementing some security and
> scalability features. Frankly, there is no value in encrypting data when
> transferring them to open, public services for public consumption by
> developers. However, within a corporate network it would make sense to
> encrypt the data. Additionally, encryption should be customizable per
> connector so that company A cannot decrypt data of company B without
> gaining access to their secret key (for example).
> 
> You should also be careful about what data is collected on a per
> connector base. For example, public connectors should never get usage
> data of closed-source code. Thus, an explicit white-list approach of
> selecting packages per connector sounds like a good option.
> 
> Regarding data privacy I see it also a matter of trust. If the connector
> owner says "hey I don't collect your IPs" than I have to trust them. If
> I don't that I simply won't use the service.
> 
> If the above points are met, I have no strong opinion about requiring
> the service to run within the Foundation infrastructure. Of course, you
> should not enable a public connector with a bunch of packages listed per
> default.
> 
> -Gunnar
> 
> -- 
> Gunnar Wagenknecht
> gunnar@xxxxxxxxxxxxxxx
> http://wagenknecht.org/

Thanks,
Marcel

-- 
Eclipse Code Recommenders:
 w www.eclipse.org/recommenders
 tw www.twitter.com/marcelbruch
 g+ www.gplus.to/marcelbruch