Planning (and triaging) for 1.9.3 alphas

The first issue is figuring out what bugs block us from shipping an
alpha release. We currently (see query links on the above page)
have 232 blocking1.9.3:? nominations, and also 13 bugs that are
currently blocking1.9.3:alpha1 (some of which I'm skeptical really
block). If component leads could triage these nominations in the
next week (particularly to find those that block alpha1), that would
be extremely helpful.

Doing blocking triage with the new flags (blocks-alpha1,
blocks-beta1, blocks-final, does-not-block) may pose some
challenges; I don't think it's something we've tried before while on
trunk and well in advance of any release. However, I expect it to
be straightforward for regressions, and hopefully straightforward
for bugs in new features that have already landed. It might be more
difficult for nominations representing features that might become
critical features for a release. However, the number of such
nominations is probably small, and it's not critical that they be
evaluated before we ship the first alpha of 1.9.3.

Please realize that an alpha release is expected to be at a quality
level representing a stabilized trunk nightly: we should block
alphas on things that are obstacles to testing the changes we want
tested or are major regressions that would prevent people from using
the builds. In most cases, we should not block on completing
particular features or particular high-risk changes, which can
always be in the next alpha instead.

Second, I'm gathering a list of changes we want testing on, and what
testing we want for those features, both for this alpha and for
future alphas. The list so far is the bulk of the content of
https://wiki.mozilla.org/User:Dbaron/1.9.3_AlphaPlease add to this list any features that:
* are not in Firefox 3.6 / Gecko 1.9.2
* are significant enough that we'd want to either:
+ direct testing or attention to them in release notes for an
alpha release
+ consider them when deciding how to schedule alpha releases
* have already landed on mozilla-central or are expected to land on
mozilla-central in the next few months
I hope that this list will be useful both for (a) publicizing what's
in the alpha releases we do and what testing we want and (b)
planning the schedule of future alphas.

Re: Planning (and triaging) for 1.9.3 alphas

On 1/22/2010 2:02 PM, L. David Baron wrote:

> Second, I'm gathering a list of changes we want testing on, and what
> testing we want for those features, both for this alpha and for
> future alphas. The list so far is the bulk of the content of
> https://wiki.mozilla.org/User:Dbaron/1.9.3_Alpha> Please add to this list any features that:
> * are not in Firefox 3.6 / Gecko 1.9.2
> * are significant enough that we'd want to either:
> + direct testing or attention to them in release notes for an
> alpha release
> + consider them when deciding how to schedule alpha releases
> * have already landed on mozilla-central or are expected to land on
> mozilla-central in the next few months
> I hope that this list will be useful both for (a) publicizing what's
> in the alpha releases we do and what testing we want and (b)
> planning the schedule of future alphas.
>

This is awesome - thanks, David!

We should probably start documenting this as Firefox 3.7 for developers
in MDC as things land.

When we put the alpha out (soon?) we should put up a post through our
web developer channels as well as our usual mozilla developer channels.
Since we're able to do this now being able to say "you should test this
feature and these 5 things should work" is useful. Looks like you've
started that in your table, but it would probably need messaging as we
push them out.

Could you please rename that as "Upcoming features for Firefox developers" as per Shaver's note? It's unclear at this time whether all of the features listed will be in a single release. Some items may be shipped to users via minor updates, some may be bundled together, some may need to be cut if we can't stabilize them in time.

Re: Planning (and triaging) for 1.9.3 alphas

On 1/25/10 11:06 AM, Mike Beltzner wrote:

> On 2010-01-25, at 8:03 AM, Eric Shepherd wrote:
>
>> On 1/22/10 8:06 PM, Christopher Blizzard wrote:
>>> We should probably start documenting this as Firefox 3.7 for developers
>>> in MDC as things land.
>>
>> A very early (obviously) draft:
>>
>> https://developer.mozilla.org/en/Firefox_3.next_for_developers>
> Could you please rename that as "Upcoming features for Firefox developers" as per Shaver's note? It's unclear at this time whether all of the features listed will be in a single release. Some items may be shipped to users via minor updates, some may be bundled together, some may need to be cut if we can't stabilize them in time.

