On 11/16/2014 3:01 PM, Axel Hecht wrote: > I guess everyone involved at some point here has a different perspective. > > The latest conversations around l10n builds basically ended in "I > don't own it" -- "No, I don't own it". > > I'd prefer to start the conversation with people, and how they're > affected, and move on to technical changes after that. I don't think that's that hard to figure out. Release Engineering gets bit by repacks being broken in automation fairly often, they'd like that not to happen. (I think this is what that A-Team etherpad describes fixing.) The build system peers frequently wind up hacking around fragile repack code, and only finding out that things are broken when localized nightlies are broken, we'd like that not to happen.
I think the root problem here is simply the complexity of the setup (which was built on the build system of its time, and thus grew out of that) combined with the fact that there isn't anyone that will actively claim to understand how it all works. If we can simply nail down the workflows that need to be supported and rewrite the build logic (using our modern moz.build niceties) it seems likely that we can build something that works more reliably and is also easier to support from both the build peer side and the RelEng side. -Ted _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
