Coupled Train Model v2

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Coupled Train Model v2

Alexander Keybl
I've tried to collect all of the feedback that's been provided by developers in the community (thanks!!), and put it on a new schedule. Here's my attempt: https://docs.google.com/spreadsheet/ccc?key=0Av9ejaFxk72tdHgwWS14d1NVbkFSd0xjZzRzNXl2VGc

It still accomplishes the same goals as the original Coupled Train Proposal (changing the time spent solely with Aurora, fewer Gecko versions in flight, overlapping beta/release for dot releases) but also has the added benefit of Aurora population testing throughout the development cycle.

Some notes:
* it assumes we perform nightly->aurora merges every ~2 weeks (this has impact to QA, so is not a final proposal)
* it assumes we'll change to a 9 week cycle (may not be the case when we decide on how to align with B2G)
* it assumes we'll have the ability to push RCs to the Beta channel by this point (incoming, thanks to RelEng)
* I'm looking at the schedule on the granularity of 1 week, for sake of visual sanity
* I threw this together fairly quickly, so there may still be mistakes
* This model assumes we'd kick off as of Firefox 32 on m-c to allow time for dust to settle around early B2G releases

-Alex
_______________________________________________
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 v2

Chris Peterson-12
hi Alex, your proposal looks very promising. I like that Aurora gets new
code sooner while also increasing Beta overlap and bake time.


On 10/24/13, 12:31 PM, Alex Keybl wrote:
> * it assumes we perform nightly->aurora merges every ~2 weeks (this has impact to QA, so is not a final proposal)

Why every 2 weeks instead of 1? To reduce the QA impact?


> * it assumes we'll change to a 9 week cycle (may not be the case when we decide on how to align with B2G)

Why a 9 week cycle instead of a multiple of 2 like 8? The ninth week
adds an unnecessary discontinuity to the nightly->aurora merge cycle. :)


cpeterson
_______________________________________________
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 v2

Alexander Keybl
> Why every 2 weeks instead of 1? To reduce the QA impact?

Correct, I'm guessing the Aurora mini-merges less than once a week due to QA bandwidth. Might not be the case.

>> * it assumes we'll change to a 9 week cycle (may not be the case when we decide on how to align with B2G)
>
> Why a 9 week cycle instead of a multiple of 2 like 8? The ninth week adds an unnecessary discontinuity to the nightly->aurora merge cycle. :)

A couple of reasons for 9 weeks:

* It maintains an 18 week end to end - code won't take longer to ship than today
* It juggles security (which would rather have a shorter cycle), l10n (who want more time to localize), and amount of time we need with our beta population to collect feedback (somewhere in between)

-Alex

On Oct 24, 2013, at 4:18 PM, Chris Peterson <[hidden email]> wrote:

> hi Alex, your proposal looks very promising. I like that Aurora gets new code sooner while also increasing Beta overlap and bake time.
>
>
> On 10/24/13, 12:31 PM, Alex Keybl wrote:
>> * it assumes we perform nightly->aurora merges every ~2 weeks (this has impact to QA, so is not a final proposal)
>
> Why every 2 weeks instead of 1? To reduce the QA impact?
>
>
>> * it assumes we'll change to a 9 week cycle (may not be the case when we decide on how to align with B2G)
>
> Why a 9 week cycle instead of a multiple of 2 like 8? The ninth week adds an unnecessary discontinuity to the nightly->aurora merge cycle. :)
>
>
> cpeterson
> _______________________________________________
> 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 v2

Nicolas B. Pierron
In reply to this post by Alexander Keybl
On 10/24/2013 12:31 PM, Alex Keybl wrote:

> I've tried to collect all of the feedback that's been provided by developers in the community (thanks!!), and put it on a new schedule. Here's my attempt: https://docs.google.com/spreadsheet/ccc?key=0Av9ejaFxk72tdHgwWS14d1NVbkFSd0xjZzRzNXl2VGc
>
> It still accomplishes the same goals as the original Coupled Train Proposal (changing the time spent solely with Aurora, fewer Gecko versions in flight, overlapping beta/release for dot releases) but also has the added benefit of Aurora population testing throughout the development cycle.
>
> Some notes:
> * it assumes we perform nightly->aurora merges every ~2 weeks (this has impact to QA, so is not a final proposal)
> * it assumes we'll change to a 9 week cycle (may not be the case when we decide on how to align with B2G)
> * it assumes we'll have the ability to push RCs to the Beta channel by this point (incoming, thanks to RelEng)
> * I'm looking at the schedule on the granularity of 1 week, for sake of visual sanity
> * I threw this together fairly quickly, so there may still be mistakes
> * This model assumes we'd kick off as of Firefox 32 on m-c to allow time for dust to settle around early B2G releases

I can understand the intent to have an overlap between Beta and Release, but
I am not sure to understand the usefulness of it between Aurora and Beta.
Couldn't we just let Aurora settle for the 2 last weeks and then merge once
into beta?

Just a side note, if we do only 3 merges from nightly to aurora, then we can
have a 2 weeks overlap without the inconsistency of the week 8 of nightly.

--
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 v2

Alexander Keybl
> I can understand the intent to have an overlap between Beta and Release, but I am not sure to understand the usefulness of it between Aurora and Beta. Couldn't we just let Aurora settle for the 2 last weeks and then merge once into beta?


The intent here would be to give QA the opportunity to confidently put out a beta without worrying about the next Aurora merge quite yet.  

> Just a side note, if we do only 3 merges from nightly to aurora, then we can have a 2 weeks overlap without the inconsistency of the week 8 of nightly.

We could consider this, but for sake of quality (as opposed to QA bandwidth), more merges is better.

-Alex

On Oct 24, 2013, at 4:28 PM, "Nicolas B. Pierron" <[hidden email]> wrote:

> On 10/24/2013 12:31 PM, Alex Keybl wrote:
>> I've tried to collect all of the feedback that's been provided by developers in the community (thanks!!), and put it on a new schedule. Here's my attempt: https://docs.google.com/spreadsheet/ccc?key=0Av9ejaFxk72tdHgwWS14d1NVbkFSd0xjZzRzNXl2VGc
>>
>> It still accomplishes the same goals as the original Coupled Train Proposal (changing the time spent solely with Aurora, fewer Gecko versions in flight, overlapping beta/release for dot releases) but also has the added benefit of Aurora population testing throughout the development cycle.
>>
>> Some notes:
>> * it assumes we perform nightly->aurora merges every ~2 weeks (this has impact to QA, so is not a final proposal)
>> * it assumes we'll change to a 9 week cycle (may not be the case when we decide on how to align with B2G)
>> * it assumes we'll have the ability to push RCs to the Beta channel by this point (incoming, thanks to RelEng)
>> * I'm looking at the schedule on the granularity of 1 week, for sake of visual sanity
>> * I threw this together fairly quickly, so there may still be mistakes
>> * This model assumes we'd kick off as of Firefox 32 on m-c to allow time for dust to settle around early B2G releases
>
> I can understand the intent to have an overlap between Beta and Release, but I am not sure to understand the usefulness of it between Aurora and Beta. Couldn't we just let Aurora settle for the 2 last weeks and then merge once into beta?
>
> Just a side note, if we do only 3 merges from nightly to aurora, then we can have a 2 weeks overlap without the inconsistency of the week 8 of nightly.
>
> --
> 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 v2

Lawrence Mandel-2
----- Original Message -----

> > I can understand the intent to have an overlap between Beta and Release,
> > but I am not sure to understand the usefulness of it between Aurora and
> > Beta. Couldn't we just let Aurora settle for the 2 last weeks and then
> > merge once into beta?
>
>
> The intent here would be to give QA the opportunity to confidently put out a
> beta without worrying about the next Aurora merge quite yet.
>
> > Just a side note, if we do only 3 merges from nightly to aurora, then we
> > can have a 2 weeks overlap without the inconsistency of the week 8 of
> > nightly.
>
> We could consider this, but for sake of quality (as opposed to QA bandwidth),
> more merges is better.

For this reason and to avoid Aurora diverging too much from Nightly and therefore, in this model, reducing the usefulness of testing, I would like to consider the weekly merge. As has been pointed out earlier, Aurora users are used to daily updates. Moving to weekly is already a significant reduction. My initial thought is we want to update Aurora more than bi-weekly.

Lawrence

>
> -Alex
>
> On Oct 24, 2013, at 4:28 PM, "Nicolas B. Pierron"
> <[hidden email]> wrote:
>
> > On 10/24/2013 12:31 PM, Alex Keybl wrote:
> >> I've tried to collect all of the feedback that's been provided by
> >> developers in the community (thanks!!), and put it on a new schedule.
> >> Here's my attempt:
> >> https://docs.google.com/spreadsheet/ccc?key=0Av9ejaFxk72tdHgwWS14d1NVbkFSd0xjZzRzNXl2VGc
> >>
> >> It still accomplishes the same goals as the original Coupled Train
> >> Proposal (changing the time spent solely with Aurora, fewer Gecko
> >> versions in flight, overlapping beta/release for dot releases) but also
> >> has the added benefit of Aurora population testing throughout the
> >> development cycle.
> >>
> >> Some notes:
> >> * it assumes we perform nightly->aurora merges every ~2 weeks (this has
> >> impact to QA, so is not a final proposal)
> >> * it assumes we'll change to a 9 week cycle (may not be the case when we
> >> decide on how to align with B2G)
> >> * it assumes we'll have the ability to push RCs to the Beta channel by
> >> this point (incoming, thanks to RelEng)
> >> * I'm looking at the schedule on the granularity of 1 week, for sake of
> >> visual sanity
> >> * I threw this together fairly quickly, so there may still be mistakes
> >> * This model assumes we'd kick off as of Firefox 32 on m-c to allow time
> >> for dust to settle around early B2G releases
> >
> > I can understand the intent to have an overlap between Beta and Release,
> > but I am not sure to understand the usefulness of it between Aurora and
> > Beta. Couldn't we just let Aurora settle for the 2 last weeks and then
> > merge once into beta?
> >
> > Just a side note, if we do only 3 merges from nightly to aurora, then we
> > can have a 2 weeks overlap without the inconsistency of the week 8 of
> > nightly.
> >
> > --
> > 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
>
_______________________________________________
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 v2

Chris Hofmann-2
In reply to this post by Alexander Keybl
On 10/24/13 12:31 PM, Alex Keybl wrote:

> I've tried to collect all of the feedback that's been provided by developers in the community (thanks!!), and put it on a new schedule. Here's my attempt: https://docs.google.com/spreadsheet/ccc?key=0Av9ejaFxk72tdHgwWS14d1NVbkFSd0xjZzRzNXl2VGc
>
> It still accomplishes the same goals as the original Coupled Train Proposal (changing the time spent solely with Aurora, fewer Gecko versions in flight, overlapping beta/release for dot releases) but also has the added benefit of Aurora population testing throughout the development cycle.
>
> Some notes:
> * it assumes we perform nightly->aurora merges every ~2 weeks (this has impact to QA, so is not a final proposal)
> * it assumes we'll change to a 9 week cycle (may not be the case when we decide on how to align with B2G)
> * it assumes we'll have the ability to push RCs to the Beta channel by this point (incoming, thanks to RelEng)
> * I'm looking at the schedule on the granularity of 1 week, for sake of visual sanity
> * I threw this together fairly quickly, so there may still be mistakes
> * This model assumes we'd kick off as of Firefox 32 on m-c to allow time for dust to settle around early B2G releases
>
> -Alex
>

Its hard for me to read what this means for a few important goals that I
think we often lose sight of.

1) Create system that impose more discipline and order on the
development process, taking high volume and frequent changes early, and
then reducing the number of changes as soon as possible, then
dramatically as we get closer to release. This kind of disapline allows
us to create the highest quality software possible and introduce it to
increasingly wider audiences and check at each stage.   That was the
basic principal behind the 100k, million, 10 million people on each of
the rapid release channels.

2) Create a solid baseline for the next release with all the changes we
intend to release (central and very early aurora)

