Re: Coupled Train Model

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Boris Zbarsky
On 10/18/13 2:10 PM, Alex Keybl wrote:
> The main purpose of Aurora as a channel is to get early feedback on new Firefox versions with users that better represent our Beta/Release populations.

A major purpose of Aurora (that I think we've totally failed to
effectively publicize) is to provide a less-scary-than-nightly option
for web developers who want to experiment with new functionality that's
not enabled by default yet and provide feedback on it.  This is why
various experimental stuff is enabled on Aurora.

In the new model, will Aurora still be usable for this purpose?  I guess
it will, since after 2 weeks or so Aurora will basically be "Beta with
the experimental stuff turned on"?

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Alexander Keybl
Correct, there can continue to be Aurora specific features disabled on Beta.

-Alex

----- Original Message -----
From: Boris Zbarsky <[hidden email]>
To: [hidden email]
Sent: Fri, 18 Oct 2013 11:39:16 -0700 (PDT)
Subject: Re: Coupled Train Model

On 10/18/13 2:10 PM, Alex Keybl wrote:
> The main purpose of Aurora as a channel is to get early feedback on new Firefox versions with users that better represent our Beta/Release populations.

A major purpose of Aurora (that I think we've totally failed to
effectively publicize) is to provide a less-scary-than-nightly option
for web developers who want to experiment with new functionality that's
not enabled by default yet and provide feedback on it. This is why
various experimental stuff is enabled on Aurora.

In the new model, will Aurora still be usable for this purpose? I guess
it will, since after 2 weeks or so Aurora will basically be "Beta with
the experimental stuff turned on"?

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Nicolas B. Pierron
In reply to this post by Boris Zbarsky
On 10/18/2013 11:10 AM, Alex Keybl wrote:
 > * change the desktop/android train model to have two 9-week cycles rather
 > than three 6-week cycles (still 18 weeks start to finish)

So, after 9 weeks of nightly (instead of 6 weeks), we will merge into
aurora?  Do we really expect that we would be able to fix 1.5 times more
code in the same period of time on aurora?

Also, B2G development is currently synchronized with even versions of Gecko.
  What would be the impact there? I don't think we want to switch B2G to a
18 weeks cycle, can we switch to a 9 weeks cycle?

On 10/18/2013 11:10 AM, Alex Keybl wrote:
 > * merge mozilla-aurora to mozilla-beta as soon as critical quality issues
 > have been resolved on both Aurora and Release (1-2 weeks after that)

What does Ā«as soon as critical quality issues have been resolvedĀ» implies?
Does that mean that the overlap period would be variable period of time and
we shift the train only when things are good enough?

When I look at the diagram, I wonder what would be the advantage of anybody
to use Aurora if this is just to have all the bugs & features 1-2 weeks
before every beta users.  Wouldn't that decrease the remaining Aurora users,
in which case this grace period for beta would be useless as we would have
either nightly users or beta users?

--
Nicolas B. Pierron
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Zack Weinberg-2
In reply to this post by Boris Zbarsky
On 2013-10-18 2:39 PM, Boris Zbarsky wrote:

> On 10/18/13 2:10 PM, Alex Keybl wrote:
>> The main purpose of Aurora as a channel is to get early feedback on
>> new Firefox versions with users that better represent our Beta/Release
>> populations.
>
> A major purpose of Aurora (that I think we've totally failed to
> effectively publicize) is to provide a less-scary-than-nightly option
> for web developers who want to experiment with new functionality that's
> not enabled by default yet and provide feedback on it.  This is why
> various experimental stuff is enabled on Aurora.

Periodic reminder that as long as we don't have one-checkbox
side-by-side installation of multiple channels (simultaneously runnable,
in separate profiles, sync hooked up automatically), web developers
cannot be bothered even with Beta, let alone Aurora.

zw
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Gavin Sharp-3
In reply to this post by Nicolas B. Pierron
On Fri, Oct 18, 2013 at 2:17 PM, Nicolas B. Pierron
<[hidden email]> wrote:
> So, after 9 weeks of nightly (instead of 6 weeks), we will merge into
> aurora?  Do we really expect that we would be able to fix 1.5 times more
> code in the same period of time on aurora?