Re: Planning (and triaging) for 1.9.3 alphas

On 1/25/10 12:43 PM, John J. Barton wrote:
> Is there any way to influence, beg, or make the case for adding items to
> this list?

The list is a list of things that have already been checked in or are in
the final stages of review and about to land in the next week or so. So
if there's something else that should be on the list (as in, has been
checked in or is about to land and is a developer-oriented feature),
just say what it is?

Re: Planning (and triaging) for 1.9.3 alphas

> Eric Shepherd wrote:
>> On 1/22/10 8:06 PM, Christopher Blizzard wrote:
>>> We should probably start documenting this as Firefox 3.7 for developers
>>> in MDC as things land.
>> A very early (obviously) draft:
>> https://developer.mozilla.org/en/Firefox_3.next_for_developers>
> Is there any way to influence, beg, or make the case for adding items to this list?

The list, AIUI, is of work that's already in progress. If there are specific features that you think we should be working on that we aren't, the appropriate procedure is to:

- file a bug with a detailed description of what the feature is, linking to specifications if they exist
- start a discussion in the appropriate forum (mozilla.dev.platform for Gecko/Toolkit requests, mozilla.dev.apps.firefox for Firefox front-end feature additions) about why you think it's important: what advantage does it provide for the Mozilla community, what are the estimated costs (if you can make such an estimate) of implementing, and who do you think would be able to help work on it

Re: Planning (and triaging) for 1.9.3 alphas

> On 2010-01-25, at 9:43 AM, John J. Barton wrote:
>
>> Eric Shepherd wrote:
>>> On 1/22/10 8:06 PM, Christopher Blizzard wrote:
>>>> We should probably start documenting this as Firefox 3.7 for developers
>>>> in MDC as things land.
>>> A very early (obviously) draft:
>>> https://developer.mozilla.org/en/Firefox_3.next_for_developers>> Is there any way to influence, beg, or make the case for adding items to this list?
>
> The list, AIUI, is of work that's already in progress. If there are specific features that you think we should be working on that we aren't, the appropriate procedure is to:
>
> - file a bug with a detailed description of what the feature is, linking to specifications if they exist
> - start a discussion in the appropriate forum (mozilla.dev.platform for Gecko/Toolkit requests, mozilla.dev.apps.firefox for Firefox front-end feature additions) about why you think it's important: what advantage does it provide for the Mozilla community, what are the estimated costs (if you can make such an estimate) of implementing, and who do you think would be able to help work on it

Ok thanks, and then what is the next step? I've done those steps for
bugs 529474, 342715, 449464, 503007, 228205, 507783 as examples. Maybe
I did not do those steps correctly?

Re: Planning (and triaging) for 1.9.3 alphas

> On 1/25/10 12:43 PM, John J. Barton wrote:
>> Is there any way to influence, beg, or make the case for adding items to
>> this list?
>
> The list is a list of things that have already been checked in or are in
> the final stages of review and about to land in the next week or so. So
> if there's something else that should be on the list (as in, has been
> checked in or is about to land and is a developer-oriented feature),
> just say what it is?
>
> -Boris

I guess then I'm asking about the step before, that is how go from "bug
entered" to the state you describe above.

Re: Planning (and triaging) for 1.9.3 alphas

> Boris Zbarsky wrote:
>>
>> On 1/25/10 12:43 PM, John J. Barton wrote:
>>>
>>> Is there any way to influence, beg, or make the case for adding items to
>>> this list?
>>
>> The list is a list of things that have already been checked in or are in
>> the final stages of review and about to land in the next week or so. So if
>> there's something else that should be on the list (as in, has been checked
>> in or is about to land and is a developer-oriented feature), just say what
>> it is?
>>
>> -Boris
>
> I guess then I'm asking about the step before, that is how go from "bug
> entered" to the state you describe above.
>
> jjb
> _______________________________________________
> dev-planning mailing list
> [hidden email]> https://lists.mozilla.org/listinfo/dev-planning>

