forums, mailing lists and other tools

[Daniel Pocock]

On 18/01/18 10:13, Mirko Boehm wrote:
> Hello there!
> 
>> On 16. Jan 2018, at 13:57, Max Mehl <max.mehl at fsfe.org
>> <mailto:max.mehl at fsfe.org>> wrote:
>>
>> # Daniel Pocock [2018-01-16 13:43 +0100]:
>>>> Discourse is somewhat overwork as we would have to patch various parts
>>>> of it to either remove JS or free/libreate it.
>>> Would packaging the Discourse JavaScript into Debian satisfy those
>>> concerns?
>>> Is there enough interest in this topic to start building a wiki page
>>> about it?
>>
>> I want to highlight that some volunteers are already experimenting with
>> a Discourse instance for FSFE, mainly Nikos IIRC (in Cc). Please join
>> them if you want to support them in their work.
>>
>> https://git.fsfe.org/fsfe-system-hackers/community
> 
> +1 for investigating Discourse. It was reviewed at the recent community
> meeting in Berlin and excitement was great. I agree with Daniel's
> concerns, and feel that the way Discourse works can help allay them.
> Especially the bridging of the traditional mailing list mode with a
> forum web interface can help making our discussions accessible to a
> wider range of people. The client-side Javascript to me is not a
> relevant issue anymore since JS is an open standard and browsers are
> sandboxed these days.
> 


There is an issue:
a) if the JavaScript is distributed as minified blobs and we can't
rebuild it easily from source,
b) if a large application makes heavy use of things like the NPM
repository for its build process

A lot of developers have given up trying to package large
JavaScript-heavy web applications for Debian because they are incomplete
or not really free software somewhere in the stack or the tool chain.

The front-end developers end up using other repositories like NPM,
thinking it is easier than doing something through Debian or Fedora, but
it turns out that is just laziness, this type of thing would never
happen if the code had been properly packaged:

https://developers.slashdot.org/story/18/01/13/0149252/erroneous-spam-flag-affected-102-npm-packages

https://developers.slashdot.org/story/16/03/23/0652204/how-one-dev-broke-node-and-thousands-of-projects-in-11-lines-of-javascript

Conclusion: if stuff is not properly packaged in the beginning it
becomes a minefield for support in the future.  If something is in a
proper package in a distribution then it is replicated into all the
mirrors, the CD images, etc and you can always rely on it being there
for you in the future and nobody can pull the rug out underneath you.
As FSFE and many other non-profits rely on volunteers for some of the
support work we shouldn't be leaving them exposed to things that can
disappear like that.

That said, I am keen to see tools developed for replicating things from
volatile repositories like NPM and Maven into proper packaging, it is
actually a GSoC project[1].  While the emphasis is Java, some parts of
the project apply to JavaScript.

Regards,

Daniel


1.
https://wiki.debian.org/SummerOfCode2018/Projects#SummerOfCode2018.2FProjects.2FRecursivelyBuildingJavaDependenciesFromSource.Recursively_building_Java_dependencies_from_source