3) then allow time localize and prepare for world wide release. (aurora,
and hopefully covered under a new firefox for web developer release)

4) Also check out that software with addon and web developers to ensure
compatibility, or give them time to adjust to new features, or report
back bugs.   (aurora, and hopefully covered under a new firefox for web
developer release)

5) When we are sure we have the highest quality in terms of
compatibility, stability, performance release to the biggest beta
audience we can muster, for as long as we possibly can test.  (beta)

6) When the beta audience tells us the software is great release it to
the rest of the world.

All the merging up, bug fix builds, and constant changes possibly
implied by the diagram makes me nervous about not paying attention to
these basic principals and needs.  Especially 2, 3, and 4.   It opens
opportunities to expose a lot of people to regresssions, and there by
possibly loosing those people as active testers at each stage of the
process.  It also makes it confusing about what we are trying to do at
each stage of the process other than just shoving software out to a lot
of people in anticipation of trying to get their feedback, and fixing
things as they seem busted.

-chofmann


_______________________________________________
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 v2

Karl Tomlinson-4
In reply to this post by Alexander Keybl
Lawrence Mandel writes:

>> > I can understand the intent to have an overlap between Beta and Release,
>> > but I am not sure to understand the usefulness of it between Aurora and
>> > Beta. Couldn't we just let Aurora settle for the 2 last weeks and then
>> > merge once into beta?
>>
>> The intent here would be to give QA the opportunity to confidently put out a
>> beta without worrying about the next Aurora merge quite yet.
>>
>> > Just a side note, if we do only 3 merges from nightly to aurora, then we
>> > can have a 2 weeks overlap without the inconsistency of the week 8 of
>> > nightly.
>>
>> We could consider this, but for sake of quality (as opposed to QA bandwidth),
>> more merges is better.
>
> For this reason and to avoid Aurora diverging too much from
> Nightly and therefore, in this model, reducing the usefulness of
> testing, I would like to consider the weekly merge. As has been
> pointed out earlier, Aurora users are used to daily
> updates. Moving to weekly is already a significant reduction. My
> initial thought is we want to update Aurora more than bi-weekly.

I assume fixes can still land on aurora with approval.

Skipping the merge from nightly to aurora at the end of week 9
would mean no last minute features, but it would still receive
fixes before going to beta, increasing the settling/fixing time
from 1 to 2 weeks, and so *increasing* quality on beta.

Also skipping the merge at the end of week 8 would increase
quality further by increasing fixing time to 4 weeks.
_______________________________________________
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 v2

Axel Hecht
In reply to this post by Alexander Keybl
On behalf of l10n, I veto this proposal.

This is not a modification of our existing release schedule, it's merely
reusing a few words with completely different meaning.

Aurora in the current scheme is the most powerful tool we have to
deliver localized software, and there's nothing left of that that matters.

It just won't create localized software, and honestly, I don't have to
prove that it doesn't. You have to prove that it would.

Axel

On 10/24/13 9:31 PM, Alex Keybl wrote:

> I've tried to collect all of the feedback that's been provided by developers in the community (thanks!!), and put it on a new schedule. Here's my attempt: https://docs.google.com/spreadsheet/ccc?key=0Av9ejaFxk72tdHgwWS14d1NVbkFSd0xjZzRzNXl2VGc
>
> It still accomplishes the same goals as the original Coupled Train Proposal (changing the time spent solely with Aurora, fewer Gecko versions in flight, overlapping beta/release for dot releases) but also has the added benefit of Aurora population testing throughout the development cycle.
>
> Some notes:
> * it assumes we perform nightly->aurora merges every ~2 weeks (this has impact to QA, so is not a final proposal)
> * it assumes we'll change to a 9 week cycle (may not be the case when we decide on how to align with B2G)
> * it assumes we'll have the ability to push RCs to the Beta channel by this point (incoming, thanks to RelEng)
> * I'm looking at the schedule on the granularity of 1 week, for sake of visual sanity
> * I threw this together fairly quickly, so there may still be mistakes
> * This model assumes we'd kick off as of Firefox 32 on m-c to allow time for dust to settle around early B2G releases
>
> -Alex

_______________________________________________
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 v2

Alexander Keybl
In reply to this post by Chris Hofmann-2
I'll try to address 2, 3, and 4 since you feel these are the largest holes in the proposal.

Can you clarify #2? What do you believe constitutes a solid baseline, and in what ways do you feel this proposal changes that?

#3 obviously still needs consensus, but I'm optimistic we can work something out.

Jorge has already addressed #4 for add-on developers, who suggests that they will welcome these changes. The lengthened cycle with Beta users will mitigate any website bustage, since we don't typically hear about them until Beta anyway.

The idea is to get our code out to as many pre-release users as early as possible without breaking our quality contract with them. My team has looked at tracking bugs to evaluate how many would block beta after a week on Aurora, and we found none. I also do not see how more frequent central to Aurora merges would be of significantly lower quality when it's basically the same process that we accomplish once a cycle, just with less code change.

-Alex

----- Original Message -----
From: Chris Hofmann <[hidden email]>
To: Alex Keybl <[hidden email]>, [hidden email] group <[hidden email]>
Sent: Thu, 24 Oct 2013 15:10:45 -0700 (PDT)
Subject: Re: Coupled Train Model v2

On 10/24/13 12:31 PM, Alex Keybl wrote:

> I've tried to collect all of the feedback that's been provided by developers in the community (thanks!!), and put it on a new schedule. Here's my attempt: https://docs.google.com/spreadsheet/ccc?key=0Av9ejaFxk72tdHgwWS14d1NVbkFSd0xjZzRzNXl2VGc
>
> It still accomplishes the same goals as the original Coupled Train Proposal (changing the time spent solely with Aurora, fewer Gecko versions in flight, overlapping beta/release for dot releases) but also has the added benefit of Aurora population testing throughout the development cycle.
>
> Some notes:
> * it assumes we perform nightly->aurora merges every ~2 weeks (this has impact to QA, so is not a final proposal)
> * it assumes we'll change to a 9 week cycle (may not be the case when we decide on how to align with B2G)
> * it assumes we'll have the ability to push RCs to the Beta channel by this point (incoming, thanks to RelEng)
> * I'm looking at the schedule on the granularity of 1 week, for sake of visual sanity
> * I threw this together fairly quickly, so there may still be mistakes
> * This model assumes we'd kick off as of Firefox 32 on m-c to allow time for dust to settle around early B2G releases
>
> -Alex
>

