Re: [H-source-users] Introduction

[Yuchen Pei]

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.

Best,
Yuchen

> Cheers,
> Damien


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

signature.asc
Description: PGP signature