Call For Discussion: New Project: Atlantis

[jesper.wilhelmsson at oracle.com]

> On 20 Nov 2018, at 17:21, Mario Torre <neugens at redhat.com> wrote:
> 
> On Tue, 2018-11-20 at 15:38 +0000, Andrew Dinn wrote:
>> On 20/11/2018 15:14, Mario Torre wrote:
>>> On Tue, 2018-11-20 at 15:38 +0100, Thomas Stüfe wrote:
>>>> I'm worried about fragmentation though. Once we have this
>>>> project,
>>>> what is then the role of serviceability-dev? Just smallish
>>>> everyday
>>>> fixes? Also, the fact that VM developer feedback is hard to come
>>>> by
>>>> is
>>>> mostly due to a lack of time on their part, and a new mailing
>>>> list
>>>> will not fix that.
>>> 
>>> Generally projects have their own mailing lists for development
>>> until
>>> they are "finished", I would expect that for this project it would
>>> work
>>> the same, once it's integrated into mainline it becomes part of the
>>> serviceability code and the project mailing list is folded into
>>> serviceability-dev, until then it's somewhat an independent unit.
>> 
>> Well, there is a requirement that anything new of a significant size
>> orc
>> complexity that gets developed under a JEP and then integrated into
>> the
>> mainline repos will have someone available to maintain it.
> 
> Yes, indeed!
> 
>> JC, can you provide assurance that Google staff involved in pushing
>> any
>> code upstream will also be available to help perform that maintenance
>> effort, in this case presumably as members of the serviceability
>> team?
>> 
>> n.b. Modulo the above detail I'm all for this proposal. I'd be very
>> pleased if the project brings opportunities for Google either to
>> upstream their existing work to everyone's benefit or, where for
>> whatever reason that is not feasible, to help tailor existing
>> upstream
>> capabilities (such as JFR events) so they might encompass Google's
>> downstream needs.
>> 
>> It's very welcome to see Google so willing to contribute to OpenJDK.
> 
> I agree!
> 
> I actually wanted to ask that one written requirement in the JEP would
> be to extend Flight Recorder whenever it makes sense, even if this
> means going an extra step (in other words, the default option), so that
> we avoid fragmentation and the proliferation of a multitude of tools.

+1

Given that it is an explicit goal to extend and utilize existing frameworks rather than adding another one, I welcome this project.
/Jesper

> 
> I understand the project is meant to be some sort of umbrealla for
> experiementation? This will probably already cure most of the risk of
> such fragmentation, however, if it's a written statement in the JEP
> goals it makes more explicit that we are interested in enhancing the
> current frameworks rather than creating alternative versions (unless it
> *really* makes sense to do so).
> 
> Cheers,
> Mario
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com <https://www.redhat.com/>>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898