How does JFX work get prioritised?
Kevin Rushforth
kevin.rushforth at oracle.com
Mon Oct 29 17:08:23 PDT 2012
I'll take the heat for this one. I just bulk removed the "Lombard"
release for all Feature JIRAs (as opposed to Tweaks) that are not part
of the list of accepted features for the release, without too much
thought behind it. One reason for doing this is to not leave the false
impression that they are being actively worked on, so that people can
either set their expectations appropriately or lobby for it being included.
Based on your e-mail, the number of votes on this issue, and a couple
private e-mails I received, it seems like this is something we should
explicitly reconsider.
-- Kevin
Daniel Zwolenski wrote:
> Is it possible for someone from the Oracle JFX team to outline how features
> get prioritised for inclusion in a release?
>
> I've been frustrated at times with things I think I are important not
> getting done, and I think a few others have had similar
> experiences. Obviously all of us think our bug/feature is the most
> important thing, and not everything can get done and there has to be
> priorities. I think it would be less frustrating though if we actually knew
> the process that was used to prioritise issues - who decides, and what
> metrics are used as input?
>
> I noted today for example, that
> RT-10376<http://javafx-jira.kenai.com/browse/RT-10376>,
> which is simply to allow maximising the stage programmatically, just got
> bumped so its not part of Java8 and is not part of any foreseeable
> release. I personally don't care about this feature so much, but it does
> look like a pretty fundamental, basic thing for a windowing toolkit to
> have, so highlights the general point:
>
> - It was raised as a "critical feature" by Jasper Potts, so it doesn't
> seem a case of not being recognised as important within Oracle.
> - It was raised back in 2010 so it doesn't seem a case of it coming in
> too late and just not making the cut for the release.
> - Based on comments from Anthony Petrov it seems to be already mostly
> implemented and just needs to be hooked in, so I'm assuming it's not really
> a big resourcing issue.
> - It's got 28 votes from the community, placing it at #8 in the most
> voted list by my reckoning, so there's no lack of community interest in the
> issue (3D geometry support has 12 votes for example).
>
> >From my vantage point, it's difficult to see why a feature like this
> wouldn't have been done months ago, let alone be off the road map
> completely, especially when you consider some of the more obscure features
> on the roadmap. Confusion over something like this, for me at least,
> festers into a general distrust in the process, which results in
> frustration around other issues I do consider important (like
> build/deployment).
>
> Can this confusion be lessened through some better communication? Is it
> possible to explain how, in this case and in general, you guys prioritise
> JavaFX work?
>
More information about the openjfx-dev
mailing list