Call For Discussion: New Project: Atlantis

[Mario Torre]

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.

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>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898