Support for Netscape/Mozilla plug-in on Linux AMD64 native platform

[Massimo Perga-2]

Hello All,
  I'm writing here to know what's the best process to follow in order to have more informations on such a plug-in.
I'm not requesting it... rather, I'm *offering* to port the current 32-bit Linux version to a native 64-bit version.
To accomplish this task, which is the project that takes care of such a plug-in ? Otherwise, have I to request a new project ?

Thanks in advance,
Regards,
  Max


      ___________________________________
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html

[Dalibor Topic]

Massimo Perga wrote:
> Hello All,
>   I'm writing here to know what's the best process to follow in order to have more informations on such a plug-in.
> I'm not requesting it... rather, I'm *offering* to port the current 32-bit Linux version to a native 64-bit version.
> To accomplish this task, which is the project that takes care of such a plug-in ? Otherwise, have I to request a new project ?
>  
The JDK plugin code is not available yet as part of OpenJDK.

If you want to work on improving gcjwebplugin's support for
OpenJDK/IcedTea, you can do that via the distro-pkg-dev list.

cheers,
dalibor topic

[Kurt Miller-3]

On Monday 29 October 2007 8:51:11 am Massimo Perga wrote:

> Hello All,
>   I'm writing here to know what's the best process to follow in order to
> have more informations on such a plug-in. I'm not requesting it... rather,
> I'm *offering* to port the current 32-bit Linux version to a native 64-bit
> version. To accomplish this task, which is the project that takes care of
> such a plug-in ? Otherwise, have I to request a new project ?
>
> Thanks in advance,
> Regards,
>   Max

Myself and Jung-uk Kim have completed making the plugin 64-bit
clean for the 1.6 JRL licensed plugin. You can find our work in patchset
2 for BSD:

http://www.eyesbeyond.com/freebsddom/java/JDK16JRLConfirm.html

Regards,
-Kurt

[Dalibor Topic]

Kurt Miller wrote:

> On Monday 29 October 2007 8:51:11 am Massimo Perga wrote:
>  
>> Hello All,
>>   I'm writing here to know what's the best process to follow in order to
>> have more informations on such a plug-in. I'm not requesting it... rather,
>> I'm *offering* to port the current 32-bit Linux version to a native 64-bit
>> version. To accomplish this task, which is the project that takes care of
>> such a plug-in ? Otherwise, have I to request a new project ?
>>
>> Thanks in advance,
>> Regards,
>>   Max
>>    
>
> Myself and Jung-uk Kim have completed making the plugin 64-bit
> clean for the 1.6 JRL licensed plugin. You can find our work in patchset
> 2 for BSD:
>
> http://www.eyesbeyond.com/freebsddom/java/JDK16JRLConfirm.html
>  

On an unrelated note, would it make sense to create infrastructure for
the porting projects inside OpenJDK? I am wondering if we shouldn't
create an official 'porters' group, with projects for ports to *BSD, etc.

While Sun may not be interested in merging in all such ports into the
main OpenJDK tree, it could be useful to have the patch sets maintained
centrally as part of the OpenJDK infrastructure. The distributed mercurial
setup could give us that liberty, I think.

cheers,
dalibor topic

[Volker Simonis]

On 10/29/07, Dalibor Topic <robilad@...> wrote:

> Kurt Miller wrote:
> > On Monday 29 October 2007 8:51:11 am Massimo Perga wrote:
> >
> >> Hello All,
> >>   I'm writing here to know what's the best process to follow in order to
> >> have more informations on such a plug-in. I'm not requesting it... rather,
> >> I'm *offering* to port the current 32-bit Linux version to a native 64-bit
> >> version. To accomplish this task, which is the project that takes care of
> >> such a plug-in ? Otherwise, have I to request a new project ?
> >>
> >> Thanks in advance,
> >> Regards,
> >>   Max
> >>
> >
> > Myself and Jung-uk Kim have completed making the plugin 64-bit
> > clean for the 1.6 JRL licensed plugin. You can find our work in patchset
> > 2 for BSD:
> >
> > http://www.eyesbeyond.com/freebsddom/java/JDK16JRLConfirm.html
> >
> On an unrelated note, would it make sense to create infrastructure for
> the porting projects inside OpenJDK? I am wondering if we shouldn't
> create an official 'porters' group, with projects for ports to *BSD, etc.
>
> While Sun may not be interested in merging in all such ports into the
> main OpenJDK tree, it could be useful to have the patch sets maintained
> centrally as part of the OpenJDK infrastructure. The distributed mercurial
> setup could give us that liberty, I think.
>

