Re: [H-source-users] Introduction

[Bone Baboon]

Yuchen Pei writes:
> I am volunteering to work on h-node and the FSF sysadmins have given
> me access to the server. My first task is to try to get a dev site
> working on trisquel 9 with its newer PHP and any suggestions on
> getting that to work are welcome.

Damien Zammit writes:

> As it happens, the server side code is out of date with the h-source
> codebase, and may have been altered without being under version
> control.  Therefore, the code on h-node server is a different
> version than the h-source repo, as I understand, but I do not have
> access to the server.

> Antonio, the main developer, has stopped developing h-node, but has
> continued working on the "easygiant" framework that underpins the
> h-node server code.

> It is my opinion that to bring this project into a more up-to-date
> and workable state, the database should be preserved as a dump and
> kept on the server, but all tables (**except** the user table(s)
> containing sensitive password hashes) should be available for
> study/development.

> I think it would be time better spent to rewrite the site in
> python-django and preserve the existing data, than to try to pick up
> the pieces on a php-based codebase that has fallen out of sync with
> the code repo.

I would like to suggest an alternative to these two options of:
* Fixing the current PHP h-node web application so that it is
  maintainable.
* Rewriting the application as a Python 3 web application.

I would suggest converting the h-node web application into a Git
repository.  This could be easier to accomplish as it can be done with
stable existing free software.

Here is an overview of the concept of converting h-node to a Git
repository:

* The existing h-node directories data would be converted to plain text
  files in a directory structure.
* The plain text files and directory structure would be part of the
  h-node Git repository.
* The plain text files would be in a format like markdown or org-mode.
* The plain text files (h-node content) would be compiled to HTML and
  served as a read only browseable static website.
* A stagit or cgit static website to browse the h-node Git repository
  would be served.
* People who want to make contributions to h-node could clone the
  repository and work on their contributions offline without a browser
  or JavaScript using free software tools of their choice.
* A web browser would be optional as all the interaction with the
  repository could be done using Git.
* Contributions would be submitted by Git patches and reviewed by
  individuals with commit access to the h-node repository before being
  merged.
* Git being unfamiliar to some people could be mitigated by providing a
  detailed tutorial on how to contribute to h-node using Git.  
* A Git repository and two static websites would be easier to maintain
  than the h-node web application and it's database.
* The Git repository approach would use several specialized programs
  instead of a monolithic web application and it's database.
* The Git repository approach would be more resilient to change as any
  of it's components could easily by switched out with another existing
  stable free software alternative.

I recently requested feedback on what people thought of the Free
Software Directory (FSD) being a Git repository.  Discussion about the
idea can be seen here:

<https://lists.gnu.org/archive/html/directory-discuss/2021-07/msg00010.html>

Most of that discussion applies equally well to h-node being converted
to a Git repository (except the MediaWiki discussion).

What do people think about h-node being converted to a Git repository?