OpenWebStart and IcedTea-Web
Jiri Vanek
jvanek at redhat.com
Tue Mar 26 16:27:32 UTC 2019
On 3/26/19 9:08 AM, Michael Heinrichs wrote:
> Hi Jiri,
>
> Yes, there is only one code base at this point. But we are currently evaluating if it makes more sense for us to join ITW or create something new/fork ITW. There are pros and cons for both sides.
>
> I cannot really tell you right now how the native part and the Java part can be split. Our engineers are doing a two day workshop this week where they try to find good answers to these questions among others. Stay tuned! :)
Lets watch it:) ITW can become downstream of yours at the end...
>
> Sorry for not being clear. When I wrote modules, I meant Maven modules. Our plan is to bundle OpenWebStart with a JRE in native installers, which would make us more flexibel in terms of which Java version we want to use. But the first version will probably run on Java 8 anyway.
ok. Multi jdk support is both advantage and pitfall of ITW.
>
> What is the policy of the ITW repo? Are you the only committer and people created pull requests? I guess this process will not work anymore unless you are willing to do nothing more but pull request reviews during the next couple of months. ;) How shall we setup the process?
There was about 20 commiters/reviwers on classapth servers I knew about, and aprox 100 I was not
aware about. Unluckily all are inactive now. Anyway, we moved to new repo, so those are no longer
valid, nor the workflow, nor the policies.
I definitely can not stay single commiter/reviwer. That would kill both me and ITW. I'm definitely
going to eyball all commits in next few weeks, but I may be of for day or so, and I do not wont it
to stay and wait. I can always speak my mind after merge, and you do not need to listen. Nor I can
catch all, nor can I be the single stop show voice.
I guess all your fultimers on ITW should get commit review permissions right now, but all changes
should go through PR, so other interested vocies can comment. Geerally untill there is anti voice,
the PR should (SHOULD!) not be merged.
We are currently setting the process up. Lets it be square usable. My only note to it really is,
that every change should go via PR, and your full timers shoudl get push/merge access.
TYVM!
J.
More information about the distro-pkg-dev
mailing list