It's not "the same period of time on aurora" - it's 9 weeks spread
across beta/aurora. So for stabilization, instead of 6 weeks on Aurora
+ 6 weeks on Beta, we get 2 weeks on Aurora and 7 weeks on
Aurora+Beta.

Gavin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Axel Hecht
In reply to this post by Boris Zbarsky
On 10/18/13 8:10 PM, Alex Keybl wrote:
> * a new string freeze date - current proposal is upon the merge to Beta, since features that aren't ready for release will be backed out by that point
That's not really enough detail to comment on the l10n aspects of your
proposal. I'd like you to explain how you're suggesting to get to a
localized release.

A bit of data as food for thought: On Firefox 24, 70 teams signed off,
53 of which were on aurora or earlier work. 17 locales only caught up on
beta, while 13 signed off on additional fixes. That could just be the
aurora-beta merge commit, though, too.

Axel
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Sebastian Hengst
In reply to this post by Boris Zbarsky
Questions which came to my mind:

* How will we attract users to Aurora if they get the same branch for 7
of 9 weeks on Beta?

* Developers will have 9 weeks time for bug fixing/polishing/making the
product end user ready and 9 weeks for developing, while nowadays they
have 12 weeks for "fixing" features developed in 6 weeks. This could be
problematic directly after the change because they aren't yet used to it.

* An API freeze shortly after the beta merge when parts of API changes
are still dev-doc-needed will make add-on compatibility changes for
add-on developers very hard. Any ideas how to improve that situation
(the timeframe for add-on developers has also been halved)?

* L10n:

** If there will be no fixed date when localization can start, most
localizers will start working at a moment which would have also worked
before.

** Let's say two weeks on Aurora, that leaves 7 weeks on Beta.
Localizers have to finish the localization with a signoff more than a
week before release. Because that's a Monday and the signoff request
usually doesn't get reviewed earlier on that Monday or the weekend
before, that's 1.5 weeks less for localization. So there are 5.5 weeks
left for localization. Given that localizations on Beta have to be
reviewed to get into production (not required on Aurora), it will be
hard to discover issues and collect feedback in that time frame before.
At the moment, localizers have 11 weeks from start to end.

Thank you in advance
Sebastian
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Gavin Sharp-3
On Sat, Oct 19, 2013 at 3:50 PM, Archaeopteryx
<[hidden email]> wrote:
> * How will we attract users to Aurora if they get the same branch for 7 of 9
> weeks on Beta?

Attracting users to Aurora isn't really a goal in and of itself (it's
only a goal insofar as it helps us ship better software). This
proposal seems like the result of confronting the reality that we have
not been able to maintain a useful Aurora differentiation for users,
so we might as well try a different approach and (mostly) combine it
with beta.

Gavin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Nicolas B. Pierron
In reply to this post by Boris Zbarsky
On 10/18/2013 11:10 AM, Alex Keybl wrote:
 > We find most major Aurora issues in the first week or so after the merge,
 > and critical Beta-blocking issues are typically resolved within days
 > thereafter.

If I understand correctly, we are trying to optimize the train model based
on this fact.

 > We have an informal saying in Release Management that we should always
 > "get new code in front of the most users as soon as possible".

The problem is that Aurora does not have enough users.  Currently we have
almost the same number of Aurora users as Nightly users, which is too low
compared to Beta.

The "Coupled Train Model" suggests to give the changes sooner to Beta users
by only making use of Aurora for a few weeks.  After these few weeks the
only difference would be features which are enabled in one but not the other.

I fear that doing so will reduce even more the number of Aurora users by
making Aurora less attractive.  Thus this would emphasize the original
problem, by reducing the number of user on Aurora. A consequence of reducing
the number of Aurora users would be to augment the time needed for finding
"most major Aurora issues".

 > We have an informal saying in Release Management that we should always
 > "get new code in front of the most users as soon as possible".

Why not using this informal saying, to increase our number of users on
Aurora?  One model KaiRo and I came up with while trying to answer the same
question was to use a "Wagon Train Model" [1].

The idea being to merge multiple time from Nightly into Aurora, and keeping
the rest unchanged.  This way, instead of having Aurora useful for only the
first 1-2 weeks, we can make a full use of it by finding major issues sooner.

These 2 models are not incompatible, as you pointed out in a private reply.
  Still, I think the "Coupled Train Model" does not try to solve the root of
the problem, which is that we do not have enough Aurora users.  And worse,
it might emphasize the problem.

