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 the information valuable as a member of the QA team. In some ways the inbound link is more valuable than the m-c link. As it clearly shows when the change was inserted to the version control and/or backed out.
Kevin On Mon, Oct 8, 2012 at 7:32 PM, Justin Lebar <justin.le...@gmail.com> wrote: >> 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/integration/mozilla-inbound/rev/8ebfc639c69f > > On Mon, Oct 8, 2012 at 9:59 PM, Justin Dolske <dol...@mozilla.com> wrote: >> 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. ;) >> >> The info is generally useful, especially in the current system. So I'd >> encourage people to keep adding "Pushed to inbound: <changeset url>" or some >> flavor thereof. It's helpful for determining what's happened/happening to a >> bug, 10x when backouts are involved. I suspect having the inbound changeset >> is useful for someone doing regression hunting (ie, looking between merges)? >> >> OTOH, there's room for improvement as more automation becomes involved, >> particularly for the simple case of land-merge-done. If a single, automated, >> post-merge comment just noted everything, that would be peachy. As would a >> single "landed, oops, backed out" note. >> >> tl;dr: seems like useful info, but am not too hung up on the details. :) >> >> Justin >> >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