Its hard for me to read what this means for a few important goals that I
think we often lose sight of.

1) Create system that impose more discipline and order on the
development process, taking high volume and frequent changes early, and
then reducing the number of changes as soon as possible, then
dramatically as we get closer to release. This kind of disapline allows
us to create the highest quality software possible and introduce it to
increasingly wider audiences and check at each stage. That was the
basic principal behind the 100k, million, 10 million people on each of
the rapid release channels.

2) Create a solid baseline for the next release with all the changes we
intend to release (central and very early aurora)

3) then allow time localize and prepare for world wide release. (aurora,
and hopefully covered under a new firefox for web developer release)

4) Also check out that software with addon and web developers to ensure
compatibility, or give them time to adjust to new features, or report
back bugs. (aurora, and hopefully covered under a new firefox for web
developer release)

5) When we are sure we have the highest quality in terms of
compatibility, stability, performance release to the biggest beta
audience we can muster, for as long as we possibly can test. (beta)

6) When the beta audience tells us the software is great release it to
the rest of the world.

All the merging up, bug fix builds, and constant changes possibly
implied by the diagram makes me nervous about not paying attention to
these basic principals and needs. Especially 2, 3, and 4. It opens
opportunities to expose a lot of people to regresssions, and there by
possibly loosing those people as active testers at each stage of the
process. It also makes it confusing about what we are trying to do at
each stage of the process other than just shoving software out to a lot
of people in anticipation of trying to get their feedback, and fixing
things as they seem busted.

-chofmann



_______________________________________________
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 v2

Alexander Keybl
In reply to this post by Karl Tomlinson-4
Correct, Aurora approvals between merges will improve quality over each N week mini cycle.

-Alex

----- Original Message -----
From: Karl Tomlinson <[hidden email]>
To: [hidden email]
Sent: Thu, 24 Oct 2013 15:14:44 -0700 (PDT)
Subject: Re: Coupled Train Model v2

Lawrence Mandel writes:

>> > I can understand the intent to have an overlap between Beta and Release,
>> > but I am not sure to understand the usefulness of it between Aurora and
>> > Beta. Couldn't we just let Aurora settle for the 2 last weeks and then
>> > merge once into beta?
>>
>> The intent here would be to give QA the opportunity to confidently put out a
>> beta without worrying about the next Aurora merge quite yet.
>>
>> > Just a side note, if we do only 3 merges from nightly to aurora, then we
>> > can have a 2 weeks overlap without the inconsistency of the week 8 of
>> > nightly.
>>
>> We could consider this, but for sake of quality (as opposed to QA bandwidth),
>> more merges is better.
>
> For this reason and to avoid Aurora diverging too much from
> Nightly and therefore, in this model, reducing the usefulness of
> testing, I would like to consider the weekly merge. As has been
> pointed out earlier, Aurora users are used to daily
> updates. Moving to weekly is already a significant reduction. My
> initial thought is we want to update Aurora more than bi-weekly.

I assume fixes can still land on aurora with approval.

Skipping the merge from nightly to aurora at the end of week 9
would mean no last minute features, but it would still receive
fixes before going to beta, increasing the settling/fixing time
from 1 to 2 weeks, and so *increasing* quality on beta.

Also skipping the merge at the end of week 8 would increase
quality further by increasing fixing time to 4 weeks.
_______________________________________________
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 v2

Chris Hofmann-3
In reply to this post by Alexander Keybl
On 10/25/13 7:50 AM, Alexander Keybl wrote:
> I'll try to address 2, 3, and 4 since you feel these are the largest holes in the proposal.
>
> Can you clarify #2? What do you believe constitutes a solid baseline, and in what ways do you feel this proposal changes that?

One in which we have stopped adding features to.  One in which we have
seen a decline in the number of changes, number of regressions found and
fixed, and for which we have enough time to gather good crash and other
feedback data (about a week or so).

If I read the proposal and the diagram right its mostly a constant
changing piece of software that is harder to localize, gain an
understanding of the state of the software, and harder to measure
feedback and quality since its under change.

-chofmann

