Re: Update on 2016 Firefox Release Schedule

On Thu, Feb 4, 2016 at 5:10 PM, Dave Herman <[email protected]> wrote:

> I'm concerned about the suggestion that we could start delaying trains,
> especially on an ad hoc basis. Trains work because of predictability and
> frequency.
>
> It's hard for me to quite understand the rationale behind varying the
> schedule, but if it's because of things like quality issues, say, from
> shipping features before they're adequately tested, then delaying trains
> will actually exacerbate the problems, not fix them. The less people can
> depend on trains, the more pressure they will feel to ship early, which is
> precisely the thing you were trying to address. If the problem with
> holidays and such is that people are trying to cram features in at the last
> minute, then again, delaying trains and making them less predictable will
> exacerbate that.
>

A bunch of thoughts to share on this but I'll just share three and then try
to catch you for a beer to talk about the others.

The first on this point about being pressured to cram features or even
prematurely tested regression bug fixes on to trains, or even jump trains
with them.

Quality is only going to get better if we find ways to remove that pressure
and take the time and effort to analyze and test each change that we make.
As dbaron said back in Portland "we have an uneven amount of time and
effort applied to testing" (roughtly quoting).  Poorly constructed changes
that aren't well tested and are under presume to land are a big source of
our problems so lets just find ways to take that issue head on.  The
presure can come in many forms.  People telling engineers that "we've got
to get this feature or bug fix shipped..."  is one.  Engineers thinking "I
just want to get this patch checked in..."  is another.  Those are watch
words to look for danger.

The other thing about the trains is that its killed a lot of motivation for
people to get involved and passionate around helping to test.  The
motivation has been replaced with the attitude that is "why should I
bother, you are just going to ship this thing anyway..."     We need to
find a way to restoring that motivation and it starts by encouraging more
people to find ship blockers and rewarding them by fixing before we ship.
That might upset the timing and reliability of the release schedule but
something we've got to do if we are really interested in improving quality.


>
> Regardless of the rationale, adding variability and uncertainty into the
> train system works directly at odds with what it has been so successful at
> achieving -- not just for Firefox, but for Chrome and Rust, for example.
>

This is a really, really, good video.

https://air.mozilla.org/january-2016-brantina-ideals-over-ideology-building-software-with-the-end-in-mind-with-jocelyn-goldfein/

It challenges your idea that the release model for Rust is one that should
by definition be the one that should work for Firefox given its stage of
development and the users that its currently serving.  It sets up a
framework where we can talk about what release models might work best for
the set of users that software serves.

The first stage toward defining a good release model would begin by
developing some consensus around which of the quadrants each of our
products has now.  As we add products to quadrants to target different sets
of users it would allow us to use different release models with different
sets of timing and quality considerations.

Experimental products allow development teams to move fast and try lots of
experiments.  They get to target users that love to check out
innovation.    The bulk of users demand something much more stable and well
tested.  They leave if you force software on them that is not ready for
prime time if they have other choices.



> This isn't a small thing: giving credit where due, I see trains as the best
> thing Chrome ever did for the web. It's been one of the biggest drivers in
> pushing the platform forward. I would hate to see us regress in our
> contribution to that part of our mission.
>

I agree here, but would offer that lagged on one important goal.  We are
shipping software with too many regressions.

-chofmann


>
> Dave
>
> On Thu, Feb 4, 2016 at 12:50 PM, Lawrence Mandel <[email protected]>
> wrote:
>
> > Four years ago Mozilla moved to a fixed-schedule release model, otherwise
> > known as the Train Model
> > <https://blog.mozilla.org/channels/2011/07/18/every-six-weeks/>, in
> which
> > we released Firefox every six weeks to get features and updates to users
> > faster and move at the speed of the Web. We studied the process carefully
> > and learned a lot. We have also identified additional areas for
> improvement
> > and it’s time we iterate again.
> >
> > We are moving to a variably scheduled six-to-eight week release cycle for
> > Firefox. With this new release cycle, we will deliver the same number of
> > releases per year but gain a few significant benefits over the previous
> six
> > week fixed model.
> >
> > For example, we will now be able to adjust release dates to respond to
> > emerging user and market needs and provide at least six working weeks for
> > every release. We also want to help support the well-being and
> > connectedness of our global Mozilla community by specifically allowing
> time
> > for holidays.
> >
> > You’ll find the 2016 Firefox release schedule listed below and in the
> > following Wiki <https://wiki.mozilla.org/RapidRelease/Calendar>.
> >
> >
> > This note has also been posted to the Future of Firefox blog
> > <
> >
> https://blog.mozilla.org/futurereleases/2016/02/04/update-on-2016-firefox-release-schedule
> > >
> > .
> >
> >
> > 2016 Firefox Release Schedule
> >
> > 2016-01-26 - Firefox 44
> >
> > 2016-03-08 - Firefox 45, ESR 45 (6 weeks cycle)
> >
> > 2016-04-19 - Firefox 46 (6 weeks cycle)
> >
> > 2016-06-07 - Firefox 47 (7 weeks cycle)
> >
> > 2016-08-02 - Firefox 48 (8 weeks cycle)
> >
> > 2016-09-13 - Firefox 49 (6 weeks cycle)
> >
> > 2016-11-08 - Firefox 50 (8 weeks cycle)
> >
> > 2016-12-13 - Firefox 50.0.1 (5 week cycle, release for critical fixes as
> > needed)
> >
> > 2017-01-24 - Firefox 51 (6 weeks from prior release)
> >
> > Note: Firefox ESR will continue to ship point releases on the same day
> that
> > Firefox ships.
> >
> >
> > Lawrence
> > _______________________________________________
> > dev-planning mailing list
> > [email protected]
> > https://lists.mozilla.org/listinfo/dev-planning
> >
> _______________________________________________
> dev-planning mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-planning
>
_______________________________________________
dev-planning mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-planning