Personally I find the branches we have annoying and are papering over
the real problem that our feedback cycles once landed are far too long.
Just for that reason alone I am against the idea.
I think if we can solve the build/test scheduling and being smart about
how we do our testing we can reduce the time the tree is closed greatly.
more comments in line.
David
On 19/12/2013 18:48, Jason Orendorff 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
mozilla-inbound has been closed for on average ~4 days a Month (Data at
the end of the email). This is including the 8 days in November because
we werent monitoring leaks properly. These ~4 days havent been split
into Infrastructure vs test/build failure causing the closure and do
include known downtime from Releng when they do work.
- protect the JS team from closures and breakage on mozilla-inbound
see my comment above.
- avoid perverse incentives (rushing to land while the tree is open)
When auto-land is ready we will be able to throttle landings for people
adding checkin-needed to bugs since the tree is fragile on re opening.
Currently the sheriffs watch for that an land things accordingly. They
do the throttling themselves.
Con:
- more work for sheriffs (mostly merges)
If mostly merges, are you suggesting there will be little traffic on the
branch or the JS team will watch the tree for failures? If the former,
is their value in having another branch when there is low traffic?
- breakage caused by merges is a huge pain to track down
Yup! Not to mention merge conflicts that can happen between branches.
Today there was a complaint in #jsapi when someone was trying to fix an
issue but the test framework was out of sync currently and no merge
imminent. This was between b2g-inbound and mozilla-inbound. Adding
another inbound feels like its going to make it even harder.
- makes it harder to land stuff that touches both JS and other modules
I already have this pain with working on something that B2G use too. The
B2G team has been working with releng to try mitigate it but it's still
painful.
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
(treestatus)☁ mozilla-inbound python treestatus-stats.py --tree
mozilla-inbound
Added on :2012-05-14T09:59:46
Tree has been closed for a total of 64 days, 23:18:12 since it was
created on 2012-05-14T09:59:46
2012-08 : 1 day, 1:26:57
2012-09 : 1 day, 3:31:16
2012-10 : 2 days, 21:33:14
2012-11 : 20:45:45
2012-12 : 2 days, 1:19:51
2013-01 : 2 days, 8:17:55
2013-02 : 4 days, 0:24:59
2013-03 : 6 days, 3:13:09
2013-04 : 4 days, 17:51:39
2013-05 : 5 days, 13:33:49
2013-06 : 2 days, 15:42:37
2013-07 : 6 days, 13:46:11
2013-08 : 4 days, 5:42:17
2013-09 : 4 days, 20:59:41
2013-10 : 4 days, 21:22:40
2013-11 : 8 days, 4:58:30
2013-12 : 2 days, 16:47:42
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