>
> #3 obviously still needs consensus, but I'm optimistic we can work something out.
>
> Jorge has already addressed #4 for add-on developers, who suggests that they will welcome these changes. The lengthened cycle with Beta users will mitigate any website bustage, since we don't typically hear about them until Beta anyway.
>
> The idea is to get our code out to as many pre-release users as early as possible without breaking our quality contract with them. My team has looked at tracking bugs to evaluate how many would block beta after a week on Aurora, and we found none. I also do not see how more frequent central to Aurora merges would be of significantly lower quality when it's basically the same process that we accomplish once a cycle, just with less code change.
>
> -Alex
>
> ----- Original Message -----
> From: Chris Hofmann <[hidden email]>
> To: Alex Keybl <[hidden email]>, [hidden email] group <[hidden email]>
> Sent: Thu, 24 Oct 2013 15:10:45 -0700 (PDT)
> Subject: Re: Coupled Train Model v2
>
> On 10/24/13 12:31 PM, Alex Keybl wrote:
>> I've tried to collect all of the feedback that's been provided by developers in the community (thanks!!), and put it on a new schedule. Here's my attempt: https://docs.google.com/spreadsheet/ccc?key=0Av9ejaFxk72tdHgwWS14d1NVbkFSd0xjZzRzNXl2VGc
>>
>> It still accomplishes the same goals as the original Coupled Train Proposal (changing the time spent solely with Aurora, fewer Gecko versions in flight, overlapping beta/release for dot releases) but also has the added benefit of Aurora population testing throughout the development cycle.
>>
>> Some notes:
>> * it assumes we perform nightly->aurora merges every ~2 weeks (this has impact to QA, so is not a final proposal)
>> * it assumes we'll change to a 9 week cycle (may not be the case when we decide on how to align with B2G)
>> * it assumes we'll have the ability to push RCs to the Beta channel by this point (incoming, thanks to RelEng)
>> * I'm looking at the schedule on the granularity of 1 week, for sake of visual sanity
>> * I threw this together fairly quickly, so there may still be mistakes
>> * This model assumes we'd kick off as of Firefox 32 on m-c to allow time for dust to settle around early B2G releases
>>
>> -Alex
>>
> Its hard for me to read what this means for a few important goals that I
> think we often lose sight of.
>
> 1) Create system that impose more discipline and order on the
> development process, taking high volume and frequent changes early, and
> then reducing the number of changes as soon as possible, then
> dramatically as we get closer to release. This kind of disapline allows
> us to create the highest quality software possible and introduce it to
> increasingly wider audiences and check at each stage. That was the
> basic principal behind the 100k, million, 10 million people on each of
> the rapid release channels.
>
> 2) Create a solid baseline for the next release with all the changes we
> intend to release (central and very early aurora)
>
> 3) then allow time localize and prepare for world wide release. (aurora,
> and hopefully covered under a new firefox for web developer release)
>
> 4) Also check out that software with addon and web developers to ensure
> compatibility, or give them time to adjust to new features, or report
> back bugs. (aurora, and hopefully covered under a new firefox for web
> developer release)
>
> 5) When we are sure we have the highest quality in terms of
> compatibility, stability, performance release to the biggest beta
> audience we can muster, for as long as we possibly can test. (beta)
>
> 6) When the beta audience tells us the software is great release it to
> the rest of the world.
>
> All the merging up, bug fix builds, and constant changes possibly
> implied by the diagram makes me nervous about not paying attention to
> these basic principals and needs. Especially 2, 3, and 4. It opens
> opportunities to expose a lot of people to regresssions, and there by
> possibly loosing those people as active testers at each stage of the
> process. It also makes it confusing about what we are trying to do at
> each stage of the process other than just shoving software out to a lot
> of people in anticipation of trying to get their feedback, and fixing
> things as they seem busted.
>
> -chofmann
>
>
>
> _______________________________________________
> 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 v2

Alexander Keybl
We're going to be stricter about feature backouts around merges, for sure, and the early and frequent Aurora population feedback will go a long way to guide those decisions. Using Aurora as time padding to make those decisions shouldn't be necessary.

-Alex

----- Original Message -----
From: chris hofmann <[hidden email]>
To: Alexander Keybl <[hidden email]>, [hidden email]
Cc: [hidden email] group <[hidden email]>
Sent: Fri, 25 Oct 2013 08:02:31 -0700 (PDT)
Subject: Re: Coupled Train Model v2

On 10/25/13 7:50 AM, Alexander Keybl wrote:
> I'll try to address 2, 3, and 4 since you feel these are the largest holes in the proposal.
>
> Can you clarify #2? What do you believe constitutes a solid baseline, and in what ways do you feel this proposal changes that?

One in which we have stopped adding features to. One in which we have
seen a decline in the number of changes, number of regressions found and
fixed, and for which we have enough time to gather good crash and other
feedback data (about a week or so).

If I read the proposal and the diagram right its mostly a constant
changing piece of software that is harder to localize, gain an
understanding of the state of the software, and harder to measure
feedback and quality since its under change.

-chofmann

>
> #3 obviously still needs consensus, but I'm optimistic we can work something out.
>
> Jorge has already addressed #4 for add-on developers, who suggests that they will welcome these changes. The lengthened cycle with Beta users will mitigate any website bustage, since we don't typically hear about them until Beta anyway.
>
> The idea is to get our code out to as many pre-release users as early as possible without breaking our quality contract with them. My team has looked at tracking bugs to evaluate how many would block beta after a week on Aurora, and we found none. I also do not see how more frequent central to Aurora merges would be of significantly lower quality when it's basically the same process that we accomplish once a cycle, just with less code change.
>
> -Alex
>
> ----- Original Message -----
> From: Chris Hofmann <[hidden email]>
> To: Alex Keybl <[hidden email]>, [hidden email] group <[hidden email]>
> Sent: Thu, 24 Oct 2013 15:10:45 -0700 (PDT)
> Subject: Re: Coupled Train Model v2
>
> On 10/24/13 12:31 PM, Alex Keybl wrote:
>> I've tried to collect all of the feedback that's been provided by developers in the community (thanks!!), and put it on a new schedule. Here's my attempt: https://docs.google.com/spreadsheet/ccc?key=0Av9ejaFxk72tdHgwWS14d1NVbkFSd0xjZzRzNXl2VGc
>>
>> It still accomplishes the same goals as the original Coupled Train Proposal (changing the time spent solely with Aurora, fewer Gecko versions in flight, overlapping beta/release for dot releases) but also has the added benefit of Aurora population testing throughout the development cycle.
>>
>> Some notes:
>> * it assumes we perform nightly->aurora merges every ~2 weeks (this has impact to QA, so is not a final proposal)
>> * it assumes we'll change to a 9 week cycle (may not be the case when we decide on how to align with B2G)
>> * it assumes we'll have the ability to push RCs to the Beta channel by this point (incoming, thanks to RelEng)
>> * I'm looking at the schedule on the granularity of 1 week, for sake of visual sanity
>> * I threw this together fairly quickly, so there may still be mistakes
>> * This model assumes we'd kick off as of Firefox 32 on m-c to allow time for dust to settle around early B2G releases
>>
>> -Alex
>>
> Its hard for me to read what this means for a few important goals that I
> think we often lose sight of.
>
> 1) Create system that impose more discipline and order on the
> development process, taking high volume and frequent changes early, and
> then reducing the number of changes as soon as possible, then
> dramatically as we get closer to release. This kind of disapline allows
> us to create the highest quality software possible and introduce it to
> increasingly wider audiences and check at each stage. That was the
> basic principal behind the 100k, million, 10 million people on each of
> the rapid release channels.
>
> 2) Create a solid baseline for the next release with all the changes we
> intend to release (central and very early aurora)
>
> 3) then allow time localize and prepare for world wide release. (aurora,
> and hopefully covered under a new firefox for web developer release)
>
> 4) Also check out that software with addon and web developers to ensure
> compatibility, or give them time to adjust to new features, or report
> back bugs. (aurora, and hopefully covered under a new firefox for web
> developer release)
>
> 5) When we are sure we have the highest quality in terms of
> compatibility, stability, performance release to the biggest beta
> audience we can muster, for as long as we possibly can test. (beta)
>
> 6) When the beta audience tells us the software is great release it to
> the rest of the world.
>
> All the merging up, bug fix builds, and constant changes possibly
> implied by the diagram makes me nervous about not paying attention to
> these basic principals and needs. Especially 2, 3, and 4. It opens
> opportunities to expose a lot of people to regresssions, and there by
> possibly loosing those people as active testers at each stage of the
> process. It also makes it confusing about what we are trying to do at
> each stage of the process other than just shoving software out to a lot
> of people in anticipation of trying to get their feedback, and fixing
> things as they seem busted.
>
> -chofmann
>
>
>
> _______________________________________________
> 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 v2

