On 10/08/2012 08:42 AM, thus spoke Justin Lebar:
> Having said that, I don't think it would be hard to write an hg hook
> which comments in the relevant bugs when a push is made to m-i. Maybe
> that would be a reasonable way to get uniformity and immediate
> notification in the bug when a patch i
Because it requires you recall that factoid. It ends up being a bit of
oral tradition. Someone new to the project asks how to find a
regression range on inbound and you need to communicate this bit of
info. Normally if you catch a regression quickly inbound is a better
place to locate it. I find th
On 09/10/12 11:09, Nicholas Nethercote wrote:>
> But I do agree that it would be lovely to automate this.
+1 for automation. Cross-referencing is a machine's job.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/list
> I suspect having the inbound changeset is useful for someone doing regression
> hunting (ie, looking between merges)?
It's the same hash on inbound and central, so I don't see why this
would matter. For example,
http://hg.mozilla.org/mozilla-central/rev/8ebfc639c69f
http://hg.mozilla.org/integ
On 10/8/12 11:09 AM, Kevin Brosnan wrote:
I agree with Gavin this makes reading a bug much simpler when it comes
to understanding where a patch has landed especially when backouts
occur. The information is added for other readers of the bug not the
developer of the patch.
I concur and dissent.
On Mon, Oct 8, 2012 at 8:05 AM, Gavin Sharp wrote:
>
> You should feel free to break the convention if the only people
> impacted are you an njn and you're both fine with it.
FWIW, I'm not fine with it :) I like knowing when a patch lands on
inbound. I also like having the full paper trail in t
I agree with Gavin this makes reading a bug much simpler when it comes
to understanding where a patch has landed especially when backouts
occur. The information is added for other readers of the bug not the
developer of the patch.
Kevin Brosnan
On Mon, Oct 8, 2012 at 5:56 AM, Gavin Sharp wrote:
On Mon, Oct 8, 2012 at 3:42 PM, Justin Lebar wrote:
> I don't feel like it's /always/ important.
>
> On a bug that njn and I are the only ones watching and which gets
> landed on m-i over the weekend, it's not at all clear to me that
> anyone is hurting for lack of an explicit notification that th
njn didn't want to call me out as the culprit here, but I'm happy to
own up to it. :)
> "Pushed to inbound" is an important status to have indicated in the bug,
I don't feel like it's /always/ important.
On a bug that njn and I are the only ones watching and which gets
landed on m-i over the we
On Monday 2012-10-08 20:03 +1100, Nicholas Nethercote wrote:
> In https://wiki.mozilla.org/Tree_Rules/Inbound, one of the steps under
> "Please do the following after pushing to inbound" is:
>
> "Add the inbound changeset URL to the bug. If there are multiple
> patches on the bug and you are not p
I disagree. "Pushed to inbound" is an important status to have
indicated in the bug, and the best way to do that is to include the
inbound changeset URL (even though it will be the same revision when
it gets to m-c, it's useful to know where it is until it gets there).
It also helps with backouts,
Hi,
In https://wiki.mozilla.org/Tree_Rules/Inbound, one of the steps under
"Please do the following after pushing to inbound" is:
"Add the inbound changeset URL to the bug. If there are multiple
patches on the bug and you are not pushing all of them, please
indicate which one(s) you pushed (eg: u
12 matches
Mail list logo
