JavaFX JIRA-related questions

[Mark Fortner]

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:

   1. File a change request with stack trace, code references, or
   screenshots.
   2. Wait for triage and discuss with assignee.
   3. 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.
   4. 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.
   5. If the original poster submits a patch, the assignee can review the
   patch discuss any changes, run the unit tests with the patches.
   6. 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).
   7. 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