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

[Dalibor Topic]

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