This sounds like a very usefull thing to do, especially to avoid
multiple ports for the same platform. In reality there will be
(hopefully) quite a lot of ports and it will be probably unavoidable
that multiple ports for a single platform will emerge. (Imagine for
example two companies contributing their ports for the same platform
which they also distribute under a second, closed licence. So it will
be impossible for these companies, to integrate code from the OpenJDK
project into their private version.)

However a porting group will definitely be a very good place to
discuss and to coordinate the different ports.

Volker

PS: perhaps it would make sense to start a new thread for this topic
as it has nothing more to do with Mozilla plugins for AMD64?


> cheers,
> dalibor topic
>

Dalibor Topic wrote:

> Kurt Miller wrote:
>> On Monday 29 October 2007 8:51:11 am Massimo Perga wrote:  
>>> Hello All,
>>>   I'm writing here to know what's the best process to follow in
>>> order to
>>> have more informations on such a plug-in. I'm not requesting it...
>>> rather,
>>> I'm *offering* to port the current 32-bit Linux version to a native
>>> 64-bit
>>> version. To accomplish this task, which is the project that takes
>>> care of
>>> such a plug-in ? Otherwise, have I to request a new project ?
>>>
>>> Thanks in advance,
>>> Regards,
>>>   Max    
>> Myself and Jung-uk Kim have completed making the plugin 64-bit
>> clean for the 1.6 JRL licensed plugin. You can find our work in patchset
>> 2 for BSD:
>>
>> http://www.eyesbeyond.com/freebsddom/java/JDK16JRLConfirm.html
>>  
> On an unrelated note, would it make sense to create infrastructure for
> the porting projects inside OpenJDK? I am wondering if we shouldn't
> create an official 'porters' group, with projects for ports to *BSD, etc.
>
> While Sun may not be interested in merging in all such ports into the
> main OpenJDK tree, it could be useful to have the patch sets maintained
> centrally as part of the OpenJDK infrastructure. The distributed
> mercurial
> setup could give us that liberty, I think.
>
> cheers,
> dalibor topic

I'm very much in agreement with any move in this direction.

I have a concern which I've heard some people inside Sun speak.  
Namely:  Who will be responsible for the quality of these ports?

At the meeting we held at FOSDEM I remember the lecture we had in the
operation of the GCC project and how they go about supporting lots of
CPU architecture and OS platform combinations.  On the one hand I think
the OpenJDK has the potential to have that same breadth of platform
support.  But if it's at the cost of the Sun quality engineering team it
will not work.

I think hosting a project like this has to be coupled with a plan for
maintaining quality in that project.

- David Herron

[Andrew Haley]

David Herron writes:
 > Dalibor Topic wrote:
 > > Kurt Miller wrote:

 > > While Sun may not be interested in merging in all such ports into the
 > > main OpenJDK tree, it could be useful to have the patch sets maintained
 > > centrally as part of the OpenJDK infrastructure. The distributed
 > > mercurial
 > > setup could give us that liberty, I think.

 > I'm very much in agreement with any move in this direction.
 >
 > I have a concern which I've heard some people inside Sun speak.  
 > Namely:  Who will be responsible for the quality of these ports?

The maintainers of those ports.  Who else could possibly do it?  Other
people may not even have the hardware.

 > At the meeting we held at FOSDEM I remember the lecture we had in
 > the operation of the GCC project and how they go about supporting
 > lots of CPU architecture and OS platform combinations.  On the one
 > hand I think the OpenJDK has the potential to have that same
 > breadth of platform support.  But if it's at the cost of the Sun
 > quality engineering team it will not work.
 >
 > I think hosting a project like this has to be coupled with a plan
 > for maintaining quality in that project.

