Group Proposal, for discussion: IDE & Tooling support

[Magnus Ihse Bursie]

> 5 mars 2019 kl. 19:04 skrev Maurizio Cimadamore <maurizio.cimadamore at oracle.com>:
> 
> So, one of the thing that emerged at the OpenJDK Committer Workshop was mainly the need of having a place where to discuss IDE related issues.
> 
> While build-dev and build-infra in general are all fine places to have these discussions (and we had some of these in the past), there are things that are suboptimal in our current approach:
> 
> * specificity: build-dev has a lot more traffic on a lot of issues that have nothing to do with IDE support
> * scattered-ness: somethings, yes, will rely on build support to 'do the right thing' - but most of them don't see the jtreg plugin support in IntelliJ. That lives in code-tools and has nothing to do whatsoever with build-dev or makefiles, even. All discussion related to that is happening on jtreg-dev.
> 
> So, we need a place for discuss things, and to provide documentation of _what already_ exists. At the moment, honestly, I'm much less interested into adding more features into the various supports we have.
> 
> Do we need a separate repo to do the documentation part? I don't think so. And that's what led us to consider forming a group. Now, I don't feel too strongly about this - but a Group doesn't strike me as a choice that doesn't make sense either.
> 
> As a closing comment, of course whatever we do might be affected (or affect!) build system components - so I'm not proposing we discuss things in a vacuum; but I want to stress the importance of centralizing all discussion and documentations in a place that feels 'independent' from compiler-dev, build-dev or jtreg-dev.
> 

Sounds like you've thought this through. 

I'll just have to accept that there'll be yet another list I'll have to subscribe to. ;-)

/Magnus

> Maurizio
> 
>> On 05/03/2019 11:10, Magnus Ihse Bursie wrote:
>> I agree that providing a great IDE experience is a very beneficial thing, both for existing OpenJDK developers, and for attracting new ones.
>> 
>> Is this goal is best served by creating a new group? I don't know. I'm a bit skeptical, and think that this work still fits quite well under the Build Group umbrella, but if this is not the general perception, I will not protest against creating a new group.
>> 
>> Also, an alternative to creating a group is to create a Project. I'm certain the Build Group could sponsor an IDE Integration Project, or something like that. A Project can also get mailing lists and repos, but does not need to have a Group Lead that needs to perform additional duties like sending a yearly status report, etc.