Feature Freeze is Imminent!

[Richard Bair]

Hi All,

I wanted to post a short message on our current state of development, terminology, and what is coming next. First, the feature freeze for 2.1 is coming next week. This means that the conversation is going to turn from feature work (new APIs and features) to bug fixing. 

"Feature freeze", in our terminology, means that the feature work is completed on the development side. The only way to change an API after mid next week will be through some process that involves sign-off from the stakeholders: dev, management, testing, etc. It isn't impossible, but I'd really like to see us make the transition to full-on bug fixing. We've got another release (2.2) coming later this year so it isn't the end of the world, but paying down our technical debt is a big deal right now so we don't get swamped later on.

Right now, any committer can fix bugs freely. Just get your normal code reviews or whatever process your team is following and off  you go. In a couple months we'll clamp down and start "bug courts". In our old internal process, the way this would work is that we'd get dev, sqe, management, etc into a room (or on the phone) and if you want to put back a bug (any bug) fix you have to first justify it. There was a wiki to keep track of approval / no approval and everything. We also kept track in JIRA. We haven't nailed down the openjfx process, but I assume what we'll do is we'll do it via JIRA. We might still get together in a room and go through all the JIRA issues and discuss and then update the JIRA issue with our votes. Since at the moment there are no non-oracle committers, you will need an Oracle proxy anyway, so that's OK. I *hope* in the next few months some people will be advancing to the committer stage (after having submitted many bug patches, hint hint :-)) and then we'll want to get a skype going or a live chat or something. I'm not sure, we'll have to resolve that part of the process so that everybody is operating on equal footing.

Once we've hit high resistance, you know we're getting close to a release. The final phase is "code freeze" where, after that, no bug fixes are going to happen unless they are absolute show stoppers.

When we hit high resistance, we'll also open up new repos for 2.2. So during high resistance the bug fix rate for 2.1 goes down, the new feature work for 2.2 starts up again, and off we go for another release.

There is a JIRA dashboard I've created (well, cribbed more like, Brian Beck did all the work) called "2.1 OpenJFX Dashboard". You can put this on your JIRA home page by clicking "Dashboards | Manage Dashboards" in the top left corner and then doing a search by name for "2.1 OpenJFX Dashboard". Then click the start to make it a favorite. Then in your home page you will have a tab for it.

This page has the following portlets:



This shows all of the issues which are unresolved and targeted at 2.1. It is broken down by functional area and priority. At the end of the release, any P1-P3 issues that haven't been fixed will have to go through a "deferral process". However since we don't want to see our bug backlog grow out of bounds, I'd really, *really* like to see us resolve at least this many issues. Of course during the next couple months the bug inflow rate will continue, so in the end we will fix quite a few more issues than 298 and might still have some issues which need deferral. But I hope we can at least not get in any further technical debt with regards to our bug backlog.

As Brian Beck would say, you can live in hope or die in despair :-)



The "PRD" stands for "Product Request Document" (or something like that) and is basically the product management's ask for what major features should go into a release. This chart tracks the progress of the completion of these features. This should be 0 next week! Any feature that isn't complete next week will have some 'splainin to do.



Since mac support is one of the big things for 2.1, we've got a special table listing those bugs that are impacting the mac work specifically.



And for all the haters who don't believe we're working on Linux, here you go.



A "New" Bug is one that hasn't been triaged. During the triage process, we validate the priority, owner, targeted release, etc. There are always going to be "new" bugs as every new bug starts of life as "new" and, darn it, bugs get filed. Anyway, this chart is used to indicate which areas are in need of cleaning out their new bugs.



This is the chart I have burned into my retina. Basically it is keeping track of the bug inflow vs. the fix rate. As you can see it has been narrowing since the new year, but what we really want to see here is a whole lot of green! I am making and will be making an impassioned plea for new contributors to put your shoulder to the wheel and help us tackle these bugs! I know each of you have your own pet bugs that you've filed and need fixed, and I'll be outlining the bug fix process  and making it as lightweight as possible. Given the sources for controls are already out, that's a great place to start with fixing!

The path to becoming a full-fledged committer on OpenJFX starts with submitting a series of patches! I would love to start inducting some of you guys who have been making valuable contributions to the discussions.



This is a tattle-tale chart. It tells us which of us are naughty and have bugs in the "new" state for too long. These are problematic because hiding in one of these "new" bugs might be a critical bug or a blocker that we will get stung by later. So if you have your name on this chart, you'd better get crackin' and get these bugs out of the new state!



Finally, here is another trouble indicator -- a blocker should never, ever, be targeted at another release. If it is targeted at another release, then it isn't really a blocker, is it? That's what this chart attempts to capture.

I hope this helps give you the information you need to start hacking on this with us and actually get some of your code into JavaFX!

Thanks
Richard