JavaFX JIRA-related questions

[Richard Bair]

Thanks for the thoughts! My goal on this is that somebody ought to be able to download openjfx, build it, & fire up ensemble in about 15 minutes. They ought to be able to debug & test an issue entirely from within the IDE. My threshold is that somebody out there is mad as a hornet and wants to fix some issue but doesn't have more than 30 minutes to really do it in before the passion subsides and they move on. So, I want it to be so easy to download the sources, build something, fix a bug, and submit (where the bug is the "NPE" variety or something essentially trivially to change the implementation -- badder bugs will obviously take more time).

For this to work, one key thing is that there should be a mode where you don't have to build the native bits. We ought to publish native bits someplace that will just work with gradle (for example) so that when you build it just downloads the native bits the same as it does jar file dependencies. Unless you opt to build native bits, and then you're going to have to do a lot more work in terms of setting up your workstation (all the dev tools).

Anyway, that's my goal. Might take a while to get there, first step is improving the build process :-)

Richard

On Jan 22, 2013, at 11:38 AM, Mark Fortner <phidias51 at gmail.com> wrote:

> Hi Richard,
> My personal "sniff test" that I use when it comes to open source projects, is "can I contribute something useful in a weekend" (the amount of time that anyone with a day job typically has to contribute).  Automated builds, definitely make that easier. 
> 
> From previous conversations, you know that dependency tools like Maven and Gradle also make that process easier, since it means I can download the source, binaries and doc by simply including the module in my POM.  When a developer is debugging their code, they can easily follow the bouncing ball into the JavaFX source codebase, and it's more likely that if they find a bug, that they will report it with some pretty useful information (i.e. class and line number), and perhaps contribute a patch back.  If you're automated build updates those basic artifacts then it will make it easier for people to contribute those patches.  It also sounds like the process of reviewing those patches will be made easier.
> 
> You've probably noticed by now that there are at least three types of potential contributors to the project: Weekenders (described previously) and Night Hackers (people who'll be up all night trying to add new functionality or fix a bug), and Day Jobbers (people who find themselves tripping over a bug while doing their day jobs). 
> 
> The main thing that differentiates the people in these groups is their willingness to download the source code, and build it.  Day Jobbers will probably go as far as getting the Maven source and binary modules, and proposing changes or giving you a patch.  Weekenders may download the Java code and add new functionality, and Night Hackers may go all the way and build the native bits (especially if they want to support another platform).  Probably most contributors would fall into the first two groups.
> 
> The way each of these types of contributors works will no doubt make you examine your tools and processes to make sure that those types of contributions can be easily made and reviewed.
> 
> A typical Day Jobber workflow might look like this:
> File a change request with stack trace, code references, or screenshots.
> Wait for triage and discuss with assignee.
> If the assignee doesn't think it's an issue (discuss this before closing the issue).  Closing the issue before discussing it with the original poster is rude and likely to tick people off.
> If it's a real issue, and someone starts working on it, discuss the changes before making them. This can be done with a code review that shows proposed API changes, and some pseudo code or unit tests that show how the code would work. It can save some time if the original poster can see prospective changes before their made to make sure that they actually solve the problem.
> If the original poster submits a patch, the assignee can review the patch discuss any changes, run the unit tests with the patches.  
> A patch build can be made, and linked to the issue so that the original poster can download and run the changes without having to build JavaFX.  (Might need to investigate how best to easily swap out JavaFX instances in order to do this -- it's sometimes easier to just install the patched version into your local Maven repo and run your code to see what happens).
> If everybody's happy, merge the code, run the unit tests, and coverage tools, make sure it passes whatever SQA standards you have, close the issue, and wait for final release.  
> This is a kind of "maximal involvement" workflow, and I wouldn't expect everyone to participate this much in the process. If we can work around the issue, we probably will, and simply throw the issue over the wall to someone at Oracle. :-)
> 
> From the tools perspective, I've noticed is that there seems to be more support for Git than Mercurial out there in the wild (tools like Stash and Sourcetree for example).  I'm sure that's probably a source of consternation for many people both inside and outside Oracle.  One of those Betamax vs VHS questions.
> 
> As for the screenshot capabilities, it looks like somebody "fixed" that problem by disabling screenshots.  I don't see the menu item any more.
> 
> Sorry for nattering on a bit, but if there are any questions, feel free to ask.
> 
> Cheers,
> 
> Mark
> 
> 
> 
> On Tue, Jan 22, 2013 at 10:24 AM, Richard Bair <richard.bair at oracle.com> wrote:
> Hi Mark!
> 
> On Dec 17, 2012, at 1:00 PM, Mark Fortner <phidias51 at gmail.com> wrote:
> 
> > I've filed a number of JIRA issues and I was wondering if there are any
> > plans to connect the Hg repo to JIRA?  We do this all the time with SVN and
> > GIT and it makes it easier to code review the change, and the unit test
> > when we can see the change set.  The change set normally appears in the
> > "Source" tab inside the JIRA issue.
> 
> Yes. We are working on an infrastructure plan along with OpenJDK (we will be using the same core services / servers / process in the future) which includes updating JIRA whenever patches are integrated into master. We're also looking at Crucible (or Stash) as a means for code review, and having our JIRA instance be the "one truth" and other tools tied / integrated into it.
> 
> The first step in our master plan is to get SQE tests open sourced and part of the forest, along with the rest of our closed source bits. We'll then be consolidating our tests & cleaning up the build. Once we've got a nice build in place, we'll be tackling tasks such as integrated code coverage reports etc. At the same time the JDK team is working on getting the JBS (Java Bug System) JIRA instance public and we'll look at migrating over to that (I would guess somewhere in the 6-12 month timeframe). Also a new instance of confluence that we will use to start putting all our docs onto (much shorter timeframe).
> 
> The next thing we want to accomplish is to get setup for continuous integration, such that instead of having a bunch of different forests we just have the master forest. We want a system where we have well defined "integration tests" which must all pass before a patch can be integrated into master. We want to have a system where this happens automatically. I submit my patch and it is automatically merged with master, built, and tested on all platforms. If everything builds & all tests pass, then the patch is automatically integrated with master and the JIRA issue updated. From there we kick off a longer set of continuous tests ("nightlies"). If those pass some acceptance threshold then the bits are posted as nightly binaries and we start a longer set (2 weeks? more?) of tests such as stability tests etc.
> 
> Also getting code review etc setup. Personally I would love to use something like Stash -- essentially a self-hosted bit-bucket -- that would let us fire up developer forests or sandboxes etc as needed and then issue pull-requests and let that be the mechanism by which a patch gets into the auto-integration queue. But Stash doesn't yet support mercurial so it is a non-starter at this point.
> 
> I would also, personally, like to have just a single open repo and not a whole forest. There are tradeoffs here (time to clone a repo -- if you only work on Media for example you might not be used to cloning & building webkit, so each new clone operation will take a lot longer with only one repo -- vs the simplicity of working with a single repo and everybody working on the same project files & having everything to build and test with), but for my money I think we ought to all just use the same repo to avoid the inevitable silo-ing that occurs today.
> 
> > Also, whenever I try to use the screenshot feature in JIRA to take a
> > screenshot and attach it to the issue, I get an Oracle Technet home page,
> > instead of the appropriate applet page.  Could somebody fix that?
> 
> Brian?
> 
> Richard
>