Why is this any different from any other free software project?  The
maintainers of each target will make sure it gets built and tested.

If the XYZ port of OpenJDK doesn't work, then that's a bug against the
XYZ port, and the XYZ maintainers will have to fix it.  If the XYZ
port isn't being properly maintained it will be deleted from the
source tree.

If the maintainers are good, so will their port be; if not, it won't.
If OpenJDK is really to be open it has to be a *distributed* effort,
with porting, testing, and support done by independent workers.  The
Sun QE team can't so do it.

And yes, there will be bad ports out there.  But you can't stop that:
it's free software.  The question is whether to ignore the bad ports
or try to bring them inside the fold to help the maintainers turn them
into good ports.

Andrew.

--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Kurt Miller-3]

Dalibor Topic wrote:

> Kurt Miller wrote:
>> Myself and Jung-uk Kim have completed making the plugin 64-bit
>> clean for the 1.6 JRL licensed plugin. You can find our work in patchset
>> 2 for BSD:
>>
>> http://www.eyesbeyond.com/freebsddom/java/JDK16JRLConfirm.html
>>  
> On an unrelated note, would it make sense to create infrastructure for
> the porting projects inside OpenJDK? I am wondering if we shouldn't
> create an official 'porters' group, with projects for ports to *BSD, etc.
>
> While Sun may not be interested in merging in all such ports into the
> main OpenJDK tree, it could be useful to have the patch sets maintained
> centrally as part of the OpenJDK infrastructure. The distributed mercurial
> setup could give us that liberty, I think.

Yes the *BSD porting team would like to have our work incorporated
upstream at Sun. If it must be keep in separate branch at first
or for longer term that is ok too.

I'm not familiar with mercurial at all. We've been using cvs. The
JDK src is imported into vendor branches, changes are made to
support the BSD's and then patchsets are cut by doing diffs
against the original src in the vendor branch. In the end we
need either a patchset off official Sun sources or a complete
source distribution that includes our changes. So long as
mercurial can accomplish those needs it would work for us.

Regarding the questions about quality: At least compatibility
can be maintained if the JavaTest Harness, the JCK tests and
documentation are available to the members of the porters
group. I think people are going to be surprised at how well
Java support on BSD's measures up - especially OpenBSD and FreeBSD
which has the most active participants.

Regards,
-Kurt

[Mark Wielaard]

Hi Massimo,

On Mon, 2007-10-29 at 12:51 +0000, Massimo Perga wrote:
>   I'm writing here to know what's the best process to follow in order to have more informations on such a plug-in.
> I'm not requesting it... rather, I'm *offering* to port the current 32-bit Linux version to a native 64-bit version.
> To accomplish this task, which is the project that takes care of such a plug-in ? Otherwise, have I to request a new project ?

You might want to try the plugin from IcedTea which is based on OpenJDK
and gcjwebplugin. It works great for me on x86 and x86_64. See
http://icedtea.classpath.org/ it should also be packaged for the latest
Fedora (8) and Ubuntu (Gutsy) releases. Most discussion about it is done
on the GNU/Linux distro package list:
http://mail.openjdk.java.net/mailman/listinfo/distro-pkg-dev

Cheers,

Mark

[Mark Reinhold]

> Date: Mon, 29 Oct 2007 18:15:21 +0000
> From: Andrew Haley <aph@...>

> ...
>
> Why is this any different from any other free software project?  The
> maintainers of each target will make sure it gets built and tested.
>
> If the XYZ port of OpenJDK doesn't work, then that's a bug against the
> XYZ port, and the XYZ maintainers will have to fix it.  If the XYZ
> port isn't being properly maintained it will be deleted from the
> source tree.
>
> If the maintainers are good, so will their port be; if not, it won't.
> If OpenJDK is really to be open it has to be a *distributed* effort,
> with porting, testing, and support done by independent workers.  The
> Sun QE team can't so do it.

Exactly so.

