On Thursday, April 10, 2014 8:27:19 AM UTC-7, Michael Shal wrote: > ----- Original Message ----- > > > From: "Gregory Szorc" <[email protected]> > > > > > > The severity of the problem depends on who you are. By some accounts, > > > the build system is staying afloat. We are fixing major issues > > > (especially if they impact automation). And, people are still scratching > > > itches here and there. People are still able to build Firefox. So, the > > > problem is easy to glance over. But, some people have expressed > > > complaints directly to me. Who knows how many more are silently > > > resenting the current status. > > > > This part always seemed quite strange to me - build config essentially has > two consumers: developers and automation. While improvements to the core > build system can benefit both, organizationally we only have a team of people > dedicated to the automation side of things. Essentially this means we only > make significant progress in the dev side when there's free time, or when > frustration with the current state of the build system boils over and someone > decides to put their real work aside for a while. This makes long term > progress much harder to achieve. IMO there's no reason we can't deliver a > 100% reliable, 0%-clobber, near-instantaneous turnaround build system > experience to developers. We just love machines more, I guess.
I think you hit the nail on the head: we have staff whose responsibility is automation but we have no staff whose primary responsibility is developers (in terms of build system at least). The work will happen where there is management accountability and there is currently nobody accountable for the core build system. I don't agree with that decision (I wish the core build system had at least 1 full-time staff person focusing on developer ergonomics and who wouldn't get distracted by automation foo). However, I can rationalize it a bit. There are concrete costs attached to automation, such as our EC2 bill. Improvements and efficiency in automation can be measured. The core build system doesn't have the luxury of direct costs. Therefore, estimating the cost of an inefficient build system and the impact of improvements is difficult. Compound this with the fact the build system has been inefficient for a decade and I think a lot of old-time engineers and managers have the perspective that we've been dealing with it for years without too much of a problem, it therefore isn't a problem worth fixing. I have little doubt that a team of 3 to 5 people working on the core build system full-time could pump out enough efficiency/productivity wins for 12-18 months before we even questioned the financial investment of those staff. The way I look at it, if one person raises the productivity of 100 people by 1%, that person's salary is paid for. I think a 1% productivity boost through a better build system is easily attainable. You figure Mozilla has a few hundred engineers that would benefit, and you've justified multiple staff working on the build system! I just wish someone with the power of the purse would agree with me and we'd start staffing the core build system. _______________________________________________ dev-builds mailing list [email protected] https://lists.mozilla.org/listinfo/dev-builds
