On Fri, Jan 26, 2018 at 1:10 AM, Wolfgang Rosenauer <[email protected]> wrote:
> 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 <[email protected]> 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? We are just now requiring Python 3.5+ to build. While some aspects of the build system will adopt Python 3, we have no timeline for moving everything away from Python 2.7. From our perspective, Python 2.7 "just works" and we'd rather spend time making meaningful improvements rather than porting little-changed code to Python 3. That being said, I concede that I'm not a fan of running on a language platform that will be unsupported after 2020. But that platform is stable and until there is more pressure or a compelling need to mass port everything to Python 3, I don't see that happening any time soon.
_______________________________________________ dev-builds mailing list [email protected] https://lists.mozilla.org/listinfo/dev-builds