I completely agree that there needs to be a way for ports other than
those supported directly by Sun to become part of the main JDK 7 (and 6)
source trees in OpenJDK.  We'll need to figure out how to identify them
as such, and what the policy is for deleting inactive or broken ports,
but there are plenty of good examples (e.g., the GCC project) from which
to learn.

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

- Mark

[Dalibor Topic]

Volker Simonis wrote:
> PS: perhaps it would make sense to start a new thread for this topic
> as it has nothing more to do with Mozilla plugins for AMD64?

Yeah, let's continue under the maintaining ports thread.

cheers,
dalibor topic

[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

[Dalibor Topic]

Kurt Miller wrote:
> Yes the *BSD porting team would like to have our work incorporated
> upstream at Sun. If it must be keep in separate branch at first
> or for longer term that is ok too.
>
>  
Great, we're all on the same page, I think.
> I'm not familiar with mercurial at all. We've been using cvs. The
> JDK src is imported into vendor branches, changes are made to
> support the BSD's and then patchsets are cut by doing diffs
> against the original src in the vendor branch. In the end we
> need either a patchset off official Sun sources or a complete
> source distribution that includes our changes. So long as
> mercurial can accomplish those needs it would work for us.
>  
I've CC:ed Mark Wielaard on this to see if what we are doing on the
icedtea mercurial repository is similar.
I hope he can provide some insight, he mentioned "mercurial queues" on
IRC after being poked
around by me. :)

cheers,
dalibor topic

[Mark Wielaard]

Hi Dalibor, Hi Kurt,

On Wed, 2007-10-31 at 16:02 +0100, Dalibor Topic wrote:

> Kurt Miller wrote:
> > I'm not familiar with mercurial at all. We've been using cvs. The
> > JDK src is imported into vendor branches, changes are made to
> > support the BSD's and then patchsets are cut by doing diffs
> > against the original src in the vendor branch. In the end we
> > need either a patchset off official Sun sources or a complete
> > source distribution that includes our changes. So long as
> > mercurial can accomplish those needs it would work for us.
> >  
> I've CC:ed Mark Wielaard on this to see if what we are doing on the
> icedtea mercurial repository is similar.
> I hope he can provide some insight, he mentioned "mercurial queues" on
> IRC after being poked
> around by me. :)

Actually I said we aren't doing it yet for IcedTea :) But we really
should when the switch to mercurial is completed.

Mercurial Queues is pretty nice for keeping patch sets on top of an
upstream mercurial repo. You can even keep and publish the patchsets in
their own mercurial repo so you can collaboratively work on them. You
pull your patches when you refresh the mercurial tree from upstream and
then push them again to rebase. MQ knows about the whole mercurial way
of managing files so it is as if you are working on the actual tree
while still keeping your patchsets separate. There is some very nice
documentation about it at: http://hgbook.red-bean.com/hgbookch12.html
"Managing change with Mercurial Queues" from "Distributed revision
control with Mercurial" by Bryan O'Sullivan which is highly recommended.

Cheers,

Mark

[Dalibor Topic]

Mark Wielaard wrote:

> Hi Dalibor, Hi Kurt,
>
> On Wed, 2007-10-31 at 16:02 +0100, Dalibor Topic wrote:
>  
>> Kurt Miller wrote:
>>    
>>> I'm not familiar with mercurial at all. We've been using cvs. The
>>> JDK src is imported into vendor branches, changes are made to
>>> support the BSD's and then patchsets are cut by doing diffs
>>> against the original src in the vendor branch. In the end we
>>> need either a patchset off official Sun sources or a complete
>>> source distribution that includes our changes. So long as
>>> mercurial can accomplish those needs it would work for us.
>>>  
>>>      
>> I've CC:ed Mark Wielaard on this to see if what we are doing on the
>> icedtea mercurial repository is similar.
>> I hope he can provide some insight, he mentioned "mercurial queues" on
>> IRC after being poked
>> around by me. :)
>>    
>
> Actually I said we aren't doing it yet for IcedTea :) But we really
> should when the switch to mercurial is completed.
>
> Mercurial Queues is pretty nice for keeping patch sets on top of an
> upstream mercurial repo. You can even keep and publish the patchsets in
> their own mercurial repo so you can collaboratively work on them. You
> pull your patches when you refresh the mercurial tree from upstream and
> then push them again to rebase. MQ knows about the whole mercurial way
> of managing files so it is as if you are working on the actual tree
> while still keeping your patchsets separate. There is some very nice
> documentation about it at: http://hgbook.red-bean.com/hgbookch12.html
> "Managing change with Mercurial Queues" from "Distributed revision
> control with Mercurial" by Bryan O'Sullivan which is highly recommended.
>
>  

