On 19/02/15 17:06, Roman Kennke wrote:
> Am Donnerstag, den 19.02.2015 um 15:25 +0100 schrieb dalibor topic:
>>
>> On 19.02.2015 13:50, Mario Torre wrote:
>>
>>> The code is part of an OpenJDK project, though, it's already the
>>> existing Java rasterizer.
>>
>> It's not part of an OpenJDK Project - Project with an upper case 'P'.
>> See http://openjdk.java.net/projects/ for details. Considering the
>> motivation for this discussion, that would be a necessary precondition.
>>
>>> Of course I'm fine with giving it a formal home in the Graphics
>>> Rasterizer project (where it naturally belongs), but let's also try to
>>> be a bit more pragmatic, this code is in hold since more than one year
>>> now, the JEP process can be started before giving a formal home, or at
>>> least concurrently to that.
>>
>> While the JEP process is explicitly open even to aggressive,
>> outside-the-box, and even completely wacky ideas, new feature ideas
>> often require significant up-front research, experimentation, and
>> socialization before they're ready to be proposed as enhancements to the
>> JDK itself.
>
> Socialization seems to be the major pain point here ;-)
>
> It seems that the project is already fairly well advanced, and, from
> what I hear, used in production code in some places already, where it
> seems to outperform the pisces rasterizer.
>
> The impact of including it in OpenJDK seems to be fairly small: it is an
> implementation of an existing SPI, and there's no need to make it the
> *default* right away. It can be included and live side-by-side and
> require some runtime flag to get it enabled. And when enough testing has
> been done, eventually switched to default.
>
>> That work is typically performed within an OpenJDK Project.
>
> I agree that it'd be good to bring Marlin into the Rasterizer project
> (which otherwise appeared to be an orphaned project anyway...) Why not
> go both routes in parallel: propose inclusion into the Rasterizer
> project, and start discussing a JEP. I see no problem with that.
>
>> Such work would have to take the time it takes either way. I believe
>> that focusing on writing JEPs before such work is complete (or even
>> begun) means setting one's priorities in a way that puts the cart before
>> the horse. You can certainly chose to do that, but the cart might not
>> get very far on its own. [0]
>
> Well, dunno, it just seems pragmatic to me. If anything, OpenJDK could
> need a little more agility and welcomeness to contributions, especially
> if they provide such massive improvements, and has already been tested
> outside OpenJDK for quite a while (exactly because it got stuck in
> OpenJDK's processes).
Speaking from past experience:
External contributors will quickly lose their enthusiasm when
there is no easy way to commit some code.
That being said: What can everyday Marlin users do in terms of
testing/reporting that might help this process along -- preferably
without too much formal overhead?
Best,
Ben
>
> Regards,
> Roman
>
--
Dr. Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
Spatial technology for the masses, not the classes:
experience free and open source GIS at http://gvsigce.org
