Use draft PRs for Chromium/Gecko/WebKit exports that aren't ready to land

[foolip]

The changes suggested in the issue would be implemented elsewhere, but I'm filing here to discuss.

Draft PRs didn't exist on GitHub when the export systems were created. The benefit of using draft PRs would be:

• Easier to filter out PRs that aren't intended for review using -is:draft, which would also included draft PRs in this repo. Currently the query to exclude exports involves 3 labels and without a link to a query takes some time to construct.
• For PRs corresponding to ongoing upstream reviews, it's an accurate description of the state of the changes.

@Hexcles @jgraham @youennf WDYT?

[jdm]

This should be straightforward to implement for Servo's exporter, and I think it makes sense

[foolip]

Sounds great @jdm, and sorry I forgot to ask about Servo.

Where there might be question marks is when should PRs stop being draft? Perhaps when the change has landed in the downstream repo?

I realize that this then wouldn't be very useful for filtering out PRs not intended to be reviewed in this repo.

[jdm]

For Servo's upstreaming lifecycle, we would either mark the PR as non-draft right before merging it, or we could do that when the downstream PR is added to the queue of to-be-merged PRs.

[jgraham]

For PRs that actually haven't been reviewed upstream I'd much prefer if they weren't marked as approved here either; the current setup is misleading for Chromium PRs in particular.

Independent of that, making the PRs draft until they're actually ready to land seems reasonable; gecko currently marks this using a custom status, but if everyone agreed on the alternate approach that would be more consistent.

[foolip]

I agree, approving the changes only when they're actually landed elsewhere seems clearer. It also makes it harder to accidentally merge a PR, although I don't think that's happened.

@Hexcles WDYT for Chromium?

[foolip]

This proposal actually won't work as-is for WebKit, because their export flow is different. There, the expectation is that the WPT PR is merged before the WebKit change. Using the draft state for these might not be natural. @youennf thoughts?

Aside: in #19796 it turned out that some PRs remaining open and unmerged after the WebKit change, but that's just a process bug.

[zcorpan]

I wonder if it would be good to also have one common export label for all exports?

[foolip]

That would come in handy for filtering, yes.