Tree Rules for the 1.8 Branch

Tree Rules for the 1.8 Branch

As mentioned in the Mozilla roadmap [1], Firefox 2 development is happening
on the 1.8 branch. A branch plan [2] is being implemented in which certain
frontend directories (mozilla/browser and parts of mozilla/toolkit) will be
automatically mirrored between the trunk and the 1.8 branch. Support for
code #ifdef MOZILLA_1_8_BRANCH has been introduced to deal with divergence
in mirrored directories between the trunk and the 1.8 branch.

For directories that are not automatically mirrored between trunk and
branch, the following 1.8 branch tree rules are in effect:

* Module owners and peers are responsible for deciding which patches are
acceptable to land on the 1.8 branch, using the guidelines below.

* A bugzilla flag branch-1.8.1 has been created. To nominate a patch for
acceptance on the 1.8 branch, set this flag and request approval from the
appropriate module owner.

* The approval1.8.1 flag is for use during freeze periods.

The following guidelines should be used by module owners to decide which
patches should be accepted on the 1.8 branch:

* The fix must not alter any XPCOM interfaces or pseudo-interfaces;

* Fixes to backend code should be tested and verified on the trunk and any
regressions must be fixed;

* Fixes to backend code should be fixes for regressions, crashes, unexpected
behavior, and features needed for Firefox 2. Landing of other new features
should be proposed to and approved by [hidden email] via email.

Re: Tree Rules for the 1.8 Branch

Benjamin Smedberg wrote:

> As mentioned in the Mozilla roadmap [1], Firefox 2 development is
> happening on the 1.8 branch. A branch plan [2] is being implemented in
> which certain frontend directories (mozilla/browser and parts of
> mozilla/toolkit) will be automatically mirrored between the trunk and
> the 1.8 branch. Support for code #ifdef MOZILLA_1_8_BRANCH has been
> introduced to deal with divergence in mirrored directories between the
> trunk and the 1.8 branch.
>
> For directories that are not automatically mirrored between trunk and
> branch, the following 1.8 branch tree rules are in effect:
>
> * Module owners and peers are responsible for deciding which patches
> are acceptable to land on the 1.8 branch, using the guidelines below.
>
> * A bugzilla flag branch-1.8.1 has been created. To nominate a patch
> for acceptance on the 1.8 branch, set this flag and request approval
> from the appropriate module owner.

Is there a process for auditing this? Is it being compared against
despot's list of owners? Or, are we just responsible for policing our
own modules? And, what about modules that are under-owned?

>
> * The approval1.8.1 flag is for use during freeze periods.
>
> The following guidelines should be used by module owners to decide
> which patches should be accepted on the 1.8 branch:
>
> * The fix must not alter any XPCOM interfaces or pseudo-interfaces;

Changes to interfaces that have been newly introduced for FF 2 are of
course exempt from this policy, right? ;-)

Re: Tree Rules for the 1.8 Branch

> Is there a process for auditing this? Is it being compared against
> despot's list of owners? Or, are we just responsible for policing our
> own modules? And, what about modules that are under-owned?

It is basically the same community-driven process we follow on trunk.
Patches in under-owned modules are going to have been reviewed by somebody,
and that same person can probably take responsibility for the 1.8 branch
flag. Disputes can be escalated to drivers@mo if necessary, but I doubt it
will be necessary.

> Changes to interfaces that have been newly introduced for FF 2 are of
> course exempt from this policy, right? ;-)

Correct. Perhaps a more precise wording would be "interfaces present in
Firefox/Thunderbird 1.5 must not be altered".

Re: Tree Rules for the 1.8 Branch

Benjamin Smedberg wrote:

> Darin Fisher wrote:
>
>> Is there a process for auditing this? Is it being compared against
>> despot's list of owners? Or, are we just responsible for policing
>> our own modules? And, what about modules that are under-owned?
>
> It is basically the same community-driven process we follow on trunk.
> Patches in under-owned modules are going to have been reviewed by
> somebody, and that same person can probably take responsibility for
> the 1.8 branch flag. Disputes can be escalated to drivers@mo if
> necessary, but I doubt it will be necessary.
>
>> Changes to interfaces that have been newly introduced for FF 2 are of
>> course exempt from this policy, right? ;-)
>
> Correct. Perhaps a more precise wording would be "interfaces present
> in Firefox/Thunderbird 1.5 must not be altered".
>
> --BDS

Re: Tree Rules for the 1.8 Branch

> Darin Fisher wrote:
>
>> Is there a process for auditing this? Is it being compared against
>> despot's list of owners? Or, are we just responsible for policing
>> our own modules? And, what about modules that are under-owned?
>
> It is basically the same community-driven process we follow on trunk.
> Patches in under-owned modules are going to have been reviewed by
> somebody, and that same person can probably take responsibility for
> the 1.8 branch flag. Disputes can be escalated to drivers@mo if
> necessary, but I doubt it will be necessary.
>
>> Changes to interfaces that have been newly introduced for FF 2 are of
>> course exempt from this policy, right? ;-)
>
> Correct. Perhaps a more precise wording would be "interfaces present
> in Firefox/Thunderbird 1.5 must not be altered".
>
> --BDS

Another question:
Shouldn't folks set the fixed1.8.1 keyword on bugs where patches have
been commited to the 1.8 branch?

Re: Tree Rules for the 1.8 Branch

Benjamin Smedberg wrote:
> As mentioned in the Mozilla roadmap [1], Firefox 2 development is
> happening on the 1.8 branch. A branch plan [2] is being implemented in
> which certain frontend directories (mozilla/browser and parts of
> mozilla/toolkit) will be automatically mirrored between the trunk and
> the 1.8 branch. Support for code #ifdef MOZILLA_1_8_BRANCH has been
> introduced to deal with divergence in mirrored directories between the
> trunk and the 1.8 branch.
>

As we talked about this yesterday, the mirroring back end should
evaluate to include the corresponding l10n repositories.

What's the bug for the server side work? I've been doing some queries
that seemed good to me, but they weren't.