On the other hand, the "Wagon Train Model" attempt to address the problem by
making Aurora more attractive, and thus increasing the number of Aurora users.

[1]
https://docs.google.com/spreadsheet/ccc?key=0AkXdfV25b2n5dFFfUzFqcHZnaVVVbWw1LXRXVXNqTFE&usp=sharing

--
Nicolas B. Pierron

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Alexander Keybl
In reply to this post by Axel Hecht
We'll have a meeting soon to float ideas and come to an agreement with you. I've had early conversations with chofmann, who noted that the most it's most important to give localizers a stable string base and enough time to translate. We're working hard to make sure we make everybody happy with the new tweaks.

-Alex

On Oct 19, 2013, at 7:28 AM, Axel Hecht <[hidden email]> wrote:

> On 10/18/13 8:10 PM, Alex Keybl wrote:
>> * a new string freeze date - current proposal is upon the merge to Beta, since features that aren't ready for release will be backed out by that point
> That's not really enough detail to comment on the l10n aspects of your proposal. I'd like you to explain how you're suggesting to get to a localized release.
>
> A bit of data as food for thought: On Firefox 24, 70 teams signed off, 53 of which were on aurora or earlier work. 17 locales only caught up on beta, while 13 signed off on additional fixes. That could just be the aurora-beta merge commit, though, too.
>
> Axel
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Alexander Keybl
In reply to this post by Sebastian Hengst
> * How will we attract users to Aurora if they get the same branch for 7 of 9 weeks on Beta?

Aurora as a population has not grown significantly over the last two years, but rather maintained. Note that Aurora will have some features that are disabled for Beta.

> * Developers will have 9 weeks time for bug fixing/polishing/making the product end user ready and 9 weeks for developing, while nowadays they have 12 weeks for "fixing" features developed in 6 weeks. This could be problematic directly after the change because they aren't yet used to it.

I do expect a bumpy first couple of cycles, but we feel it's for the best in the longterm.

> * An API freeze shortly after the beta merge when parts of API changes are still dev-doc-needed will make add-on compatibility changes for add-on developers very hard. Any ideas how to improve that situation (the timeframe for add-on developers has also been halved)?

Early feedback from add-on developers is that less frequent updates fits their dev schedule better. We'll have to figure out an API freeze date that works for both Mozilla and third parties.

-Alex

On Oct 19, 2013, at 6:50 PM, Archaeopteryx <[hidden email]> wrote:

> Questions which came to my mind:
>
> * How will we attract users to Aurora if they get the same branch for 7 of 9 weeks on Beta?
>
> * Developers will have 9 weeks time for bug fixing/polishing/making the product end user ready and 9 weeks for developing, while nowadays they have 12 weeks for "fixing" features developed in 6 weeks. This could be problematic directly after the change because they aren't yet used to it.
>
> * An API freeze shortly after the beta merge when parts of API changes are still dev-doc-needed will make add-on compatibility changes for add-on developers very hard. Any ideas how to improve that situation (the timeframe for add-on developers has also been halved)?
>
> * L10n:
>
> ** If there will be no fixed date when localization can start, most localizers will start working at a moment which would have also worked before.
>
> ** Let's say two weeks on Aurora, that leaves 7 weeks on Beta. Localizers have to finish the localization with a signoff more than a week before release. Because that's a Monday and the signoff request usually doesn't get reviewed earlier on that Monday or the weekend before, that's 1.5 weeks less for localization. So there are 5.5 weeks left for localization. Given that localizations on Beta have to be reviewed to get into production (not required on Aurora), it will be hard to discover issues and collect feedback in that time frame before. At the moment, localizers have 11 weeks from start to end.
>
> Thank you in advance
> Sebastian

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Alexander Keybl
In reply to this post by Nicolas B. Pierron
> Why not using this informal saying, to increase our number of users on Aurora?  One model KaiRo and I came up with while trying to answer the same question was to use a "Wagon Train Model" [1].

As you noted, any benefits it brings can be worked into this model in the future (more frequent merges to Aurora from Nightly). I'd really like to keep this thread on topic, if possible.

> These 2 models are not incompatible, as you pointed out in a private reply.  Still, I think the "Coupled Train Model" does not try to solve the root of the problem, which is that we do not have enough Aurora users.  And worse, it might emphasize the problem.

