648093 - button to send patches to try

Status: RESOLVED DUPLICATE of bug 657828

(bugzilla.mozilla.org :: General, defect)

Description

[Jeff Hammel]

It would be nice to have a button to push patches to try, possibly with a button to push to m-c if all goes well. 

The latter should only work if the patch isn't bitrotted.  Also, it would be nice to know that (see bug 648092) and of course depends on the appropriate r+/a+ flags as necessary.

Comment 1

[Jeff Hammel]

An ideal workflow would look something like this:

    - bugzilla would ideally tell you if a patch to m-c is bitrotted: bug 648092
    - you should be able to push to try from bugzilla, ideally: bug 648092
    - ideally, in the case where try passes and there are no conflicts with m-c tip (that is, no one has landed changes that conflict with your patch, whether that means bitrotting your patch, changes in the same file, etc) you should be able to take the changeset from try and apply it directly to m-c.  Whether this means pulleys and levers that do this semi-automatically or the sheriff makes the call and pushes a button to pull your try changeset(s) to m-c is a topic of discussion.  Total savings: 100% of the machine time for tests since you're not running them twice!
    - as a nuance, this means no one touches m-c directly, probably; you push to try and if you win you get to land on m-c.  This is actually a lie -- there will need to be people with the ability to tweak m-c directly but that is a small minority
    - and of course this only applies to m-c tip.  If you want to run a try job with some other crazy check that you don't want on m-c that should be allowed and encouraged; maybe that's even the default.  But the point is: the stuff that can/will land on m-c must go on try versus m-c tip instead of developers not updating their m-c copy and therefore trying versus outdated copies of m-c and pushed to m-c tip
    - it would also be nice to be able to tie bugzilla attachments to mq; this way, pushing to an m-q would obselete old attachments on a bug and load the new ones (nuances to be worked out)

Much of this is outside of the scope of bugzilla....possibly worth one (or several) follow-up bugs

Comment 2

[(no longer active)]

I think releng should be consulted before we attempt to fix this.  There are a lot of people who push daily batches of their work to try (only once per day) to get testing on all platforms.  If this makes it easier to get try results per bug, it could increase the number of try server jobs by several times, and I don't think that our releng infrastructure is currently capable of handling such a load.

Comment 3

[Chris AtLee [:catlee]]

Heheh, we've been thinking along these same lines.  We want to get bug 430942 fixed first, so try runs can report to bugzilla.  After that, my thoughts on workflow were:
- Have attachment flag like push-to-try[?-+]
- Bot finds push-to-try? attachments, tries to apply against tip of m-c with appropriate try syntax to get reporting sent back to the bug.
- Sets push-to-try+ if the push was successful, and push-to-try- otherwise.

Comment 4

[(no longer active)]

(In reply to comment #3)
> Heheh, we've been thinking along these same lines.  We want to get bug 430942
> fixed first, so try runs can report to bugzilla.  After that, my thoughts on
> workflow were:
> - Have attachment flag like push-to-try[?-+]
> - Bot finds push-to-try? attachments, tries to apply against tip of m-c with
> appropriate try syntax to get reporting sent back to the bug.

We somehow need to specify the order, for bugs with multi-part patches, which are becoming more common in Core at least.

> - Sets push-to-try+ if the push was successful, and push-to-try- otherwise.

Shouldn't this be per bug?  I'm not sure what it means for a bot to push my "part 1" patch but not the accompanying "part 2".

Also, are you implying that my concern in comment 2 is not something which worries you guys?  (Don't get me wrong, that would make me really happy!)

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

Just ran across this and I think that our autolanding work will cover this general request/use case - certainly it will make a "button" wontfix since we'll have other tools (bugzilla extension, API, and whiteboard syntax) to assist with automatically pushing to try and to branches.