Add '[leave open]' to the whiteboard if a bug should remain open after inbound -> m-c merges

[Ed Morley]

For a while now, we've requested that people add '[leave open]' to the whiteboard when landing on inbound, if the bug should remain open after the mozilla-inbound to mozilla-central merge.

Up until now there was a chance that bug comments/patches still awaiting review would be spotted by the person manually marking the bugs. However, we're now trialling an automated tool to do this, that relies upon the whiteboard annotation - so please remember to add it if needed.

I have spotted a few bugs over the last few days where it was omitted, so posting this in case people were not aware of:
https://wiki.mozilla.org/Tree_Rules/Inbound#Please_do_the_following_after_pushing_to_inbound

Best wishes,

Ed

[Kartikaya Gupta]

On 12-06-14 09:22 , Ed Morley wrote:
> I have spotted a few bugs over the last few days where it was omitted, so posting this in case people were not aware of:
> https://wiki.mozilla.org/Tree_Rules/Inbound#Please_do_the_following_after_pushing_to_inbound
>

I had a question about this point on that page:

> Set the target milestone (unless an aurora migration is due within 24
> hours).

What is the rationale behind having this set when landing on inbound?
Does it make more sense for the target milestone to be set when m-i is
merged to m-c, and we know for sure which version it ended up in?

A couple of times I've landed something on inbound just before an aurora
migration and had to update the target milestone because it ended up on
the next train. Also, if a patch is backed out the target milestone is
un-set, so it seems reasonable to me that it should only get set once,
when the patch "sticks" and gets into m-c.

kats

[Ed Morley]

On Thursday, June 14, 2012 3:11:48 PM UTC+1, Kartikaya Gupta wrote:
> > Set the target milestone (unless an aurora migration is due within 24
> > hours).
>
> What is the rationale behind having this set when landing on inbound?
> Does it make more sense for the target milestone to be set when m-i is
> merged to m-c, and we know for sure which version it ended up in?

I added that requirement to the tree rules doc back when I was a volunteer and marking the bugs manually, in order to save my/other sheriff's time.

The new automated too sets the milestone automatically, so I have just removed that step from https://wiki.mozilla.org/Tree_Rules/Inbound#Please_do_the_following_after_pushing_to_inbound

The tool doesn't yet set the assignee (need to cater for bugs with multiple patches with different authors and a few other edge cases), but I'd like us to do that in the future too.

Best,

Ed

[Kartikaya Gupta]

On 12-06-14 10:47 , Ed Morley wrote:
> I added that requirement to the tree rules doc back when I was a volunteer and marking the bugs manually, in order to save my/other sheriff's time.
>
> The new automated too sets the milestone automatically, so I have just removed that step from https://wiki.mozilla.org/Tree_Rules/Inbound#Please_do_the_following_after_pushing_to_inbound

Awesome, thanks!

> The tool doesn't yet set the assignee (need to cater for bugs with multiple patches with different authors and a few other edge cases), but I'd like us to do that in the future too.

Yeah, I can imagine that would be a harder case to deal with.

Cheers,
kats

[Steve Fink]

Related: bzexport will set the assignee automatically when you attach a
patch. (So |hg bzexport| will, with or without --new; |hg newbug| will not.)

And if you have a reason for not using bzexport, you should file a bug
in product "Other Applications", component "bzexport" (or |hg newbug -e
--component=bzexport|, but that may run afowl of a chicken/egg problem,
if you'll excuse my spelling.) Or email me.

But only fixable reasons. There are many perfectly valid reasons for not
using it.

[Mike Hommey]

On Thu, Jun 14, 2012 at 09:22:37AM -0700, Steve Fink wrote:
> On 06/14/2012 08:02 AM, Kartikaya Gupta wrote:

> Related: bzexport will set the assignee automatically when you
> attach a patch. (So |hg bzexport| will, with or without --new; |hg
> newbug| will not.)

Is it supposed to that already or is that an upcoming feature? Because
it surely never did it for me, and I'm on the last changeset, afaict.

Or maybe http://hg.mozilla.org/users/tmielczarek_mozilla.com/bzexport/
is not the canonical repository anymore?

Mike

[Steve Fink]

On Thu 14 Jun 2012 09:39:12 AM PDT, Mike Hommey wrote:
> On Thu, Jun 14, 2012 at 09:22:37AM -0700, Steve Fink wrote:
>> On 06/14/2012 08:02 AM, Kartikaya Gupta wrote:

>> Related: bzexport will set the assignee automatically when you
>> attach a patch. (So |hg bzexport| will, with or without --new; |hg
>> newbug| will not.)
>
> Is it supposed to that already or is that an upcoming feature? Because
> it surely never did it for me, and I'm on the last changeset, afaict.
>
> Or maybe http://hg.mozilla.org/users/tmielczarek_mozilla.com/bzexport/
> is not the canonical repository anymore?

When in doubt, assume I'm an idiot.

You are right; it only does that with |hg bzexport --new| or |hg newbug
--take-bug|.

I should fix that. https://bugzilla.mozilla.org/show_bug.cgi?id=764881

I thought I already had.