Gijs Kruitbosch writes:
>> What if it causes a regression and a blocking bug needs to be filed?
> Then you file a bug and needinfo the person who landed the commit
> (which one would generally do anyway, besides just marking it
> blocking the regressor).
I find the association of multiple regressions with their cause
very helpful because one regression is often similar to another.
Bugzilla provides the link from cause to effect, a link
direction which is not in the changeset history.
Where there is no bug for the cause, then these links are missing.
I'm not convinced that a "Changeset XXXXX bug" filed after the
fact would be easy to find from the commit message.
> More generally, I concur with Greg that we should pivot to having
> the repos be our source of truth about what csets are present on
> which branches. I've seen cases recently where e.g. we land a
> feature, then there are regressions, and some of them are
> addressed in followup bugs, and then eventually we back everything
> out of one of the trains because we can't fix *all* the
> regressions in time. At that point, the original feature bug's
> flags are updated ('disabled' on the branch with backouts), but
> not those of the regression fix deps, and so if *those* have
> regressions, people filing bugs make incorrect assumptions about
> what versions are affected. Manually tracking branch fix state in
> bugzilla alone is a losing battle.
A system for tracking related changes and branch state that can
have mistakes corrected is better than no system at all.
(I'm not clear whether you think the information currently in the
repos is sufficient.)
For exmample, using changeset history would be a cumbersome way to
determine whether the most recent change for one issue on a branch
was a "fix" or a back-out.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