Chris Peterson-12
In reply to this post by Axel Hecht
On 10/25/13, 4:19 AM, Axel Hecht wrote:
> Aurora in the current scheme is the most powerful tool we have to
> deliver localized software, and there's nothing left of that that matters.

hi Alex, for those of us that are not familiar with Firefox's
localization workflow, can you briefly describe the timeline for a new
feature's localization?

Neither of these recent train proposals have a good answer for string
freezes or localization time.

What are the average and longtail of localization times? Are most
features localization-complete before Beta? Our localizers are tireless
volunteers, so some locales are probably completed much more quickly
than others.


thanks,
chris
_______________________________________________
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 v2

Alexander Keybl
I'd actually prefer to hear typical timelines, average l10n complete % at Nightly->Aurora and Aurora->Beta, etc. from the l10n team since I don't have that data. Agreed this would be great data to tweak the model.

-Alex

On Oct 25, 2013, at 1:06 PM, Chris Peterson <[hidden email]> wrote:

> On 10/25/13, 4:19 AM, Axel Hecht wrote:
>> Aurora in the current scheme is the most powerful tool we have to
>> deliver localized software, and there's nothing left of that that matters.
>
> hi Alex, for those of us that are not familiar with Firefox's localization workflow, can you briefly describe the timeline for a new feature's localization?
>
> Neither of these recent train proposals have a good answer for string freezes or localization time.
>
> What are the average and longtail of localization times? Are most features localization-complete before Beta? Our localizers are tireless volunteers, so some locales are probably completed much more quickly than others.
>
>
> thanks,
> chris
> _______________________________________________
> 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 v2

Alexander Keybl
In reply to this post by Alexander Keybl
To give a couple of examples of anecdotal evidence as to why we should really be considering a longer beta cycle, we just ran into https://bugzilla.mozilla.org/show_bug.cgi?id=927901 in the last week of FF25's beta after we'd already spun our RC for FF25. My conversation with dougt:

> 1:16 PM <akeybl> is this a breakdown of pre-release user testing?
> 1:17 PM <akeybl> if we think we need to respin for this, we obviously need to lengthen the beta cycle
> 1:17 PM <akeybl> because there's no other way to find/fix in time
> 1:17 PM <dougt> i think you want to remove m-a, and make beta longer
> 1:18 PM <akeybl> we're doing something similar in that Couple Train Model thread on dev.planning

On a separate note, in terms of Aurora vs Beta user feedback:

> 1:18 PM <dougt> johns tells me all of the time he only hears about plugin bugs in beta
> 1:18 PM <dougt> so, basically he fixes stuff, forgets about the fixes for 6 weeks, then gets a bunch of new bug reports about the stuff he forgot about :)

Seems like all the more reason to pursue this model, allow devs to focus on fewer Gecko versions, and provide them with more feedback earlier in the release.

-Alex

On Oct 24, 2013, at 3:31 PM, Alex Keybl <[hidden email]> wrote:

> I've tried to collect all of the feedback that's been provided by developers in the community (thanks!!), and put it on a new schedule. Here's my attempt: https://docs.google.com/spreadsheet/ccc?key=0Av9ejaFxk72tdHgwWS14d1NVbkFSd0xjZzRzNXl2VGc
>
> It still accomplishes the same goals as the original Coupled Train Proposal (changing the time spent solely with Aurora, fewer Gecko versions in flight, overlapping beta/release for dot releases) but also has the added benefit of Aurora population testing throughout the development cycle.
>
> Some notes:
> * it assumes we perform nightly->aurora merges every ~2 weeks (this has impact to QA, so is not a final proposal)
> * it assumes we'll change to a 9 week cycle (may not be the case when we decide on how to align with B2G)
> * it assumes we'll have the ability to push RCs to the Beta channel by this point (incoming, thanks to RelEng)
> * I'm looking at the schedule on the granularity of 1 week, for sake of visual sanity
> * I threw this together fairly quickly, so there may still be mistakes
> * This model assumes we'd kick off as of Firefox 32 on m-c to allow time for dust to settle around early B2G releases
>
> -Alex
> _______________________________________________
> 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 v2

Axel Hecht
In reply to this post by Chris Peterson-12
On 10/25/13 7:06 PM, Chris Peterson wrote:
> On 10/25/13, 4:19 AM, Axel Hecht wrote:
>> Aurora in the current scheme is the most powerful tool we have to
>> deliver localized software, and there's nothing left of that that
>> matters.
>
> hi Alex, for those of us that are not familiar with Firefox's
> localization workflow, can you briefly describe the timeline for a new
> feature's localization?
>
I'm taking this as an "Axel" question.

I'll need to turn this question around a bit. Feature-based l10n is
something that a few communities do. The large-scale effort we're doing
is working on code dumps. Someone (not me) goes in, imports our string
into the db of a webtool, localizers work on that, someone (same not me)
exports that to a hg repo, commits, nags me and Jeff.