Re: Planning (and triaging) for 1.9.3 alphas

On Mon, Jan 25, 2010 at 1:35 PM, John J. Barton
<[hidden email]> wrote:
> I guess then I'm asking about the step before, that is how go from "bug
> entered" to the state you describe above.

The list on MDC is descriptive, not prescriptive. Seems to me that
you're asking "how do I get fixes for the bugs I care about". There is
no magic bugzilla flag or wiki page that will do that. You need to
identify the problems first and foremost - you've done a pretty good
job of that. Next step is to identify the people who can help you with
those bugs and engage with them, making sure they understand why the
bugs are important to fix. Doing investigative work and presenting
patches to seed discussion is probably the most reliable way to push
bugs forward, because it's easier for others to provide feedback on a
patch than it is to investigate a bug from scratch. If you aren't able
to produce patches you'll have to rely on polite requests and plain
old communication skills (taking into account the fact that these
people might disagree with your assessment of the bugs' importance).

As I suppose you know, I am ready to provide endless additional
commentary on the issues around these bugs, if that will help.

jjb

>
> On Mon, Jan 25, 2010 at 13:35, John J. Barton
> <[hidden email]> wrote:
>> Boris Zbarsky wrote:
>>> On 1/25/10 12:43 PM, John J. Barton wrote:
>>>> Is there any way to influence, beg, or make the case for adding items to
>>>> this list?
>>> The list is a list of things that have already been checked in or are in
>>> the final stages of review and about to land in the next week or so. So if
>>> there's something else that should be on the list (as in, has been checked
>>> in or is about to land and is a developer-oriented feature), just say what
>>> it is?
>>>
>>> -Boris
>> I guess then I'm asking about the step before, that is how go from "bug
>> entered" to the state you describe above.
>>
>> jjb
>> _______________________________________________
>> dev-planning mailing list
>> [hidden email]>> https://lists.mozilla.org/listinfo/dev-planning>>

Re: Planning (and triaging) for 1.9.3 alphas

Sadly, you can't share Bugzilla queries that easily ;) However, knowing that these things are triaged and use a consistent whiteboard tag means that it's easier for people to understand which bugs are useful for Firebug, which is great.

You asked how you progress: you find people to get interested in and to work on those bugs. You engage contributors, and push things forward. It's a collaborative effort, and one which we're all in together.

Re: Planning (and triaging) for 1.9.3 alphas

Mike Beltzner wrote:
> On 2010-01-25, at 10:52 AM, John J. Barton wrote:
>
>> p1 firebug list: https://bugzilla.mozilla.org/buglist.cgi?cmdtype=runnamed&namedcmd=p1>
> Sadly, you can't share Bugzilla queries that easily ;) However, knowing that these things are triaged and use a consistent whiteboard tag means that it's easier for people to understand which bugs are useful for Firebug, which is great.

Re: Planning (and triaging) for 1.9.3 alphas

> On Mon, Jan 25, 2010 at 1:35 PM, John J. Barton
> <[hidden email]> wrote:
>> I guess then I'm asking about the step before, that is how go from "bug
>> entered" to the state you describe above.
>
> The list on MDC is descriptive, not prescriptive. Seems to me that
> you're asking "how do I get fixes for the bugs I care about". There is
> no magic bugzilla flag or wiki page that will do that. You need to
> identify the problems first and foremost - you've done a pretty good
> job of that. Next step is to identify the people who can help you with
> those bugs and engage with them, making sure they understand why the
> bugs are important to fix. Doing investigative work and presenting
> patches to seed discussion is probably the most reliable way to push
> bugs forward, because it's easier for others to provide feedback on a
> patch than it is to investigate a bug from scratch. If you aren't able
> to produce patches you'll have to rely on polite requests and plain
> old communication skills (taking into account the fact that these
> people might disagree with your assessment of the bugs' importance).
>
> Gavin

Ok thanks. I think I've done all of that, though some may argue about
the 'polite' part ;-). I have to come up with a different strategy.