Re: [technology-pmc] Prerequisites for Graduation Review for Code Recomm

[Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>]

On 08.12.2011, at 22:48, Wayne Beaton wrote:

> With regard to diversity, more is always better. However, the current diversity in the project is sufficient for graduation.

OK. Good to know it would suffice.

> The "credit to Eclipse" aspect is also, IMHO, good as I seem to hear good things about the project from lots of different sources.

OK.

> I'm a little concerned, however, that there doesn't seem to be a functioning build. At least, I can't find the results of one (the repositories indicated on the project's download page appears to be bogus).

Since we need the whole infrastructure (Git/Jenkins/Update Sites etc.) for running student projects too, we considered this a sufficient solution to start with. However, we are moving our Jenkins builds to Eclipse now - and with it, we start signing the packages etc.

> It'd also be nice to see more community involvement via Bugzilla. I count 63 bugs, with only one of them including patches from a non-committer (Bug 347397). It's definitely a good start, however. FWIW, there is no record of this patch in the project's IP Log (either via marking bug attachments iplog+, or by setting the author field in Git). Let me know if you need help with this.

There are several student contributions that passed the IP checks. However, I did neither use the iplog+ flags nor the author field in Git so far. I'll take a closer look on that to fix this. I'll get back to you.

> Aside from that, are the project's APIs stabilizing?

Those we already have extension requests we get stable. 

* The extended documentation platform gets a flexible and stable API. McGill University expressed interest to provide extensions to this platform.

* The completion engines (calls, overrides, subwords, and call chain) do not expose any public APIs. They are just consumers of the existing APIs in JDT. There will be only a small fraction of utility classes which I'd like to keep in an internal package as long a no external party request their use.

* For Codesearch, we'll probably expose a front-end to the Lucene index that allows extenders to define Lucene queries on it.

* Snipmatch is unstable yet and I tend to think that we will not have any public APIs.

* The usage data collector (we would _like_ to deliver) depends on the outcome of the discussion on bug 347069 (especially privacy and data storage parts of that discussion) and the time we have at our disposal then.

* The code to generate and deliver your own models will likely be unstable. We planned to contribute them from the project's update site and not from the general Juno site to have shorter delivery cycles.

We are currently working out the project plan for Juno. A first draft is available here: http://www.eclipse.org/projects/project-plan.php?projectid=technology.recommenders

Please let me know if you need more information or have requests/complains.

Thanks,
Marcel

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