Future of JavaFX
Florian Brunner
fbrunnerlist at gmx.ch
Wed Dec 2 23:50:07 UTC 2015
I think actually the 2nd point (State-of-the-art code collaboration platform)
is not comfortable enough how I described it.
Firstly, it should be a CI server, not a person, who synchronizes the
repositories whenever there is a change on a non-feature branch of the main
repository.
Secondly, try to work with pull requests
For this to work in such an environment the collaborations platform needs the
following features, I think:
- restrict write access to the non-feature branchens (in Gitflow based Git
repositories these are usually at least the "master" and "develop" branch),
Only the CI server (or maybe the platform) should have write access to these
branches, but no developer.
- provide the possibility to define a reviewer group and set up a rule that at
least one member of this reviewer group needs to approve the pull request
- the reviewer should get an email (push notfication) whenever there is a new
pull request or whenever a pull request changed
At least for Git, Atlassian Stash can provide such features, AFAIK. Maybe
BitBucket does provide some similar features for Mercurial repositories?
If such a collaboration platform can be established/ configured it should even
be possible to set-up another CI server job for 2 way synchronization, as it
can be made sure everything has been reviewed by an accepted reviewer.
-Florian
Am Mittwoch, 2. Dezember 2015, 23.43:44 schrieb Florian Brunner:
> Some time ago there actaully was a OpenJFX mirror repository on BitBucket.
>
> I'm not totally sure anymore why this was stopped. I think it needs someone
> who keeps the repositories in sync and there were some concerns that it's
> harder to control who wrote a patch. But maybe the idea with CLA signers
> only members would solve this issue?
>
> So I see 3 pain points being raised.
>
> 1. Signing the CLA.
> - Personally, I don't see any way around this. If there is no CLA then you
> end up with a project _nobody_ is in control of.
> - Basically it envolves the following steps:
> -- Download it from the website
> -- print it
> -- sign it
> -- send it off
> -- you only have to do this once
> -- you don't have to wait for Oracle to receive it to start working
> on the issue you like to solve
>
> Can this be presented in a way it doesn't scare people away as according
> to some statements it seems to do now?
>
> 2. State-of-the-art code collaboration platform.
> -- This would have to be something like GitHub or BitBucket
> -- Only CLA signers can be members of the project
> -- Someone has to be in charge to synchronize the repositories
> (probably one way only)
> -- personally I like to work with feature branches in Git but I
> think you can get something similar with Mercurial bookmarks. So
> --- pick an issue you would like to work on
> --- consider to announce it on this mailing list
> --- create a feature branch
> --- start pushing your changes to the feature branch
> --- other developers of the projects (all CLA signers) might chime
> in as they like
> --- once you think you're finished create a patch from the feature
> branch and add it to the issue or (if you don't have enough rights) send it
> to the mailing list
> --- take the feedback from the review, do the fixes an create another
> patch etc.
>
> So the main benefit would be that several developers could work on the same
> issue until it gets to a high enough qualiy state to be merged into the main
> repository and not requiring one developer to do it all on his/ her own.
>
>
> 3. Filing and commenting on issues
> - if you don't have enough rights, file it on bugs.java.com
> - ask on this mailing list (or ask someone you know on this mailing list
> to do it for you) about the corresponding issue on bugs.openjdk.java.net -
> someone from Oracle should give anyone who filed an issue that made it to
> bugs.openjdk.java.net the enough rights so he/ she can join on the
> discussion in the issue
>
> Any better way?
>
>
> -Florian
>
> Am Dienstag, 1. Dezember 2015, 17.16:46 schrieb Tomas Mikula:
> > The proposed strategy also applies to bitbucket, which does have mercurial
> > support ;)
> >
> > On Tue, Dec 1, 2015 at 5:12 PM, Markus KARG <markus at headcrashing.eu>
wrote:
> > > Too bad that Github cannot fork mercurial repos. It would be interesting
> > > to see the real number of pull requests such a fork would gain. Maybe
> > > Dalibor is right and we would end up with zero? ;-)
> > >
> > > -Markus
> > >
> > >
> > >
> > > From: Tomas Mikula [mailto:tomas.mikula at gmail.com]
> > > Sent: Dienstag, 1. Dezember 2015 23:05
> > > To: Markus KARG
> > > Cc: openjfx-dev at openjdk.java.net
> > > Subject: Re: Future of JavaFX
> > >
> > >
> > >
> > > The review process for external contributions does not even have to be
> > > different from the internal review process. There can be a virtual
> > > organization on GitHub called "Oracle CLA signatories". After a pull
> > > request has been reviewed, all that the OpenJFX committer has to do
> > > before
> > > merging is to check whether the contributor is a member of this
> > > organization.
> > >
> > >
> > >
> > > Tomas
> > >
> > >
> > >
> > > On Tue, Dec 1, 2015 at 4:41 PM, Markus KARG <markus at headcrashing.eu>
> > > wrote:
> > >
> > > We should ask ourselfs whether we want more contributions or not. We
> > > will
> > > not get them until we change something. Most contributors in the Open
> > > Source just want to drop a bug report or a feature or two, and
> > > multiplied
> > > by the number of those guys, this is a lot of stuff. Only few
> > > contributors
> > > are willing to stay for long time, and only for those it makes sense to
> > > have the complex rules. For example, I do not see why we cannot have a
> > > dedicated full time "Community Officer" who simply collects the
> > > contributions, reviews it, applies the needed checks and rules and all
> > > that
> > > instead of asking everybody to follow a complex process? That would
> > > ensure
> > > the quality, but not for the cost of losing contributors.
> > >
> > >
> > > -----Original Message-----
> > > From: Hervé Girod [mailto:herve.girod at gmail.com]
> > > Sent: Dienstag, 1. Dezember 2015 20:19
> > > To: Markus KARG
> > > Cc: openjfx-dev at openjdk.java.net
> > > Subject: Re: Future of JavaFX
> > >
> > > Things are not different for Apache projects. Google does not accept any
> > > external contributions. The Linux kernel development is very tightly
> > > controlled. We should stop considering that widespread open source
> > > policies
> > > are only a problem with JavaFX. These policies are in place for a
> > > reason.
> > >
> > > Hervé
> > >
> > > Sent from my iPhone
> > >
> > > > On Dec 1, 2015, at 20:13, Markus KARG <markus at headcrashing.eu> wrote:
> > > >
> > > > I wonder why I was able to jointly assign my copyright with a lot of
> > >
> > > other
> > >
> > > > open source projects without having to sign papers, sent them in by
> > > > fax,
> > > > wait for a written agreement, and pray to get a JIRA account... ;-)
> > > >
> > > > See, I talked to a real lot of former JavaFX contributors in the past
> > >
> > > weeks
> > >
> > > > (visited some European JUGs in 2015), and *virtually everybody* told
> > > > me
> > >
> > > that
> > >
> > > > he is really unsatisfied with the fact that he cannot directly file to
> > >
> > > JIRA
> > >
> > > > anymore or AT LEAST vote and comment on existing tickets. Is the
> > > > JavaFX
> > >
> > > team
> > >
> > > > clear about how many contributors you lost by that policy? I really
> > >
> > > wonder
> > >
> > > > whether you see the reality there outside of Oracle. People stopped
> > > > reporting bugs! This is a real problem for JavaFX. You should act.
> > > > Now.
> > > >
> > > > -Markus
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On
> > >
> > > Behalf Of
> > >
> > > > dalibor topic
> > > > Sent: Dienstag, 1. Dezember 2015 19:06
> > > > To: openjfx-dev at openjdk.java.net
> > > > Subject: Re: Future of JavaFX
> > > >
> > > >> On 01.12.2015 18:35, Markus KARG wrote:
> > > >> With respect to TeamFX, the better question is: Are there plans to
> > >
> > > further
> > >
> > > >> open the project so third party has an easier channel to contribute
> > > >
> > > > without
> > > >
> > > >> the hazzle of contributor agreements
> > > >
> > > > "Like many other open-source communities, the OpenJDK Community
> > > > requires
> > > > Contributors to jointly assign their copyright on contributed code."
> > > > as
> > > > http://openjdk.java.net/contribute/ wisely says.
> > > >
> > > > There is no good reason to change that.
> > > >
> > > > cheers,
> > > > dalibor topic
> > > > --
> > > > <http://www.oracle.com> Dalibor Topic | Principal Product Manager
> > > > Phone: +494089091214 <tel:%2B494089091214> <tel:+494089091214
> > >
> > > <tel:%2B494089091214> > | Mobile: +491737185961 <tel:%2B491737185961>
> > >
> > > > <tel:+491737185961 <tel:%2B491737185961> >
> > > >
> > > > ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
> > > >
> > > > ORACLE Deutschland B.V. & Co. KG
> > > > Hauptverwaltung: Riesstr. 25, D-80992 München
> > > > Registergericht: Amtsgericht München, HRA 95603
> > > >
> > > > Komplementärin: ORACLE Deutschland Verwaltung B.V.
> > > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> > > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> > > > Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
> > > >
> > > > <http://www.oracle.com/commitment> Oracle is committed to developing
> > > > practices and products that help protect the environment
More information about the openjfx-dev
mailing list