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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ > dev-platform mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
