I have coded such a framework in one of my open source projects. I can extract this code and setup a github project for it if people are interested.
Hervé Sent from my iPhone > On Feb 7, 2018, at 10:52, John-Val Rose <johnvalr...@gmail.com> wrote: > > <rant> > > Well, not only do I think that a docking framework is *that* complex, I see > it as an essential part of any serious graphics toolkit. > > In general, I don’t understand all the limitations that people keep imposing > on JavaFX as if we have to “settle” for what is basically a 2nd class citizen > compared with toolkits in other languages. > > Why can’t we just make JavaFX so compelling that developers from other > languages are enticed by the feature set itself? There is no reason (other > than a lack of effort) why JavaFX cannot be on par with Qt or Xamarin in > terms of features, performance, tooling and adoption. > > Am I the only one that believes the world’s most popular and amazing > programming language, platform and the JVM deserves a first class graphics > toolkit? > > I understand the constraints imposed on Oracle staff but isn’t there anyone > else out there in the community who shares my vision for JavaFX? > > It seems the general attitude is that JavaFX just needs to be a “better > Swing”. > > Forget about this nonsense of “thinking outside the box”. > > There is NO BOX! > > JavaFX can and should be the best that we as a community can make it. > > And then we just keep making it better... > > If we don’t adopt such a vision and attitude then what is the point of doing > anything at all? Just leave JavaFX to rot into oblivion and relegate Java to > a server-side language only. > > </rant> > >> On 7 Feb 2018, at 19:25, Tom Eugelink <t...@tbee.org> wrote: >> >> Well, I believe he was hinting at that a docking framework is considered >> more complex, there was no negative sentiment in that. Although I do not >> think a docking framework is that complex, but maybe I'm wrong. >> >> And yes, ALMOST everyone is at ControlFX ;-) >> >> >> >>> Jonathan - why do you *cough* at ideas like more complex controls and >>> docking frameworks? >>> >>> I think that a docking framework especially would be a great addition to >>> JavaFX. >>> >>> Am I missing something? >>> >>>> On 7 Feb 2018, at 18:16, Jonathan Giles <jonat...@jonathangiles.net> >>>> wrote: >>>> >>>> Obviously everyone is at ControlsFX instead ;-) >>>> >>>> Part of the drop I would suggest is simply that many of the itches >>>> people >>>> want to scratch are now scratched. Alternatively, the remaining itches >>>> are >>>> either in more complex controls (*cough* docking frameworks *cough*) or >>>> in >>>> areas beneath the controls APIs - performance, webview, etc - which are >>>> more challenging and require greater levels of dedication. >>>> >>>> However, more generally, your point is well made - contribution to >>>> JavaFX >>>> does not need to be synonymous with contribution to OpenJFX. People who >>>> find the challenges of the current OpenJFX requirements too great should >>>> be >>>> encouraged to involve themselves in projects such as JFXtras, etc. >>>> >>>> -- Jonathan >>>> >>>>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink <t...@tbee.org> wrote: >>>>> >>>>> Many years ago I had a discussion with Jonathan Giles about if the >>>>> things >>>>> that were being made in JFXtras would eventually become part of the >>>>> JavaFX >>>>> core. In the end I decided that, for me personally, I could do the >>>>> things I >>>>> wanted to perfectly in a separate project. The rigid structure that >>>>> Java(FX) has to adhere to, would be a big downside. >>>>> >>>>> What I want to say with that is that all the external projects are also >>>>> contributions to JavaFX. It does not matter whether for example a >>>>> control >>>>> is part of the core distribution or of a side project; it is just >>>>> another >>>>> module users can add to the mix. >>>>> >>>>> So reflecting back I still stand by that choice. But having a few more >>>>> people in the project (just like in JavaFX ;-) ) would be nice, but >>>>> OTOH it >>>>> forces me to deal with (and learn about) annoying stuff like Gradle >>>>> build >>>>> scripts and Java 9 migration. But because of that progress is not as >>>>> fast >>>>> as I would like it to be. Could it be that there is a decline in people >>>>> willing to work for open source projects? Or is it just that this tech, >>>>> JavaFX, is no longer appealing? >>>>> >>>>> Tom >>>>> >>>>> >>>>> >>>> Obviously everyone is at ControlsFX instead ;-) >>>> >>>> Part of the drop I would suggest is simply that many of the itches >>>> people >>>> want to scratch are now scratched. Alternatively, the remaining itches >>>> are >>>> either in more complex controls (*cough* docking frameworks *cough*) or >>>> in >>>> areas beneath the controls APIs - performance, webview, etc - which are >>>> more challenging and require greater levels of dedication. >>>> >>>> However, more generally, your point is well made - contribution to >>>> JavaFX >>>> does not need to be synonymous with contribution to OpenJFX. People who >>>> find the challenges of the current OpenJFX requirements too great should >>>> be >>>> encouraged to involve themselves in projects such as JFXtras, etc. >>>> >>>> -- Jonathan >>>> >>>>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink <t...@tbee.org> wrote: >>>>> >>>>> Many years ago I had a discussion with Jonathan Giles about if the >>>>> things >>>>> that were being made in JFXtras would eventually become part of the >>>>> JavaFX >>>>> core. In the end I decided that, for me personally, I could do the >>>>> things I >>>>> wanted to perfectly in a separate project. The rigid structure that >>>>> Java(FX) has to adhere to, would be a big downside. >>>>> >>>>> What I want to say with that is that all the external projects are also >>>>> contributions to JavaFX. It does not matter whether for example a >>>>> control >>>>> is part of the core distribution or of a side project; it is just >>>>> another >>>>> module users can add to the mix. >>>>> >>>>> So reflecting back I still stand by that choice. But having a few more >>>>> people in the project (just like in JavaFX ;-) ) would be nice, but >>>>> OTOH it >>>>> forces me to deal with (and learn about) annoying stuff like Gradle >>>>> build >>>>> scripts and Java 9 migration. But because of that progress is not as >>>>> fast >>>>> as I would like it to be. Could it be that there is a decline in people >>>>> willing to work for open source projects? Or is it just that this tech, >>>>> JavaFX, is no longer appealing? >>>>> >>>>> Tom >>>>> >>>>> >>>>> >>>>>> On 7-2-2018 03:16, Kevin Rushforth wrote: >>>>>> >>>>>> I would recommend against having a separate issue tracker or mailing >>>>>> list >>>>>> associated with the sandbox. That will create more confusion than any >>>>>> benefit you might have. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Nir Lisker wrote: >>>>>> >>>>>>> Another thing to be careful about with the sandbox/staging idea is >>>>>>> the >>>>>>> confusion that will arise with duplication. There will be 2 issue >>>>>>> trackers >>>>>>> (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and >>>>>>> maybe 2 >>>>>>> discussion lists. For those "in the know" this will be a simple >>>>>>> matter, but >>>>>>> for a potential contributor this can be a gamebreaker if not handled >>>>>>> appropriately. >>>>>>> >>>>>>> Dalibor Topic's suggestion of contacting other mirrors can be >>>>>>> instrumental in solving these problems. >>>>>>> >>>>>>> - Nir >>>>>>> >>>>>>> On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth < >>>>>>> kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>> >>>>>>> wrote: >>>>>>> >>>>>>> Yes, this sounds like a good step in the right direction. This >>>>>>> would give anyone (with a signed OCA) the ability to create their >>>>>>> own branch, commit changes to it, submit a PR, etc. >>>>>>> >>>>>>> I presume there will be a branch that is an exact mirror of the >>>>>>> jfx-dev repo on OpenJDK in addition to the development branch in >>>>>>> the sandbox? >>>>>>> >>>>>>> The only thing to consider is whether it should be Committers or >>>>>>> Reviewers that have rights to merge into the sandbox development >>>>>>> branch. There are pros / cons of each. I'd probably lean towards >>>>>>> having it be Committers, with the idea that a Committer needs to >>>>>>> sponsor the patch anyway and would then be able to "take it the >>>>>>> rest of the way". The only downside I see is that you could end up >>>>>>> with a few patches that get accepted into the sandbox dev branch, >>>>>>> but never make it to the upstream jfx-dev repo (or not without >>>>>>> significant change). I doubt this will be a big problem in >>>>>>> practice. >>>>>>> >>>>>>> Either way, this could also provide a good alternative to webrev >>>>>>> when reviewing the final changes. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> Johan Vos wrote: >>>>>>> >>>>>>> Hi Michael, >>>>>>> >>>>>>> This proposal is very much in line with my thinking as well. >>>>>>> The problem is not that we don't have a github clone of >>>>>>> OpenJFX. We have a >>>>>>> number of them (e.g. I created >>>>>>> https://github.com/javafxports/jfx-dev >>>>>>> <https://github.com/javafxports/jfx-dev> some >>>>>>> months ago). We just need a single one that is updated >>>>>>> constantly from >>>>>>> mainstream, and standardize on that. Let's call that "sandbox" >>>>>>> (I would be >>>>>>> ok with staging as well, but sandbox is imho more inviting to >>>>>>> people who >>>>>>> want to try something drastic, e.g. support for Vulkan) >>>>>>> >>>>>>> The main issue is how to get contributions, review them, and >>>>>>> eventually >>>>>>> send them upstream. >>>>>>> >>>>>>> The PR review process is extremely important. If we lower that >>>>>>> bar, we >>>>>>> loose quality. If the bar is too high, great PR's won't be >>>>>>> accepted >>>>>>> upstream as there is not enough review time to review it. >>>>>>> >>>>>>> I agree giving the current OpenJFX committers merge rights for >>>>>>> the >>>>>>> "sandbox" repository makes sense. Once a public contribution >>>>>>> is merged by >>>>>>> one of those committers, that same committer can send it >>>>>>> upstream to the >>>>>>> existing OpenJFX repository. Additional checks will be >>>>>>> performed there, >>>>>>> mainly in order to make sure the overall "Feel of Java" is >>>>>>> preserved. To >>>>>>> that purpose, it would help to have a closer alignment with >>>>>>> the OpenJDK >>>>>>> community. >>>>>>> >>>>>>> We have to be aware that this will increase the workload of >>>>>>> the current >>>>>>> committers and reviewers. That is the price we pay for >>>>>>> standardization. >>>>>>> Rather than everyone creating his own forks of a UI framework >>>>>>> in Java, we >>>>>>> invest a lot in creating a single, generally agreed one. >>>>>>> >>>>>>> So in summary, I'm +1 on a 2-phase approach: "open" commits >>>>>>> allowed in >>>>>>> staging. OpenJFX committers accept PR's (if they are of good >>>>>>> quality) and >>>>>>> prepare upstream commits for OpenJFX. We hope there will be >>>>>>> more >>>>>>> contributors who become committers and reviewers in the medium >>>>>>> term. >>>>>>> >>>>>>> - Johan >>>>>>> >>>>>>> On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen >>>>>>> <mike.en...@gmail.com <mailto:mike.en...@gmail.com>> wrote: >>>>>>> >>>>>>> >>>>>>> Those are great questions, and I think with >>>>>>> Kevin/Oracle/other OpenJFX devs >>>>>>> help we >>>>>>> can figure something out. >>>>>>> >>>>>>> My thinking is that the PR would be reviewed by basically >>>>>>> anyone who has >>>>>>> free time. >>>>>>> I think that, at first, only OpenJFX committers will be >>>>>>> able to merge PRs. >>>>>>> They would >>>>>>> do the final review/merge to the staging repo after it has >>>>>>> been reviewed by >>>>>>> the "wider audience" >>>>>>> which includes people without commit rights (people like >>>>>>> us). Then, as this >>>>>>> thing evolves, >>>>>>> based on the pool of people who are contributing both pull >>>>>>> requests and PR >>>>>>> reviews, >>>>>>> the committers will be able to grant commit privileges to >>>>>>> some people in >>>>>>> that pool. >>>>>>> >>>>>>> I can't think of any way that would make it so the changes >>>>>>> are as likely to >>>>>>> be >>>>>>> merged upstream as possible other than having the current >>>>>>> OpenJFX >>>>>>> committers paving the >>>>>>> way. Hopefully this vision is aligned with Kevin's and >>>>>>> hopefully these >>>>>>> concrete details >>>>>>> can be worked out. >>>>>>> >>>>>>> Regards, >>>>>>> Michael >>>>>>> >>>>>>> On Sun, Feb 4, 2018 at 6:21 PM, Nir Lisker >>>>>>> <nlis...@gmail.com <mailto:nlis...@gmail.com>> wrote: >>>>>>> >>>>>>> >>>>>>> So if a community ran GitHub is used for staging, who >>>>>>> will approve PRs >>>>>>> >>>>>>> for >>>>>>> >>>>>>> the code and the Wiki of the GitHub repo? >>>>>>> >>>>>>> On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen >>>>>>> <mike.en...@gmail.com <mailto:mike.en...@gmail.com>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Great points, Nir. We share the same hopes. I just >>>>>>> wanted to piggy-back >>>>>>> on the >>>>>>> wiki thing: >>>>>>> >>>>>>> " * The Wiki could be open sourced as well (like >>>>>>> other Wikis). I could >>>>>>> definitely update a page or 2 there and so would >>>>>>> other developers as >>>>>>> >>>>>>> they >>>>>>> >>>>>>> gain knowledge. I don't know yet how permissions >>>>>>> for that should be >>>>>>> handled." >>>>>>> >>>>>>> This is another thing that we could use the GitHub >>>>>>> staging repository >>>>>>> >>>>>>> for. >>>>>>> >>>>>>> The staging repository could have a wiki (projects >>>>>>> on GitHub can have >>>>>>> >>>>>>> one) >>>>>>> >>>>>>> that is editable by all, and then maybe once a >>>>>>> month or so someone with >>>>>>> permissions >>>>>>> to edit to official wiki can sync with the new, >>>>>>> reviewed changes (the >>>>>>> once-a-month >>>>>>> time constraint is very flexible). >>>>>>> >>>>>>> I am just trying to explain how the GitHub >>>>>>> repository "one-way mirror" >>>>>>> (potentially linked >>>>>>> with/managed by Adopt an OpenJDK) can act as a >>>>>>> staging ground for all >>>>>>> kinds of contributions to >>>>>>> OpenJFX. >>>>>>> >>>>>>> By the way, I am trying to cleanup the groundwork >>>>>>> I did on getting >>>>>>> Appveyor builds to >>>>>>> run for openjfx, if indeed it is decided to setup >>>>>>> such a staging >>>>>>> repository. You can >>>>>>> see my efforts here: >>>>>>> https://raw.githubusercontent. >>>>>>> >>>>>>> >>>>>>> com/brcolow/openjfx/f1b8978849fc371683b40931c17020421acc0057 >>>>>>> /appveyor.yml >>>>>>> >>>>>>> If the GitHub repository was setup, changes such >>>>>>> as these to add CI >>>>>>> infrastructure would >>>>>>> never be adopted by upstream OpenJFX, but would >>>>>>> allow for developer's to >>>>>>> get good >>>>>>> feedback on test results for all supported >>>>>>> platforms when they open a >>>>>>> >>>>>>> PR. >>>>>>> >>>>>>> Merging a PR >>>>>>> on the public GitHub repository means, in my >>>>>>> opinion, that it is ready >>>>>>> >>>>>>> to >>>>>>> >>>>>>> be opened as >>>>>>> an upstream bug/feature request. Automating the >>>>>>> process with patch sets, >>>>>>> webrevs, formatting/lint >>>>>>> results, etc. would be the most ideal situation >>>>>>> and I would be happy to >>>>>>> contribute to these >>>>>>> efforts. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Michael Ennen >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker >>>>>>> <nlis...@gmail.com <mailto:nlis...@gmail.com>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> As someone who has recently made the climb and >>>>>>> managed to build OpenJFX >>>>>>> with OpenJDK on Win 10 I might have some >>>>>>> relevant input. >>>>>>> >>>>>>> --- Building OpenJFX --- >>>>>>> >>>>>>> * With the recently updated instructions on >>>>>>> the Wiki, building OpenJFX >>>>>>> >>>>>>> is >>>>>>> >>>>>>> not that hard. Having to build OpenJDK for >>>>>>> that was a real headache >>>>>>> because >>>>>>> their instructions and build tools are not up >>>>>>> to date ( >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8194645 >>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8194645>). >>>>>>> * The above doesn't mean that the process >>>>>>> shouldn't be made easier. >>>>>>> Ideally, it would be the as easy as working on >>>>>>> most open source >>>>>>> >>>>>>> projects >>>>>>> >>>>>>> on >>>>>>> Github (not advocating git over hg): clone >>>>>>> into the IDE and start >>>>>>> working; >>>>>>> when a fix is ready, submit a PR. Don't know >>>>>>> if it's technically >>>>>>> >>>>>>> possible >>>>>>> >>>>>>> in this case, but it's a target. >>>>>>> * The repository needs a good cleanup before >>>>>>> contributors start >>>>>>> >>>>>>> cloning ( >>>>>>> >>>>>>> bugs.openjdk.java.net/browse/JDK-8196198 >>>>>>> <http://bugs.openjdk.java.net/browse/JDK-8196198>). >>>>>>> >>>>>>> --- Working on OpenJFX --- >>>>>>> >>>>>>> * It should be clear which tests need to run >>>>>>> for a specific patch. >>>>>>> Changes >>>>>>> can be made anywhere from the documentation >>>>>>> level to native code level >>>>>>> and >>>>>>> there's no reason to run the same tests for >>>>>>> all of these. If the >>>>>>> >>>>>>> process >>>>>>> >>>>>>> can be automate it's even better. >>>>>>> * The Webrev tool seems archaic to me (and >>>>>>> part of its output is broken >>>>>>> as >>>>>>> far as I could tell). An IDE can create diff >>>>>>> patches with a couple of >>>>>>> clicks. >>>>>>> * The Jcheck tool seems archaic to me. It >>>>>>> should be ported to IDE >>>>>>> formatters which are to be distributed with >>>>>>> the source. No reason to >>>>>>> >>>>>>> run >>>>>>> >>>>>>> a >>>>>>> tool that tells me which whitespaces I need to >>>>>>> go back and change when >>>>>>> something like Ctrl+Shift+F in an IDE finishes >>>>>>> the job. >>>>>>> >>>>>>> --- Wiki --- >>>>>>> >>>>>>> * The Wiki could be open sourced as well (like >>>>>>> other Wikis). I could >>>>>>> definitely update a page or 2 there and so >>>>>>> would other developers as >>>>>>> >>>>>>> they >>>>>>> >>>>>>> gain knowledge. I don't know yet how >>>>>>> permissions for that should be >>>>>>> handled. >>>>>>> * Code conventions should be clearly listed. >>>>>>> * Separate sections with instructions should >>>>>>> be made for: (1) cloning >>>>>>> >>>>>>> and >>>>>>> >>>>>>> building, (2) modifying, (3) running tests, >>>>>>> (4) submitting, and (5) >>>>>>> reviewing. >>>>>>> * Old sections should be cleaned up (I don't >>>>>>> think Discussions is >>>>>>> >>>>>>> useful >>>>>>> >>>>>>> anymore). >>>>>>> >>>>>>> --- Review policy --- >>>>>>> >>>>>>> * I have no experience with review policies or >>>>>>> project roles so I can't >>>>>>> help here much (maybe after a discussion >>>>>>> starts). >>>>>>> * One thing I do know is that reviewers should >>>>>>> be extremely >>>>>>> knowledgeable, >>>>>>> which means that there aren't many qualified. >>>>>>> Because of this, if it >>>>>>> becomes "too" easy to contribute to OpenJFX, >>>>>>> careful measures need to >>>>>>> >>>>>>> be >>>>>>> >>>>>>> taken as to not to swamp the few reviewers >>>>>>> with many patches (though >>>>>>> >>>>>>> some >>>>>>> >>>>>>> would say this is an ideal situation). Some >>>>>>> sort of review queue might >>>>>>> help >>>>>>> with organization instead of the current email >>>>>>> system. I have no >>>>>>> >>>>>>> concrete >>>>>>> >>>>>>> solution for this. >>>>>>> >>>>>>> - Nir >>>>>>> >>>>>>> >>>>>>> Message: 1 >>>>>>> >>>>>>> Date: Thu, 01 Feb 2018 15:26:24 -0800 >>>>>>> From: Kevin Rushforth >>>>>>> <kevin.rushfo...@oracle.com >>>>>>> <mailto:kevin.rushfo...@oracle.com>> >>>>>>> To: "openjfx-dev@openjdk.java.net >>>>>>> <mailto:openjfx-dev@openjdk.java.net>" >>>>>>> <openjfx-dev@openjdk.java.net >>>>>>> <mailto:openjfx-dev@openjdk.java.net>> >>>>>>> Subject: More community participation in >>>>>>> JavaFX >>>>>>> Message-ID: <5a73a220.7030...@oracle.com >>>>>>> <mailto:5a73a220.7030...@oracle.com>> >>>>>>> Content-Type: text/plain; >>>>>>> charset=windows-1252; format=flowed >>>>>>> >>>>>>> To: OpenJFX Developers >>>>>>> >>>>>>> We are looking to grow the community of >>>>>>> contributors to the OpenJFX >>>>>>> project, especially serious contributors >>>>>>> who will stick around long >>>>>>> enough to become reviewers, to help us >>>>>>> keep the platform vibrant. To >>>>>>> this end we are looking at ways to >>>>>>> encourage more participation and >>>>>>> >>>>>>> make >>>>>>> >>>>>>> it easier for interested folks to >>>>>>> contribute. >>>>>>> >>>>>>> We are specifically looking to discuss >>>>>>> ideas around the following >>>>>>> >>>>>>> areas: >>>>>>> >>>>>>> * Easing barriers to contribution (e.g., >>>>>>> making JavaFX easier to >>>>>>> >>>>>>> build, >>>>>>> >>>>>>> better documentation, making it easier to >>>>>>> test changes) >>>>>>> >>>>>>> * Code review policies >>>>>>> >>>>>>> * API / feature review policies >>>>>>> >>>>>>> * Code review tools (we currently use >>>>>>> webrev, but that isn't set in >>>>>>> >>>>>>> stone) >>>>>>> >>>>>>> To keep this thread productive, the >>>>>>> following are explicitly out of >>>>>>> >>>>>>> scope: >>>>>>> >>>>>>> * Discussion of specific features or bugs >>>>>>> that you would like to >>>>>>> implement (or wish someone else would) >>>>>>> >>>>>>> * Discussion about platform support >>>>>>> >>>>>>> * Discussion about version control systems >>>>>>> (e.g., hg versus git), >>>>>>> hosting of the OpenJFX repos and bug >>>>>>> database (e.g., OpenJDK versus >>>>>>> github), etc...at least for now. We are >>>>>>> aware of the potential >>>>>>> >>>>>>> benefits >>>>>>> >>>>>>> of such changes, but we'd like to focus >>>>>>> our efforts on >>>>>>> >>>>>>> higher-leverage >>>>>>> >>>>>>> things we can do in the short term. >>>>>>> >>>>>>> * Discussion about the requirement of a >>>>>>> signed OCA to become a >>>>>>> >>>>>>> contributor >>>>>>> >>>>>>> * Off-topic or tangential commentary about >>>>>>> OpenJFX that isn't >>>>>>> >>>>>>> directly >>>>>>> >>>>>>> related to the topic at hand >>>>>>> >>>>>>> >>>>>>> As a starting point for discussion, here >>>>>>> are some areas I think need >>>>>>> improvement; I'm sure there are others: >>>>>>> >>>>>>> I. Helping contributors get started >>>>>>> >>>>>>> It isn?t as easy to get started with >>>>>>> OpenJFX as it should be. We want >>>>>>> >>>>>>> to >>>>>>> >>>>>>> make it easier for potential OpenJFX >>>>>>> contributors to get started. >>>>>>> >>>>>>> Here >>>>>>> >>>>>>> are some ideas that I think might help: >>>>>>> >>>>>>> * Improve the build instructions / Wiki (I >>>>>>> made a first start, but >>>>>>> >>>>>>> there >>>>>>> >>>>>>> is much more to be done) >>>>>>> >>>>>>> * Make the build itself more resilient >>>>>>> where possible, and provide >>>>>>> better error messages, specifically when >>>>>>> dealing with native >>>>>>> >>>>>>> compilers >>>>>>> >>>>>>> and libraries >>>>>>> >>>>>>> * Add an option to skip building all >>>>>>> native code and use prebuilt >>>>>>> binaries (like we do already for media and >>>>>>> webkit); this is tracked >>>>>>> >>>>>>> by >>>>>>> >>>>>>> JDK-8092279, but it hasn?t been looked at >>>>>>> recently >>>>>>> >>>>>>> * Make it easier to build / test your >>>>>>> local OpenJFX build using an >>>>>>> OpenJDK build (currently the only way to >>>>>>> do this is to build OpenJDK >>>>>>> locally, after using configure to point to >>>>>>> your just-built javafx.* >>>>>>> modules). >>>>>>> >>>>>>> * Provide step-by-step instructions for >>>>>>> how to make a contribution, >>>>>>> including testing requirements; a lot of >>>>>>> the pieces are there, but >>>>>>> >>>>>>> are >>>>>>> >>>>>>> out of date or scattered in several >>>>>>> places. As part of this, we could >>>>>>> have a section on how to contribute docs, >>>>>>> samples or tests, since >>>>>>> >>>>>>> that >>>>>>> >>>>>>> is often a good place to start. >>>>>>> >>>>>>> * Provide a sandbox environment where >>>>>>> contributors can discuss and >>>>>>> >>>>>>> test >>>>>>> >>>>>>> ideas. For example, an OpenJFX mirror on >>>>>>> github, potentially >>>>>>> >>>>>>> connected >>>>>>> >>>>>>> to AdoptOpenJDK. >>>>>>> >>>>>>> >>>>>>> II. Code reviews and API reviews >>>>>>> >>>>>>> Code reviews are important to maintain >>>>>>> high-quality contributions, >>>>>>> >>>>>>> but >>>>>>> >>>>>>> we recognize that not every type of change >>>>>>> needs the same level of >>>>>>> review. Without lowering our standards of >>>>>>> quality, we want to make it >>>>>>> easier to get low-impact changes (simple >>>>>>> bug fixes) accepted. >>>>>>> >>>>>>> There are three categories of changes, >>>>>>> each of which might merit a >>>>>>> different review standard: >>>>>>> >>>>>>> 1. Low-impact bug fixes. These are >>>>>>> typically isolated bug fixes with >>>>>>> little or no impact beyond fixing the bug >>>>>>> in question; included in >>>>>>> >>>>>>> this >>>>>>> >>>>>>> category are test fixes (including new >>>>>>> tests) doc fixes, and fixes to >>>>>>> sample applications (including new >>>>>>> samples). >>>>>>> >>>>>>> 2. Higher impact bug fixes or RFEs. These >>>>>>> include changes to the >>>>>>> implementation that potentially have a >>>>>>> performance or behavioral >>>>>>> >>>>>>> impact, >>>>>>> >>>>>>> or are otherwise broad in scope. Some >>>>>>> larger bug fixes will fall into >>>>>>> this category, as will fixes in high-risk >>>>>>> areas (e.g., CSS). >>>>>>> >>>>>>> 3. New features / API additions. In >>>>>>> addition to reviewing the >>>>>>> implementation, we will need a separate >>>>>>> approval process for the new >>>>>>> >>>>>>> API >>>>>>> >>>>>>> / feature (such as the CSR, which is what >>>>>>> we use now, or a similar >>>>>>> process). >>>>>>> >>>>>>> We take compatibility seriously, so >>>>>>> anything that adds new API needs >>>>>>> >>>>>>> to >>>>>>> >>>>>>> be done with an eye towards supporting it >>>>>>> for at least 10 years. We >>>>>>> don't want to add new public API without >>>>>>> that level of commitment. >>>>>>> >>>>>>> Every >>>>>>> >>>>>>> new feature forecloses on alternate future >>>>>>> features. Significant >>>>>>> >>>>>>> effort >>>>>>> >>>>>>> must be taken to think about "if we did >>>>>>> this, what could it interact >>>>>>> with in the future?" Also, anything with a >>>>>>> large potential impact on >>>>>>> performance or behavioral compatibility >>>>>>> needs to be looked at >>>>>>> >>>>>>> carefully. >>>>>>> >>>>>>> Put another way, we want to encourage >>>>>>> thinking about new features or >>>>>>> >>>>>>> new >>>>>>> >>>>>>> API in terms of a design / stewardship >>>>>>> process; to think in terms of >>>>>>> questions like "what's the right thing for >>>>>>> JavaFX in the next 10+ >>>>>>> >>>>>>> years" >>>>>>> >>>>>>> rather than "here's some code that solves >>>>>>> my problem, please take >>>>>>> >>>>>>> it". >>>>>>> >>>>>>> As a stake in the ground, I might suggest >>>>>>> the following: >>>>>>> >>>>>>> * All changes need at least one reviewer >>>>>>> other than the person making >>>>>>> the change who can evaluate the change for >>>>>>> correctness and >>>>>>> >>>>>>> consistency. >>>>>>> >>>>>>> For simple bug fixes, a single reviewer >>>>>>> may be sufficient. Of course, >>>>>>> one of our big challenges in all this is: >>>>>>> "how do we grow more >>>>>>> reviewers?", by which I mean "how do we >>>>>>> facilitate getting >>>>>>> >>>>>>> contributors >>>>>>> >>>>>>> with enough expertise in a given area to >>>>>>> eventually be able to >>>>>>> effectively review contributions from >>>>>>> others?" >>>>>>> >>>>>>> * We need clear criteria for the other two >>>>>>> categories that balance >>>>>>> process efficiency with the desire to >>>>>>> maintain compatibility and >>>>>>> stability. API changes need to be approved >>>>>>> by a lead. My thought is >>>>>>> >>>>>>> to >>>>>>> >>>>>>> combine the last two into a single >>>>>>> category for purposes of reviewing >>>>>>> the implementation. Anything that affects >>>>>>> public API or behavioral >>>>>>> compatibility will require CSR or similar >>>>>>> approval, over and above >>>>>>> >>>>>>> the >>>>>>> >>>>>>> implementation review, which seems >>>>>>> sufficient. >>>>>>> >>>>>>> * I recommend that we formalize the >>>>>>> concept of reviewers, using the >>>>>>> OpenJDK Reviewer role for the Project. We >>>>>>> might also consider if we >>>>>>> >>>>>>> want >>>>>>> >>>>>>> to make any changes to the criteria used >>>>>>> by the JDK Project for >>>>>>> >>>>>>> becoming >>>>>>> >>>>>>> an OpenJFX Project Author, Committer, and >>>>>>> Reviewer. The OpenJDK >>>>>>> >>>>>>> bylaws >>>>>>> >>>>>>> allow projects a fair degree of latitude >>>>>>> to define these criteria, so >>>>>>> >>>>>>> we >>>>>>> >>>>>>> might consider making some modifications. >>>>>>> For example, we might make >>>>>>> >>>>>>> it >>>>>>> >>>>>>> somewhat easier for a Contributor to >>>>>>> become an Author, or for a >>>>>>> Committer to become a Reviewer. I have >>>>>>> some thoughts on this, but >>>>>>> >>>>>>> want >>>>>>> >>>>>>> to hear from others first. >>>>>>> >>>>>>> >>>>>>> I look forward to feedback on this >>>>>>> proposal, and hope it will spark a >>>>>>> productive discussion. >>>>>>> >>>>>>> -- Kevin Rushforth, OpenJFX Project Lead >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>> >>