As Gavin mentioned, we're accepting the current state of populations and trying to make best use of them. We don't have any data to suggest that your proposed model will improve Aurora population size, but we do have data that suggests more time with the beta channel would yield more fixes in a release.

-Alex

On Oct 20, 2013, at 7:53 PM, "Nicolas B. Pierron" <[hidden email]> wrote:

> On 10/18/2013 11:10 AM, Alex Keybl wrote:
> > We find most major Aurora issues in the first week or so after the merge,
> > and critical Beta-blocking issues are typically resolved within days
> > thereafter.
>
> If I understand correctly, we are trying to optimize the train model based on this fact.
>
> > We have an informal saying in Release Management that we should always
> > "get new code in front of the most users as soon as possible".
>
> The problem is that Aurora does not have enough users.  Currently we have almost the same number of Aurora users as Nightly users, which is too low compared to Beta.
>
> The "Coupled Train Model" suggests to give the changes sooner to Beta users by only making use of Aurora for a few weeks.  After these few weeks the only difference would be features which are enabled in one but not the other.
>
> I fear that doing so will reduce even more the number of Aurora users by making Aurora less attractive.  Thus this would emphasize the original problem, by reducing the number of user on Aurora. A consequence of reducing the number of Aurora users would be to augment the time needed for finding "most major Aurora issues".
>
> > We have an informal saying in Release Management that we should always
> > "get new code in front of the most users as soon as possible".
>
> Why not using this informal saying, to increase our number of users on Aurora?  One model KaiRo and I came up with while trying to answer the same question was to use a "Wagon Train Model" [1].
>
> The idea being to merge multiple time from Nightly into Aurora, and keeping the rest unchanged.  This way, instead of having Aurora useful for only the first 1-2 weeks, we can make a full use of it by finding major issues sooner.
>
> These 2 models are not incompatible, as you pointed out in a private reply.  Still, I think the "Coupled Train Model" does not try to solve the root of the problem, which is that we do not have enough Aurora users.  And worse, it might emphasize the problem.
>
> On the other hand, the "Wagon Train Model" attempt to address the problem by making Aurora more attractive, and thus increasing the number of Aurora users.
>
> [1] https://docs.google.com/spreadsheet/ccc?key=0AkXdfV25b2n5dFFfUzFqcHZnaVVVbWw1LXRXVXNqTFE&usp=sharing
>
> --
> Nicolas B. Pierron
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Axel Hecht
In reply to this post by Axel Hecht
I personally care about getting a great localized release channel out to
users. That's 60% of our users, and I want a great product for those. I
guess everyone else wants that, too.

On the way there, we currently have some vehicles/channels with a
variety of properties and social contracts. Most of those aren't well
defined. As far as I understand those, you're proposing to change at
least some of them.

I'd ask you to define what you think the various builds should be in
particular with l10n in mind, so that I don't have to speculate about
those, and put words in your mouth.

Right now, I think that calendars are a technical detail. Sure, we need
to make them useful, but I don't see how we'd do that without knowing
what the blocks on that calendar actually stand for.

Axel

On 10/21/13 3:16 PM, Alex Keybl wrote:

> We'll have a meeting soon to float ideas and come to an agreement with you. I've had early conversations with chofmann, who noted that the most it's most important to give localizers a stable string base and enough time to translate. We're working hard to make sure we make everybody happy with the new tweaks.
>
> -Alex
>
> On Oct 19, 2013, at 7:28 AM, Axel Hecht <[hidden email]> wrote:
>
>> On 10/18/13 8:10 PM, Alex Keybl wrote:
>>> * a new string freeze date - current proposal is upon the merge to Beta, since features that aren't ready for release will be backed out by that point
>> That's not really enough detail to comment on the l10n aspects of your proposal. I'd like you to explain how you're suggesting to get to a localized release.
>>
>> A bit of data as food for thought: On Firefox 24, 70 teams signed off, 53 of which were on aurora or earlier work. 17 locales only caught up on beta, while 13 signed off on additional fixes. That could just be the aurora-beta merge commit, though, too.
>>
>> Axel
>> _______________________________________________
>> dev-planning mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Chris Hofmann-3
In reply to this post by Alexander Keybl
On 10/21/13 6:16 AM, Alex Keybl wrote:
> We'll have a meeting soon to float ideas and come to an agreement with you. I've had early conversations with chofmann, who noted that the most it's most important to give localizers a stable string base and enough time to translate.

