On 02/07/2013 05:45 PM, Christian Thalinger wrote:
On Feb 4, 2013, at 8:18 PM, Martijn Verburg <martijnverb...@gmail.com> wrote:
Hi Christian,
This was discussed at FOSDEM (and in the months leading up to it). We are
going to start a prototype for this idea in the LJC and gather requirements,
look at security implications etc.
Oh, that's great! I should have gone this year then :-)
-- Chris
yes,
we miss you :)
Rémi
We are still in the process of securing finding for some hosting etc but will
get started shorty after.
Cheers,
Martijn
On Tuesday, 5 February 2013, Christian Thalinger wrote:
On Feb 4, 2013, at 12:42 AM, David Holmes <david.hol...@oracle.com> wrote:
Hi Mark,
On 4/02/2013 6:22 PM, mark.reinh...@oracle.com wrote:
2013/2/2 13:42 +0100, david.hol...@oracle.com:
...
I think the "risks" are a little under-stated. You have changed shared code and
that potentially impacts all platforms (unless you have only added new
functions unused on existing platforms?). There is also the matter of the
"elephant in the room" - the existing proprietary PPC port that Oracle has for
Java SE Embedded. Someone (from Oracle of course) will have to see how the
proposed structure of the new port will impact the existing closed port. It
might be a non-issue, or a major issue - most likely somewhere in between.
Either way, issues with a proprietary port that's downstream of OpenJDK
are for the maintainers of that port to solve, regardless of whether the
maintainers work for Oracle. The existence of a proprietary port cannot
hold back the contribution of an open port.
Ok.
I am also hoping that this will not simply be a copy'n'modify port as we have
seen in the past. The proliferation of platform ifdefs in shared code is truly
horrendous; as is the duplication across the purportedly platform-specific
code. This problem wasn't addressed for the Mac port but in my opinion (and
that is all it is) it needs to be before the community accepts any further
ports.
I think it'd be a fine thing for that code to be refactored and cleaned
up, but I don't see that as a prerequisite for a new port coming in.
The code base will be unmanageable if we keep doing this copy'n'modify approach to
porting, and the more ports we add the more impractical it becomes to try and retrofit a
cleaner porting architecture. The OSX/bsd port is still causing us
"indigestion".
I'd also like to understand the proposed maintenance model going forward. We
(in Oracle) already have to accommodate our closed ports when they are affected
by changes to common code that requires per-platform changes as well. Who will
be providing the changes needed for aix-ppc? And how will that happen?
Every port needs a documented set of maintainers, and it's up to the
maintainers to track changes in shared code. If a port stops being
maintained and rots for a significant period of time then it's likely to
be removed. This is how similar long-lived projects (e.g., GCC) work.
Even if there are designated maintainers there is still a matter of how things
will proceed. If someone is changing shared code who has the responsibility for
making sure every port is accounted for? Do we have to coordinate things so
that no changes are made until all changes are ready? Or do we allow things to
break until the designated maintainers catch up?
It would be desirable to have an integration build and testing system that
includes all platforms which are supported by OpenJDK. Ideally this would be
an open system where OpenJDK members (other companies than Oracle) could add
their machines for the platforms they care about.
-- Chris
Now that a port that's to be maintained by non-Oracle developers is being
proposed, I will soon propose a formal policy along these lines.
That would be good to see.
Thanks,
David
- Mark
