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 > > 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