thank you very much, Mark!

cheers,
dalibor topic

[Kurt Miller-3]

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

[Dalibor Topic]

Kurt Miller wrote:

> If there was general porters group but a separate project for the BSD's
> that might would work too.

It probably didn't came out as I wanted it, but yeah, the idea I'm
toying around with is having a group for porters, and having separate
projects for each port (bsd, icedtea [1], ...) with different source
repositories as part of that group.

Since the current processes are focused around Members, and Members are
instantiated by Groups, rather than Projects, for bootstrapping purposes
we need some group that can handle member 'creation' for porting
projects. We can have one such group, or we can have multiple groups,
one for each porting project.

Alternatively, we could rely on the contributions of potential members
to porting projects to existing projects to become eventually
significant enough for existing groups to let them in, and grant them
membership status.

I'm not quite enthusiastic about that option, because it requires
potential members to porting projects to first gain credibility doing
something else, before they are allowed to be members of a porting project.

cheers,
dalibor topic

[1] ... for a convenient definition of 'port'.

[Kurt Miller-3]

Sorry for the delayed reply...

Dalibor Topic wrote:

> Kurt Miller wrote:
>
>> If there was general porters group but a separate project for the BSD's
>> that might would work too.
>
> It probably didn't came out as I wanted it, but yeah, the idea I'm
> toying around with is having a group for porters, and having separate
> projects for each port (bsd, icedtea [1], ...) with different source
> repositories as part of that group.
>
> Since the current processes are focused around Members, and Members are
> instantiated by Groups, rather than Projects, for bootstrapping purposes
> we need some group that can handle member 'creation' for porting
> projects. We can have one such group, or we can have multiple groups,
> one for each porting project.

Ahh ok I understand now. Either way works and is fine for the BSD port.
Whatever you and the other existing Members/Groups decide is fine.

> Alternatively, we could rely on the contributions of potential members
> to porting projects to existing projects to become eventually
> significant enough for existing groups to let them in, and grant them
> membership status.
>
> I'm not quite enthusiastic about that option, because it requires
> potential members to porting projects to first gain credibility doing
> something else, before they are allowed to be members of a porting project.

Indeed. That would raise the barriers for new ports to be very high
I would think.

Regards,
-Kurt

[Mark Reinhold]

I'm now convinced that, contrary to my earlier musings, a Porters Group
is a good idea.  It can serve as a coordination point for all in-progress
porting efforts as well as a way for people working on such ports to gain
experience and eventually become Members of the OpenJDK Community.

As Dalibor said, it probably makes the most sense for each porting effort
to have its own Project so that, e.g., more advanced ports such as BSD
can keep their work separate from newer, more experimental ports (VMS?).

I expect that the long-term goal of any more serious porting effort will
be to integrate into one of the mainline JDK code bases.  At that point
its corresponding Project would be archived, and further work on the port
would happen in the mainline.

So who'd like to propose a Porters Group?  Dalibor?

- Mark

[Dalibor Topic]

Mark Reinhold wrote:
> I expect that the long-term goal of any more serious porting effort will
> be to integrate into one of the mainline JDK code bases.  At that point
> its corresponding Project would be archived, and further work on the port
> would happen in the mainline.

That'd be perfect.

> So who'd like to propose a Porters Group?  Dalibor?

It would be a pleasure.

I'll work with Greg and Kurt on a proposal, and would be glad to serve
as the group's initial moderator for the time being.

Meanwhile, we'll need (at least) two more existing members to join me as
initial Porters Group members .. so please reply to this post, if you
are interested in being an initial member of the group, or send me an
e-mail off-list.

cheers,
dalibor topic