Maintaining ports (was Re: Support for Netscape/Mozilla plug-in on Linux AMD64 native platform)

[Kurt Miller]

Dalibor Topic wrote:
> Mark Reinhold wrote:
>> I'm not sure that a general "Porters" Group is the optimal route; such a
>> Group would, I suspect, tend to lack focus.  What may make more sense is
>> for each specific porting effort (e.g., BSD) to propose its own Project
>> into which the relevant code can initially be contributed, synced with
>> the mainline code, and generally hacked upon until it's ready to be
>> proposed for integration.  Once that integration happens then further
>> development and maintenance of the port would be done under the aegis
>> of the appropriate mainline project (e.g., JDK 7).
>>   
> 
> I think 'lack of focus' is a general issue when porting OpenJDK, as
> depending on the configuration one  is porting to, one needs to work
> on many different components. A porters group would seem to be
> a good place to group different projects together that have at least one
> thing in common: they aren't going to be supported as part of the
> mainline QA work by Sun, but, as you said, can serve as 'staging
> ground' for code & fixes destined to go upstream into mainline,
> coming from different porting communities.
> 
> I see a couple of benefits to such a structure: the porting efforts can
> use our bug tracking, repository, review and legal (SCA) infrastructure,
> which should make merging in their fixes and features into the
> mainline project much easier. It would also allow us to formally
> recognize such projects as parts of the OpenJDK community,
> and the contributors channeling their contributions through the porting
> projects would know that their patches contribute to OpenJDK, even if
> the actual merging and review process into mainline, once a
> contribution has entered via a porting project, takes a while to
> ensure the high standards necessary for code coming into the
> OpenJDK core.
> 
> Finally, grouping porting projects together would also serve as a tiny
> demarcation line between parts of OpenJDK that are officially part of
> the mainline jdk7, and porting efforts that are not (yet). Chances
> are that some porting efforts will never be worth the monetary
> investment in QA it would take to make them non-academic in nature.
> But that's OK, they still may end up doing useful work on other
> components of OpenJDK as part of their efforts, and as long as they
> are not a drain on our resources, I'd rather have them inside
> OpenJDK, than outside.
> 
> I'd expect us to mirror part of the project roster of the 'porters'
> group inside the conformance group, so I guess we may as well group
> them all together formally. :)
> 
> cheers,
> dalibor topic

I see the merits of both approaches (single porters group vs specific
porters group). I do have some concerns with a single porters group
that perhaps can mitigated. The BSD ports are mature ports that have
been maintained since 1.1.  The needs of a general porters group
will likely be a bit different then what the focus of a BSD group
would be. I would anticipate new ports would want to discuss and
experiment porting the JDK to other platforms, whereas the BSD port is
complete and would be focused on improving the quality of the existing
port to the point where it could become part of the source tree someday.

If there was general porters group but a separate project for the BSD's
that might would work too. Ultimately I would want to keep the BSD port
source code separate from new (less mature) ports to other platforms. My
concern with a mixed source environment would be that new ports would
distract from the goal of the BSD port eventually being integrated. Even
if BSD integration is never achieved due to other barriers, maintaining
and improving the high quality of the BSD port is quite important for us.

For the above reasons I tend to favor a BSD specific group and an
associated project. The focus of such a group would be well defined
and its goals achievable; i.e. ongoing BSD support and maintenance of
OpenJDK and the improvement of port quality for some future possible
integration with the main source tree.

Regards,
-Kurt