Hi, (wondering if this goes through. Somehow I miss another answer sent to this list earlier.)
Am 24.01.2018 um 10:26 schrieb Landry Breuil: > On Tue, Jan 23, 2018 at 04:50:10PM -0800, Gregory Szorc wrote: >> On Tue, Jan 23, 2018 at 4:34 PM, Gregory Szorc <g...@mozilla.com> wrote: >> >>> If we require Node.js to build Firefox, what are the requirements, >>> desires, and hardships of downstream packagers and consumers of the Firefox >>> build system? Keep in mind that mozilla-central right now is Firefox 60. >>> That will become ESR 60 in May. >> >> Quick follow-up. First to add mozilla-linux-taskforce. Second to note that >> we almost certainly wouldn't make a change before Firefox 61. That would >> give everyone only caring about ESR an extra ~1 year to deal with fallout. > > The adoption of rust has been painful, i guess the requirement of npm > will be even more painful, and if i'd be given the choice, i'd strongly > raise my voice against it. Just recently it's been made harder for > packagers to work on betas by not providing source tarballs anymore but > only a link to hg that we get to hammer (#1432591) and now this ? > > But since the decision has already been made, i guess we can't do > anything about it, but adapt or die ? > As long as the required version isnt too recent (we have 6.12.3 in > OpenBSD right now, and i have no idea what this means in terms of nodejs > versions) and *you stick to vendoring the nodejs modules HELL* (build > systems are forbidden to download stuff themselves here), i guess we'll > swallow the bitter pill. > Or give up and go do something else, in the greener pastures outside of > this crazy javascript bloat ecosystem. I can only mainly agree to what Landry wrote. With (open)SUSE we have basically the same situation. Our buildsystem is not allowed to download any resources. Everything must be available in the source tree or in the distribution we build for. As node.js and modules is quite a moving target there is a high risk that we end up being unable to build Firefox+1 leaving users at risk. While there is ESR this helps indeed because this is what we nowadays (are forced to) ship because mainly of rust since we simply cannot update rust in a released distribution every around 6 weeks. But "dealing with the fallout" by having a year time does not help. This is an ongoing burden which cannot be solved but would need to be addressed always when the node.js requirement is increased basically. For our rolling variant Tumbleweed this is typically not much of an issue because also node.js is rolling there and can be updated via the normal process if required. Tumbleweed is also the only distribution we nowadays can ship regular release on (see above). That context explained I think our downstream requirements are summarized: - all node.js modules need to be shipped via the mozilla source tree to be on the safe side (no download possible) - problem is with node.js itself and the module compatibility. I have no experience with that stuff - try to be conservative and also keep node.js requirements in ESR cycles unchanged Just to give an impression which node.js versions we currently have in supported releases: Stable distributions: node.js 4.8.7 and 6.11.1 (choice) Rolling distribution: node.js 6.12.3 and 8.9.4 Obviously those are changing over time. While we are at it something a bit offtopic: Currently we are scared about python 2.7 requirements since the next stable version is in the works which will last for at least 3-5 years and our goal is to get rid of python 2.7 in that release because it will (officially) run out of maintenance before EOL. Are there any plans about that? Wolfgang _______________________________________________ dev-builds mailing list dev-builds@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-builds