I'll also add that what I think we discussed was that getting
localization work finished before moving to beta was a key part of the
work that needs to be done on aurora.   As Axel mentioned most of our
users don't use the English version.  It's actually 70%, so serving and
building larger beta populations around the world should be a key goal
to improving quality.

When you explained the idea to me a second time it was actually just an
effort to move in the most orderly and fast way to getting to a stable
beta, then moving that set of software to beta.  The idea was the we
were just going to try and get more disciplined about not taking
features into beta, and avoiding risky changes that could destabilize.
    The two weeks was just a target for trying to achieve this, not a
fixed time table.    I also think the "9-9" confuses things even further
as part of this proposal because it hints at things happening automatically.

I think we are better served by this model and we need to just develop a
good checklist for what constitues "finishing aurora" in terms of having
localizations "done",  getting and checking stability data, finishing
the testing of experimental features as borris mentioned, and anything
else the aurora cycle is still targeted to achieve.   Then when all
those things are checked off it will be time to move as quickly as
possible to beta.

Thats the kind of proposal that makes most sense to me, and helps us to
achieve more disapline in building the software.  I think that we
sometimes forget about thats what we are trying to achieve with the
train model.  Its better discipline that we are trying to add.

-chofmann


>   We're working hard to make sure we make everybody happy with the new tweaks.
>
> -Alex
>
> On Oct 19, 2013, at 7:28 AM, Axel Hecht <[hidden email]> wrote:
>
>> On 10/18/13 8:10 PM, Alex Keybl wrote:
>>> * a new string freeze date - current proposal is upon the merge to Beta, since features that aren't ready for release will be backed out by that point
>> That's not really enough detail to comment on the l10n aspects of your proposal. I'd like you to explain how you're suggesting to get to a localized release.
>>
>> A bit of data as food for thought: On Firefox 24, 70 teams signed off, 53 of which were on aurora or earlier work. 17 locales only caught up on beta, while 13 signed off on additional fixes. That could just be the aurora-beta merge commit, though, too.
>>
>> Axel
>> _______________________________________________
>> dev-planning mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-planning
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Aki Sasaki
In reply to this post by Zack Weinberg-2
On 10/18/13 2:25 PM, Zack Weinberg wrote:

> On 2013-10-18 2:39 PM, Boris Zbarsky wrote:
>> On 10/18/13 2:10 PM, Alex Keybl wrote:
>>> The main purpose of Aurora as a channel is to get early feedback on
>>> new Firefox versions with users that better represent our Beta/Release
>>> populations.
>>
>> A major purpose of Aurora (that I think we've totally failed to
>> effectively publicize) is to provide a less-scary-than-nightly option
>> for web developers who want to experiment with new functionality that's
>> not enabled by default yet and provide feedback on it.  This is why
>> various experimental stuff is enabled on Aurora.
>
> Periodic reminder that as long as we don't have one-checkbox
> side-by-side installation of multiple channels (simultaneously runnable,
> in separate profiles, sync hooked up automatically), web developers
> cannot be bothered even with Beta, let alone Aurora.

This would be nice, as would an equivalent to the
extensions.checkCompatibility.nightly=false.  With this set, I can use
nightly with all my addons.  Without this set, most of my addons go away
and I can't get them back.  Aiui, Aurora and Beta don't have
equivalents, other than extensions.checkCompatibility.VERSION which need
to be updated every 6 weeks, so when Nightly goes kablooey I
automatically reach for Release.  With an
extensions.checkCompatibility.{aurora,beta}=false I'd be more likely to
use them.

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Jeff Griffiths-4
In reply to this post by Zack Weinberg-2


On 10/18/2013, 2:25 PM, Zack Weinberg wrote:

> On 2013-10-18 2:39 PM, Boris Zbarsky wrote:
>> On 10/18/13 2:10 PM, Alex Keybl wrote:
>>> The main purpose of Aurora as a channel is to get early feedback on
>>> new Firefox versions with users that better represent our Beta/Release
>>> populations.
>>
>> A major purpose of Aurora (that I think we've totally failed to
>> effectively publicize) is to provide a less-scary-than-nightly option
>> for web developers who want to experiment with new functionality that's
>> not enabled by default yet and provide feedback on it.  This is why
>> various experimental stuff is enabled on Aurora.
>
> Periodic reminder that as long as we don't have one-checkbox
> side-by-side installation of multiple channels (simultaneously runnable,
> in separate profiles, sync hooked up automatically), web developers
> cannot be bothered even with Beta, let alone Aurora.

