We already have the approximate equivalent of this. It's the
'checkin-needed' keyword.
Add this to your bug, and the sheriffs will land the patch for you,
using the approximate process you describe. The only difference is this
is done out-of-band, so turnaround may take up to 24 hrs.
The advantage of using this is that it allows the sheriffs to regulate
patch landings more evenly, and avoid landings during peak hours, which
makes bustages easier to spot, and potentially reduces the duration of
tree closures.
The disadvantage is that you may end up waiting to have your patch
landed, and some bugs may be hard for the sheriffs to land; e.g., if
there are a lot of patches in a single bug, and some of them have
already landed, or there are patches for multiple repos.
Jonathan
On 12/19/2013 2:42 PM, Bobby Holley wrote:
As someone who works mostly on the intersection of the JS engine and
everything else, I'm not really wild about this. SpiderMonkey is pretty
intimately tied to the rest of Gecko, certainly just as much as something
like gfx. I think fx-team makes more sense, since most of the patches there
consist primarily of changes to XUL/CSS/JS.
The main problem with inbound seems to be that it requires all developers,
who are generally working on disjoint things, to devote attention to
serializing their patches into inbound with other patches that are mostly
unrelated (but might not be!). As the number of pushers and inbound
closures increases, this becomes more and more of an attention-suck.
The long-term solution that we're working towards is some kind of
bugzilla-based auto-lander IIUC. But in the mean time, it seems like it
would be trivial to write a locally-hosted (mach-integrated?) auto-lander
script, the automates the process of:
(1) Wait until inbound is open.
(2) pull -u, apply the patches, and make sure they apply cleanly.
(3) Push, and mark the bug.
In the case where the patches don't apply, the developer can be alerted,
since her attention is basically required in that case anyway. In all other
cases, we effectively emulate the experience of pushing to an always-open
inbound.
This would be a relatively trivial tool to write, especially compared with
the infra and staff burden of maintaining a bunch of separate repos.
Thoughts?
bholley
On Thu, Dec 19, 2013 at 10:48 AM, Jason Orendorff <jorendo...@mozilla.com>wrote:
On dev-tech-js-engine-internals, there's been some discussion about
reviving a separate tree for JS engine development.
The tradeoffs are like any other team-specific tree.
Pro:
- protect the rest of the project from closures and breakage due to JS
patches
- protect the JS team from closures and breakage on mozilla-inbound
- avoid perverse incentives (rushing to land while the tree is open)
Con:
- more work for sheriffs (mostly merges)
- breakage caused by merges is a huge pain to track down
- makes it harder to land stuff that touches both JS and other modules
We did this before once (the badly named "tracemonkey" tree), and it
was, I dunno, OK. The sheriffs have leveled up a *lot* since then.
There is one JS-specific downside: because everything else in Gecko
depends on the JS engine, JS patches might be extra likely to conflict
with stuff landing on mozilla-inbound, causing problems that only
surface after merging (the worst kind). I don't remember this being a
big deal when the JS engine had its own repo before, though.
We could use one of these to start:
<https://wiki.mozilla.org/ReleaseEngineering/DisposableProjectBranches>
Thoughts?
-j
_______________________________________________
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
