On 11/07/2013 06:12 PM, Dale Harvey wrote:
While I really hate the workflow of having to bisect problems that may be
anywhere between 2 seperate repositories
Putting gaia inside m-c doesnt seem like a scalable solution, should we be
putting gonk / the rest of android in there too?
This is exactly what google does, they have everything from the Android
kernel to Gmail all sitting in a single monolithic source tree. And they
have had a lot of success making this system scale (I highly recommend
watching http://www.infoq.com/presentations/Development-at-Google if you
are interested in the details of how it works).
I feel like in m-c I already see problems related to trying to chuck
everything in the same basket
What are the problems you've noticed? As someone who works with m-c on a
daily basis, I'm quite happy with how simple a single repository system
makes my life.
shouldnt we be looking to better uncouple projects (like repo per app in gaia
:))
I strongly disagree. Decoupled repo's is a disaster when it comes to
sheriffing, automated testing and regression hunting. Ask anyone who
maintains/maintained comm-central how difficult it was to stay on top of
gecko induced breakages. And that was only two repos. With B2G we are
talking about hundreds of repos. I'd argue that *that* is what is
unscalable.
and have a better understanding of
tools like repo or other tools for handing multiple repositories (but not
submodules)
This part I agree on. Whether we go the Google route of a single
monolithic repository, or the current trajectory of decoupled
repositories, we need better tooling to make the workflows of all
parties easier. I just think our efforts would be better spent on better
tooling for a monolithic repo (i.e tests that only run if a change
touches a specific directory, ability to clone only parts of a repo, etc).
In conclusion, neither path is easy, both have their own set of problems
which can be mitigated with better tooling. I think Google has proven
that the monolithic method scales, and I've seen no evidence (and much
counter-evidence) that the distributed repo method doesn't.
My two cents,
Andrew
p.s I urge you to watch
http://www.infoq.com/presentations/Development-at-Google if you are on
the fence.
On 7 November 2013 13:22, Gary Kwong <[email protected]> wrote:
The other alternative to make it painless to land gecko+gaia atomic
changes is of course to move gaia to the same repo as gecko, and make
the github repo a readonly mirror of gaia-hg. I'm sure I will be very
popular with this proposal in gaia circles ;)
This is interesting. More consolidation of repos - releng might have some
ideas?
If this seems like a possible way forward, perhaps a bug could be filed?
-Gary
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
