[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [H-source-users] Introduction

From: Yuchen Pei
Subject: Re: [H-source-users] Introduction
Date: Mon, 19 Jul 2021 12:19:39 +1000
User-agent: mu4e 1.4.13; emacs 27.2

Hello Damien,
Damien Zammit <damien@zamaudio.com> writes:

Hi Yuchen,

On 15/7/21 10:34 am, Yuchen Pei wrote:
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.
A few years ago, I volunteered to help on h-node.

I wanted to figure out what was hindering the development of this project. 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.

I had a look at the server code and compared the files with the latest commits on the repo, and it appears to me the only unmerged change is commit efd48dee15bbdf3a5a2b6a5cf724ca586568b53e. So the server code is rather up to date.

But, the server directory does look a bit different from the repo.

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 looks like the easygiant software is no longer actively maintained ( https://git.savannah.nongnu.org/cgit/h-source.git/tree/h-source/README.txt), and the website (www.easygiant.org) looks like it has nothing to do with the web software.

Furthermore, easygiant is not supported by php-7 which is the version on the staging server. Therefore it is blocking spinning up the staging server.

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.

There's a schema file in the repo (https://git.savannah.nongnu.org/cgit/h-source.git/tree/h-source/tables.sql). Is it not sufficient for development?

I have also cc'd sysadmin@fsf in case they have something to say about getting a sql dump out of the fsf machine.

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 agree something needs to be done with the outdated code to unblock getting the staging server up and running, and there are these two options you mentioned (rewriting in something modern vs. updating the php-based codebase).

Since my php knowledge is hello-world-level and I'm more comfortable with a few other languages including python, I am not against rewriting in python. I haven't worked with django though.

Taking a step back, why do you think django may be a better choice compared to other server software? Would it be easy to rewrite the api with django as well?

I would be happy to devote some time to rewriting the site in django, but I would need access to a partial database dump as described above.

Great, thanks a lot for offering to help! Let's wait a bit and see if there are other proposals. Meanwhile would you mind writing a proposal, including why django is a good choice, how much work is needed and how we can break down and divide the work? For a partial database dump see my comment above.

I will create an issue to track this.



PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]