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 >>>> >>>> >>>> >>>> >>>> >>
