Agreed. -----Original Message----- From: Phil Race [mailto:[email protected]] Sent: Donnerstag, 3. Dezember 2015 19:39 To: Markus KARG; [email protected] Subject: Re: Future of JavaFX
As Kevin already said, you won't get anywhere by discussing that on *this* list. It is out of the control of JavaFX. It is an OpenJDK-wide policy regarding the bug tracker. You would need to take it to openjdk-discuss since it is common across all OpenJDK projects. And there is some work in progress the submission easier and to provide means to add updates. I think that may have been shared in a previous thread on this or some other list. -phil. On 12/3/2015 10:31 AM, Markus KARG wrote: > +1 > > It simply must be possibly for *everyone* to open tickets, comment on > tickets, vote for tickets, without signing a CLA. We simply could have bylaws > that say that you agree to the CLA simply by using the tracker. In Germany > for example, this is possible by posting the licence agreement on the same > web site and the words "By using this service you agree to this terms.". > > The must be people in charge reviewing small contributions and directly tell > in the comments field what exactly is needed to be accepted as a contribution. > > Everything else will hold people back from contributing small contributions > or even report bugs. > > -Markus > > -----Original Message----- > From: openjfx-dev [mailto:[email protected]] On > Behalf Of Mark Fortner > Sent: Donnerstag, 3. Dezember 2015 00:12 > To: Florian Brunner > Cc: [email protected] > Subject: Re: Future of JavaFX > > I think the first hurdle is to get people to sign the CLA. Having to > print a copy, sign it, and find a fax machine or scanner to resend it > seems kind of archaic in this day and age. That said, e-signing a PDF > shouldn't be too difficult, but it would be better if it were simply a > form that you attached your public key to. This would serve 2 > purposes: (1) you have a proxy for a signature, (2) the key could be used to > access the repo. > > That said, even that might be too much for people who just have a > quick bug fix that they'd like to see reviewed and merged. > > Cheers, > > Mark > > > On Wed, Dec 2, 2015 at 4:43 PM, Florian Brunner <[email protected]> wrote: > >> 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 <[email protected]> >> 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:[email protected]] >>>> Sent: Dienstag, 1. Dezember 2015 23:05 >>>> To: Markus KARG >>>> Cc: [email protected] >>>> 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 >>>> <[email protected]> >>>> 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:[email protected]] >>>> Sent: Dienstag, 1. Dezember 2015 20:19 >>>> To: Markus KARG >>>> Cc: [email protected] >>>> 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 <[email protected]> >> 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:[email protected]] On >>>> Behalf Of >>>> >>>>> dalibor topic >>>>> Sent: Dienstag, 1. Dezember 2015 19:06 >>>>> To: [email protected] >>>>> 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 >>