This is a point we keep coming back to. If there aren't enough users on
Aurora to be useful in terms of testing or bug discovery I would love to
be able to use it to target web developers specifically ( we already
recommend it ) along with some developer-centric features. This could be
as simple as:

1) prompt the user on first-run of Aurora if they want a 'developer'
profile.

2) afterwards, only launch Aurora with the Aurora profile.

I like the automagic sync idea only to a point - developers are going to
tend to have different configurations / extensions / etc for a
dev-centric browser.

$0.02, Jeff
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Stormy Peters-6
On Mon, Oct 21, 2013 at 2:24 PM, Jeff Griffiths <[hidden email]>wrote:

>
>
> On 10/18/2013, 2:25 PM, Zack Weinberg wrote:
>
>> On 2013-10-18 2:39 PM, Boris Zbarsky wrote:
>>
>>> On 10/18/13 2:10 PM, Alex Keybl wrote:
>>>
>>>> The main purpose of Aurora as a channel is to get early feedback on
>>>> new Firefox versions with users that better represent our Beta/Release
>>>> populations.
>>>>
>>>
>>> A major purpose of Aurora (that I think we've totally failed to
>>> effectively publicize) is to provide a less-scary-than-nightly option
>>> for web developers who want to experiment with new functionality that's
>>> not enabled by default yet and provide feedback on it.  This is why
>>> various experimental stuff is enabled on Aurora.
>>>
>>
>> Periodic reminder that as long as we don't have one-checkbox
>> side-by-side installation of multiple channels (simultaneously runnable,
>> in separate profiles, sync hooked up automatically), web developers
>> cannot be bothered even with Beta, let alone Aurora.
>>
>
> This is a point we keep coming back to. If there aren't enough users on
> Aurora to be useful in terms of testing or bug discovery I would love to be
> able to use it to target web developers specifically ( we already recommend
> it ) along with some developer-centric features. This could be as simple as:
>

I think one change that would really help (suggested by choffman I believe)
is to rename Aurora to something that implies that it is a developer or
early release.

Stormy


>
> 1) prompt the user on first-run of Aurora if they want a 'developer'
> profile.
>
> 2) afterwards, only launch Aurora with the Aurora profile.
>
> I like the automagic sync idea only to a point - developers are going to
> tend to have different configurations / extensions / etc for a dev-centric
> browser.
>
> $0.02, Jeff
>
> ______________________________**_________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/**listinfo/dev-planning<https://lists.mozilla.org/listinfo/dev-planning>
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Gervase Markham
In reply to this post by Jeff Griffiths-4
On 22/10/13 16:00, Stormy Peters wrote:
> I think one change that would really help (suggested by choffman I believe)
> is to rename Aurora to something that implies that it is a developer or
> early release.

Er... Alpha? :-)

Gerv

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Eric Rescorla
We could be really unimaginative and call it "Dev"

-Ekr



On Wed, Oct 23, 2013 at 4:39 AM, Gervase Markham <[hidden email]> wrote:

> On 22/10/13 16:00, Stormy Peters wrote:
> > I think one change that would really help (suggested by choffman I
> believe)
> > is to rename Aurora to something that implies that it is a developer or
> > early release.
>
> Er... Alpha? :-)
>
> Gerv
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Coupled Train Model

Rob Campbell-5
"Minotaur".

On 2013-10-23, at 08:03 , Eric Rescorla <[hidden email]> wrote:

> We could be really unimaginative and call it "Dev"
>
> -Ekr
>
>
>
> On Wed, Oct 23, 2013 at 4:39 AM, Gervase Markham <[hidden email]> wrote:
>
>> On 22/10/13 16:00, Stormy Peters wrote:
>>> I think one change that would really help (suggested by choffman I
>> believe)
>>> is to rename Aurora to something that implies that it is a developer or
>>> early release.
>>
>> Er... Alpha? :-)
>>
>> Gerv
>>
>> _______________________________________________
>> dev-planning mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-planning
>>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12