On 13-04-03 23:05 , Jesse Ruderman wrote:
I suggest adding an Auto branch between Try and Central. Advantages:
[snip]
* In Scenario D (when subtle patch interactions cause build or test
failures), automation can move on to another set of Try landings, giving
sheriffs time react without the pressure of tree closure.
This part doesn't make sense to me. When you say "automation can move on
to another set of Try landings", where would these patches go?
Presumably on this "Auto" branch, since all patches go through Auto. But
in this scenario, Auto is broken from the previous set of try landings,
so you wouldn't really want to put them there. Does Auto also allow
multiple heads? That's the only way this makes sense. But then if Auto
has multiple heads, presumably those heads are getting merged onto m-c,
and so you'll need to run tests on m-c. I think this contradicts your
other statement (step 6). Can you clarify?
On 13-04-04 03:23 , Jesse Ruderman wrote:> * Try to understand what
happened in a changeset. (For a normal
> changeset, you'd use "hg diff" or "hg log -p" or "hg export".) For a
> merge changeset, your first question might be whether the merge was
> trivial. If not, where not, and how was each conflict resolved?
Fair point.
> * Try to understand the shape of history around a merge. Which parent
> was 'inbound' and which parent was 'central'? From central's
> perspective, what changes did this bring in from inbound? (These
> questions are possible to answer with pushlog, debugancestor, and log.)
Agreed. Even now I have trouble figuring out which parent was inbound
and which was central. I think have a policy on how to do the merge and
having it consistently followed would help a lot here, even today. By
this I mean dictate that "when merging to m-c, you must always update to
current m-c, and then merge the new changesets in". That way you know
that the first parent of the merge head was m-c, and the other parents
were merged in. Currently with the inbound <-> m-c merges I don't
believe there is a policy on this. For example, cset 475dc5f51bdb (which
was an inbound -> m-c merge) has a first parent that is from inbound and
a second parent from m-c. Cset 686d76b44d9f on the other hand, which was
a fx-team -> m-c merge, has a first parent that is from m-c and a second
parent from fx-team.
> hg log:
>
> * [hg log modules/libpref/src/init/all.js] includes lots of bogus
> trivial merges.
Yes, it does. You can skip all the merges with -M though. I'm not sure
if there are conditions in which you'd want to list only non-trivial
merges in the log; it seems to me that hg blame is more suited for any
such use cases, because the change description of a non-trivial merge is
pretty useless. (That being said, we could make a policy of annotating
non-trivial merges with something in the change description - e.g.
"Merge inbound to m-c; non-trivial").
> * Was revision X quickly followed by a backout? With branchy history,
> there's no "the next 10 changesets".
In my proposal you would almost never have a backout cset get merged to
m-c. At least not because of tree bustage; maybe for other reasons like
improper review. However then the backout would likely not be "quickly
following" the original change anyway.
> hg bisect:
>
> There are three reasons hg bisect might blame a merge. I've hit them
> all many times and they're all unpleasant. (I taught Gary's bisect
> wrapper to distinguish between the cases, which helps a little.)
>
> A. From the perspective of mozilla-central, the bug was introduced by a
> merge from inbound. My 'start' revision came after the common ancestor.
> I have to start over or use --extend.
>
> B. The problem was actually introduced by the merge; both parents are
> free of the bug. What patches on each side contributed to the problem?
> hg bisect can't answer this question.
>
> C. I marked a changeset as 'bad' when it actually had a different bug
> than the one I was bisecting for. hg bisect blames a random merge
> changeset whose parents it hasn't even tested.
>
Yeah. TBH I don't have a good solution for hg bisect, as I haven't spent
a lot of time with it. I just want to point out that all these problems
exist now anyway; they might get a little more frequent and/or annoying.
On 13-04-04 05:54 , Neil wrote:> After patches have passed try, do
people then push them to inbound,
> because they don't want to watch the tree? Maybe it should be possible
> for sheriffs to merge/rebase a completely green try run to m-c as if it
> was an m-i merge.
This is pretty much exactly what I'm suggesting.
Cheers,
kats
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