In our current release process, we're putting out a statement of work to
our l10n community every six weeks. That's the thing we're exposing on
the aurora channel.

The localization teams have some 5 1/2 weeks to get to work on that.

The actual work to get from English to localized strings is probably
less than a day.

What really makes localizing aurora attractive today is that a localizer
can occasionally scratch their itch and attend mozilla l10n. And they'll
spend a few hours, and they can be confident that their work creates a
good product for the officially released product. They'll watch
community feedback, and they'll know if they need to get back to it or not.


*The challenge to put out is*:

In the proposal, what's the value of contributing to aurora l10n for 7
out of the 9 weeks?

My concern is that this can be anything between zero and hero, depending
on what lands in the last merge. The l10n contributor seems to have
little impact on that. If the first 7 weeks were https elliptic curve
stuff, and the last merge impacts the file menu, your l10n work sucks.
The l10n-drivers team has a lot of feedback that localizers are
optimizing for what happens at the end of the cycle.

I'd love a change to our release schedule that gave me more leverage to
get l10n teams to work early in the cycle.

> Neither of these recent train proposals have a good answer for string
> freezes or localization time.
> What are the average and longtail of localization times? Are most
> features localization-complete before Beta? Our localizers are
> tireless volunteers, so some locales are probably completed much more
> quickly than others.
Thanks, in particular on behalf of the many teams that are active early.

The aspect that I'd like to put front and center here is contributor
experience. What we have today is: A string localized in aurora is a
string localized in release. At the point you contribute, you can
evaluate the impact of your contributions to the released product.

In the Model v2, neither of those hold. The strings that an l10n
contributor localized in week 1-7 don't represent the strings that users
gonna see in release.

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 v2

Chris Peterson-12
On 10/25/13, 4:44 PM, Axel Hecht wrote:
> In our current release process, we're putting out a statement of work to
> our l10n community every six weeks. That's the thing we're exposing on
> the aurora channel.
>
> The localization teams have some 5 1/2 weeks to get to work on that.
>
> The actual work to get from English to localized strings is probably
> less than a day.

hi Axel, thanks for the explanation. I see how sustaining a community of
l10n contributors is different than hiring contractors to do a job.

Today, contributors don't use all 6 weeks on Aurora for localizing, but
the time gives them flexibility to schedule *when* they do the
localization. And Aurora is always open, so new l10n projects can start
any time.

While the coupled Aurora/Beta train model (with a 2 week Aurora) might
*technically* be enough time to localize, we would be asking
contributors to rush for 2 weeks and then not provide them much
opportunity for contributing during the other 7 weeks of the cycle.

Chrome can impose code freezes on developers and hire an army of l10n
contractors to rush as the end of the cycle. Mozilla can't do that if
developers need mozilla-central to always be open for checkins and the
l10n community needs complete string dumps and flexible scheduling.
Aurora is Mozilla's code and string freeze.


chris
_______________________________________________
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 v2

Alexander Keybl
In reply to this post by Axel Hecht
In my response to Chris, I noted that we will be much stricter about feature backout based upon QA testing both during development and upon the final merge to Aurora before Beta. That saves about 7 weeks to localize (forget the week before release). That's obviously less time than today. But the real question is, can we agree on an acceptable beta string quality (perhaps lower than today) and can we tweak the process to ensure the same release quality at the end of the day.

I think the main piece of data we're missing is the % completion of string translation upon the current Aurora to Beta merge and the Beta to Release merge. That data will be very telling, and help us to understand what our targets need to be.

As noted previously, we've never blocked an Aurora to Beta merge based upon localization completeness, so I'm hoping we can focus on Release localization completeness instead.

-Alex

----- Original Message -----
From: Axel Hecht <[hidden email]>
To: [hidden email]
Sent: Fri, 25 Oct 2013 16:44:48 -0700 (PDT)
Subject: Re: Coupled Train Model v2

On 10/25/13 7:06 PM, Chris Peterson wrote:
> On 10/25/13, 4:19 AM, Axel Hecht wrote:
>> Aurora in the current scheme is the most powerful tool we have to
>> deliver localized software, and there's nothing left of that that
>> matters.
>
> hi Alex, for those of us that are not familiar with Firefox's
> localization workflow, can you briefly describe the timeline for a new
> feature's localization?
>
I'm taking this as an "Axel" question.

I'll need to turn this question around a bit. Feature-based l10n is
something that a few communities do. The large-scale effort we're doing
is working on code dumps. Someone (not me) goes in, imports our string
into the db of a webtool, localizers work on that, someone (same not me)
exports that to a hg repo, commits, nags me and Jeff.

In our current release process, we're putting out a statement of work to
our l10n community every six weeks. That's the thing we're exposing on
the aurora channel.

The localization teams have some 5 1/2 weeks to get to work on that.

The actual work to get from English to localized strings is probably
less than a day.

What really makes localizing aurora attractive today is that a localizer
can occasionally scratch their itch and attend mozilla l10n. And they'll
spend a few hours, and they can be confident that their work creates a
good product for the officially released product. They'll watch
community feedback, and they'll know if they need to get back to it or not.


*The challenge to put out is*:

In the proposal, what's the value of contributing to aurora l10n for 7
out of the 9 weeks?

My concern is that this can be anything between zero and hero, depending
on what lands in the last merge. The l10n contributor seems to have
little impact on that. If the first 7 weeks were https elliptic curve
stuff, and the last merge impacts the file menu, your l10n work sucks.
The l10n-drivers team has a lot of feedback that localizers are
optimizing for what happens at the end of the cycle.

I'd love a change to our release schedule that gave me more leverage to
get l10n teams to work early in the cycle.

> Neither of these recent train proposals have a good answer for string
> freezes or localization time.
> What are the average and longtail of localization times? Are most
> features localization-complete before Beta? Our localizers are
> tireless volunteers, so some locales are probably completed much more
> quickly than others.
Thanks, in particular on behalf of the many teams that are active early.

