[Go Faster] Do we want system add-ons to update without restarting?

Chris Hofmann chofmann at mozilla.com
Mon Sep 28 19:10:16 UTC 2015


On Mon, Sep 28, 2015 at 10:54 AM, Robert Helmer <rhelmer at mozilla.com> wrote:

> I don't have all the answers here, but when I said "autonomous" I more
> had in mind partners like Pocket, who are already working on their
> own, with their own processes, and giving us code dumps.


After a group like the pocket developers give us a "code dump"
what happens from there.  Would they work autonomously on all the
rest of the stages toward release of promotion to press and users, or
at some point do they start working less autonomously and more integrated
into our defined release process?



> My impression
> is that we're going to have more partner integrations in the future
> and we want to try to improve the situation here.
>

It sounds like a good impression to confirm, and understand more
about how the interaction and process toward pushing out bits to
each of the testing and release channels will work.


>
> The Hello team largely operates within normal Mozilla processes right
> now as you describe. The release process is the only thing I imagine
> them having more autonomy around.
>
>
By release process to you mean pushing the button on making the bits
available,
or some other pieces closing related to that process?  It would be good
have a common defintion of that term and where system addons
lend benefit.

I'm hopeful that we won't be by passing important
testing, security evaluations, crash measurement, and all the things that
we do at the expense time in an effort to raise or maintain quality.
There are even more checks like static analysis of code, and response
*before* landing, that suggested by roc and others over on the thread
Sylvestre started on dev-platform.

This kind of increased scrutiny of code could be interpreted as
reducing the amount of autonomy of a developer or system addon
development team might have if there goal is to just get their addon
shipped, but it would be good to get this definition nailed down.

To reduce chemspills and user frustration we are going to have to find
ways to raise the quality bar and allow for more testing and this might be
at odds
with "developer autonomy"  and also "shipping faster" so I think its a
worthwhile
thing to define clearly since there could be some tension there between
requirements.

-chofmann


>
> On Mon, Sep 28, 2015 at 10:13 AM, Chris Hofmann <chofmann at mozilla.com>
> wrote:
> >
> >
> > On Mon, Sep 28, 2015 at 6:53 AM, Laura Thomson <lthomson at mozilla.com>
> wrote:
> >>
> >>
> >> > It allows teams
> >> > working on these add-ons to be more autonomous and not have to sync to
> >> > Firefox's release cycle (barring a dependency on a platform change).
> >>
> >> What Rob said, here.
> >>
> >> Laura
> >> ==
> >>
> >
> > I think its worthwhile defining what "Working Autonomously" means.   Its
> not
> > listed as goal or anywhere in the PRD.
> >
> > There are several place where "Working Automously" might come in to play.
> >
> > During development of code.   - Developers work Autonomously on this now,
> > they are able to land new code on there own development branch or
> central as
> > wanted.
> >
> > During localization of code.  - Developers work autonomously on this now,
> > they land strings and l10n-drivers and localization teams get the feature
> > localized, sometimes within hours of code landing, and some times with
> some
> > teams on the aurora or latter cycle.  We really don't have a definition
> of
> > when localization work is "required" and we really don't require any
> > developer involvement in the process in most cases other than than
> landing
> > good and well thought out en-US strings and comply with well defined
> > development practices that allow the efficient translation of the
> feature.
> > Its been suggested that if we somehow allow features to ship only in
> en-US,
> > or only in selected languages it will somehow increase developer
> autonomy,
> > but it also works against the goal of a product built to reach all of our
> > global audience.  If we are interested in maintaining and building global
> > marketshare that ought to be an explicit goal.  The systems in place now
> > both allow developer autonomy and meet the goal of reaching the widest
> > possible audience.
> >
> > During testing, security checks, stability assessment and other
> evaluation,
> > of code.   Developers don't work autonomously on this now.  They engage
> with
> > QA and our testing community to get feedback and bugs to shape the
> feature.
> > How are system addons intended to change automomy in this area?   Its
> been
> > hinted at that developers might do this work, or make decisions that
> some of
> > these tasks might not be needed or intentionally avoided in the interest
> of
> > shipping sooner.  It would be good to figure out and make explicit if
> this
> > is the case.
> >
> > During Release Management and over all Integration of the feature into
> the
> > single browser product that we ship.   How it all hangs together is one
> of
> > the most important things we assess and do.  It creates the unified
> browsing
> > experience we want our users have.    Its also hard for me to see how
> > individual developer autonomy helps in performing these tasks, and it
> > appears that system addons is actually a distraction in getting that work
> > accomplished, since they operate in a parallel distribution path.  The
> > increase the amount of work to get done, the number or releases to
> > administer and ship, and intern the more work and time spent actually
> causes
> > us to go slower.
> >
> > These are just a few areas where autonomy might come into play.  Lets
> define
> > and asses what autonomy means if its an important part of system addons.
> >
> > -chofmann
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/gofaster/attachments/20150928/d497a335/attachment.html>


More information about the Gofaster mailing list