On 27/10/2015 15:24, Mike Hommey wrote: > On Mon, Oct 26, 2015 at 11:44:40PM -0700, Jonas Sicking wrote: >> On Mon, Oct 26, 2015 at 8:27 PM, Nicholas Nethercote >> <n.netherc...@gmail.com> wrote: >> > On Tue, Oct 27, 2015 at 10:26 AM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> >> >> The question is, do we fix that friction by making collaboration >> >> easier, or do we fix it by reducing collaboration. >> > >> > Yes. Merging c-c into m-c would achieve the first alternative. (And it >> > has support from plenty of people in this thread, including build >> > system peers like glandium and gps whose opinion I think should hold >> > strong sway on the topic of repository structure.) >> > >> > Do you have suggestions for achieving the second alternative? >> >> The suggestion would be to give the build engineers explicit >> permission to do whatever changes they need without worrying about if >> it breaks thunderbird. >> >> I.e. do the same thing in the build system as we do in the rest of the tree. > > Let's say we do this. At some point we'll reach the fact that the c-c > specific hacks in the build system are getting in the way (which they > already are, but it's kind of bearable for now), and we'll want to > remove them. What happens then? > > Well, I guess we could declare that it's not our problem and leave it to > the TB and SM people to change their build system and automation to cope > with that. And leave them without a build for months. Do we expect them > to survive that? > > Mike
And what happens if c-c needs to push out a chemspill/security fix while the build system is broken? Phil -- Philip Chee <phi...@aleytys.pc.my>, <philip.c...@gmail.com> http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
