Yes, I agree - sorry. I got a bit confused as to which thread I was “in” (while reading messages from each of them simultaneously) and there’s definitely a degree of overlap between the two of them topic-wise.
Anyway, I vented - just not in the right place. I still hope for some feedback on said venting... > On 8 Feb 2018, at 03:42, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > > This has now veered off topic for this thread. It would be a fine topic for > the "future content of OpenJFX" thread. > > -- Kevin > > > John-Val Rose 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>
