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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