The aspect that I'd like to put front and center here is contributor
experience. What we have today is: A string localized in aurora is a
string localized in release. At the point you contribute, you can
evaluate the impact of your contributions to the released product.

In the Model v2, neither of those hold. The strings that an l10n
contributor localized in week 1-7 don't represent the strings that users
gonna see in release.

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 v2

Axel Hecht
In reply to this post by Axel Hecht
Sorry, but here's going to be a metric shitload of data:

We had ~70 people pushing to Firefox 25, 23 on central, 58 on aurora, 38
on beta. There were 19 active locales on central, 75 on aurora, 35 on
beta. 35 is surprisingly also the number of localizations that have
recently got non-merge-or-release pushes.

To slice the data differently:

The count of locales that are currently tracking are roughly ~80.

We have less-than 20 locales on central.

We have some 40-50 locales that are translating through pootle,
https://mozilla.locamotion.org/. That's where we're making numbers these
days.
Those don't interact with version control themselves, but only come into
our repositories through mentors, mostly Dwayne. That means, there's on
person in the 58 people mentioned above that stands for half our our
localizations in the data I have.
They're only exposed to aurora, the beta repositories don't even show
up. There's benefit to that. People showing up to contribute don't need
to figure out what they want to contribute to, they just pick "Firefox",
and know their work is good. Some activity stats, based on which of his
irregular landings picked up changes from his system: 1 landings for 9
localizations, 2 for 10, 3 for 4 and 4 landing for 4 localizations, 6
and 7 landings for one locale only. One third/one half of Dwayne's
ecosystem are actually one-hit wonders per cycle. I bet some of those
are actually follow-ups for technical problems, but I don't know how to
pick them right now.


Bottom line: The bread and butter of Firefox localization is working on
a single contribution channel, many of which contribute once or twice
per cycle.

I've focused this post on contribution metrics, mostly because I think
they matter most. Engaged people with rewarding contribution patterns
are most likely to create good products. I realize that I'm not talking
about completion metrics at all. They've sadly lost their meaning over
the course of the past releases, one devtool by the other. One third of
the Firefox user interface is actually developer interface, and that
follows different rules. Getting back comparable completion metrics is
something we've started talking about, but we're not close.

Now I'm taking a deep breath and send out just the data. If you're
interested in different slices or sets or patterns, feel free to ping
me, I'll try best to find something in the data that I have that's close.

I'll add my personal opinions on how the v2 proposal affects the
contribution patterns in a follow-up.

Axel

On 10/28/13 1:34 PM, Alexander Keybl wrote:

> In my response to Chris, I noted that we will be much stricter about feature backout based upon QA testing both during development and upon the final merge to Aurora before Beta. That saves about 7 weeks to localize (forget the week before release). That's obviously less time than today. But the real question is, can we agree on an acceptable beta string quality (perhaps lower than today) and can we tweak the process to ensure the same release quality at the end of the day.
>
> I think the main piece of data we're missing is the % completion of string translation upon the current Aurora to Beta merge and the Beta to Release merge. That data will be very telling, and help us to understand what our targets need to be.
>
> As noted previously, we've never blocked an Aurora to Beta merge based upon localization completeness, so I'm hoping we can focus on Release localization completeness instead.
>
> -Alex
>
> ----- Original Message -----
> From: Axel Hecht <[hidden email]>
> To: [hidden email]
> Sent: Fri, 25 Oct 2013 16:44:48 -0700 (PDT)
> Subject: Re: Coupled Train Model v2
>
> On 10/25/13 7:06 PM, Chris Peterson wrote:
>> On 10/25/13, 4:19 AM, Axel Hecht wrote:
>>> Aurora in the current scheme is the most powerful tool we have to
>>> deliver localized software, and there's nothing left of that that
>>> matters.
>> hi Alex, for those of us that are not familiar with Firefox's
>> localization workflow, can you briefly describe the timeline for a new
>> feature's localization?
>>
> I'm taking this as an "Axel" question.
>
> I'll need to turn this question around a bit. Feature-based l10n is
> something that a few communities do. The large-scale effort we're doing
> is working on code dumps. Someone (not me) goes in, imports our string
> into the db of a webtool, localizers work on that, someone (same not me)
> exports that to a hg repo, commits, nags me and Jeff.
>
> In our current release process, we're putting out a statement of work to
> our l10n community every six weeks. That's the thing we're exposing on
> the aurora channel.
>
> The localization teams have some 5 1/2 weeks to get to work on that.
>
> The actual work to get from English to localized strings is probably
> less than a day.
>
> What really makes localizing aurora attractive today is that a localizer
> can occasionally scratch their itch and attend mozilla l10n. And they'll
> spend a few hours, and they can be confident that their work creates a
> good product for the officially released product. They'll watch
> community feedback, and they'll know if they need to get back to it or not.
>
>
> *The challenge to put out is*:
>
> In the proposal, what's the value of contributing to aurora l10n for 7
> out of the 9 weeks?
>
> My concern is that this can be anything between zero and hero, depending
> on what lands in the last merge. The l10n contributor seems to have
> little impact on that. If the first 7 weeks were https elliptic curve
> stuff, and the last merge impacts the file menu, your l10n work sucks.
> The l10n-drivers team has a lot of feedback that localizers are
> optimizing for what happens at the end of the cycle.
>
> I'd love a change to our release schedule that gave me more leverage to
> get l10n teams to work early in the cycle.
>
>> Neither of these recent train proposals have a good answer for string
>> freezes or localization time.
>> What are the average and longtail of localization times? Are most
>> features localization-complete before Beta? Our localizers are
>> tireless volunteers, so some locales are probably completed much more
>> quickly than others.
> Thanks, in particular on behalf of the many teams that are active early.
>
> The aspect that I'd like to put front and center here is contributor
> experience. What we have today is: A string localized in aurora is a
> string localized in release. At the point you contribute, you can
> evaluate the impact of your contributions to the released product.
>
> In the Model v2, neither of those hold. The strings that an l10n
> contributor localized in week 1-7 don't represent the strings that users
> gonna see in release.
>
> 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
123