> Am 19.01.2021 um 18:40 schrieb H. Nikolaus Schaller <[email protected]>: > > >> Am 19.01.2021 um 18:20 schrieb Ivan Vučica <[email protected]>: >> >> On Tue, Jan 19, 2021 at 5:11 PM H. Nikolaus Schaller <[email protected]> >> wrote: >>> It did not need any maintainance in between. But it could be copied to >>> any Linux host with apt-get install apache2 php mysql in ca. 30 minutes. >> >> This assumes you're always around -- or someone else that has dealt >> with PHP and MySQL is around. > > It has to be done only once. > >> >>> >>>> Existing system works, and it'll keep on working, but I am neither >>>> submitting software to the existing system or contributing changes to >>>> it. >>> >>> Why not? >> >> - The code is not in the main repos > > It is on github: https://github.com/goldelico/swi > > and can easily be integrated to the repos > >> - The deployment procedure is unclear > > Indeed, tat is a weak point, but some information is in the README.md. > Well not about the precise installation on gnustep.org.
Ok, I have researched. It was uploaded to the same location as the homepage through CVS. So it simply sits in the root directory of the webspace served by www.gnustep.org. I have no idea what the host was... Well, it could have been cvs.savannah.gnu.org:/web/gnustep > >> - I don't have admin privileges to touch the database The MySQL database is database "gnustep" running on mysql.gnustep.org. This server resolves to mysql2.oxymium.net whoever operates that. There is a user+password stored in the config.php as with all such installations. So it could be possible to pull the DB as SQL-INSERT statement format by mysqldump. Or everybody can pull it through the .plist in XML/PList format. In summary this means as long as the new www.gnustep.org server has PHP and can access mysql.gnustep.org nobody should even recognise that there was a move. So the database is not of concern. Only running PHP on the www.gnustep.org server. >> - Even as a regular user I don't have any sort of login credentials. > > What do you need them for? The workflow is based on the assumption > that everybody can openly contribute and reviewers/moderators delete > spam. > >> >>>> Moving off of it means less maintenance for whoever's running >>>> machine underlying gnustep.org, and easier contributions by people who >>>> can write Markdown, but not necessarily want to touch PHP. >>> >>> Nobody needs to write PHP (except me as I have written the original >>> code). >> >> No other person who wants to modify the site should need to touch PHP? > > In 8 years nobody wanted to modify it. And to be honest, there are more > people proficient in PHP than in ObjC or Jekyll or others. It is not > at all exotic. > >> >>> You as the user do not need to work that way. Like on Wikipedia you >>> do not get into touch with the MediaWiki code (which is also PHP + MySQL). >>> >>> You just type content into the web form and press the submit button. >> >> Assuming that's the only thing that should be done. > > What is missing? What else should be done? > >> >>>> Storing a list of software in a version control system seems like a >>>> much simpler solution. >>> >>> That is probably a misconception. The database *is* a version control >>> system. Just not git. >> >> How trivial is it for me to clone it to my local system *right now* >> without having any access to the database, or any login credentials? > > What is the benefit of cloning it? > > Yes, the MySQL database is quite hidden somewhere on the www.gnustep.org > server. Even I do not remember. This should be changed. > >> >> How do I know who is the approver for the changes? > > Ok, good point. These people should be listed somewhere. > AFAIR, currently it is Riccardo and me. > >> >>>> "It already exists" is an easy answer ignoring the question "who has >>>> the backups, who can create the backups, who can approve the changes, >>>> who can fork the site, and who maintains and pays for the existing >>>> system". >>> >>> There are answers, but nobody has asked yet. >> >> Well now. > > Fine! > >> >>>> Static documentation sites edited via version control systems are >>>> absolutely normal today. >>>> >>>> And adding minimal interactivity via Javascript is the very reason why >>>> Javascript came to be in the nineties. >>> >>> Yes, I know the history. And because JavaScript has limitations there >>> is still a lot of server-side activities. And PHP and MySQL became the >>> standard after that. >> >> They're less and less of a standard these days. > > This is not my impression. But I may be biased. >
