Re: [Savannah-hackers-public] New frontend for Savannah

[Assaf Gordon]

Hello,

> On Feb 4, 2017, at 13:25, Brigham Keys, Esq. <address@hidden> wrote:
> 
>     I started some discussion about GNU Savannah in the gnu-prog-discuss 
> mailing list and I think the conclusion was more or less that rather than 
> replace Savannah, we could potentially get a new web frontend for it. So 
> first thing to ask would be are you guys willing to have a new frontend for 
> it that reflects modern web standards?

In short, yes.

If someone (you?) builds a drop-in replacement for the current PHP code,
I'm sure there won't be any objections to replacing it.


To start, I recommend using the following resources
to learn about the current web frontend and backend database:
https://savannah.gnu.org/maintenance/RunningSavaneLocally/
https://savannah.gnu.org/maintenance/SavaneInABox/

I recommend carefully reading previous related discussion:
https://lists.gnu.org/archive/html/savannah-hackers-public/2014-09/msg00000.html
https://lists.gnu.org/archive/html/savannah-hackers-public/2016-02/msg00000.html


In terms of actual replacement, the easiest approach would be to incrementally 
improve
the existing PHP code. Take care to include support for the included fragments 
of
external files as explained here:
 
https://lists.gnu.org/archive/html/savannah-hackers-public/2016-09/msg00009.html
Such incremental changes would be the easiest for us to integrate.

Note that the 'savane' code base and UI supports themes, so perhaps you can 
start there
(i.e. create a new theme that uses modern web standards).

A more complicated approach would be to rewrite the PHP code from scratch.
This has been attempted few times, never to fruition:
https://lists.gnu.org/archive/html/savannah-hackers-public/2014-10/msg00009.html
http://gna.org/p/savane

Personally, if I just had enough free time, I would gladly make such attempt 
myself
(I'm sure many volunteers feel the same way). But having worked on Savannah
for slightly more than 2 years, I came to realize the complexity of the current 
system,
and it won't be an easy task (IMHO). The out-dated "bug trackers" represent an 
especially
sore spot.
<personal gripe>
It's one thing to write emails about switching to another system like "Apache 
Allure",
it's a whole different ball game to actually implement it.
If you can convince GNU and FSF members that Savannah's bug-trakcers should be
dropped and instead we should switch to an off-the-shelf existing solution -
you'll have my full support (that's my personal opinion, not sure if other
savannah people share it). Just be sure to actually reach a consensus as to
which product to use, I promise to help you implement it.
</personal gripe>

If you do rewrite the web-code from scratch, I *highly* recommend keeping the
database structure intact, particularly the users and groups tables ("group"
is the internal name for "projects").
Changing those will require many intricate changes to other system components,
and will require orders-of-magnitude more effort.
To learn more about other aspects of Savannah, see these:
http://savannah.gnu.org/maintenance/SavannahInternals/
http://savannah.gnu.org/maintenance/UserAuthentication/
http://savannah.gnu.org/maintenance/SavannahServices/


Regardless of which method you choose -
we'd expect you to "stick around" and maintain your code for a
long period. Switching to a new codebase and then having the author
disappear is a recipe for disaster.


Lastly, please remember that Savannah is run by volunteers
with only minimal help from FSF, and yet it has to comply with many
requirements imposed by GNU and FSF.
Any savannah replacement must be able to implement these requirements
(or, alternatively, you can try to convince people to drop them).

regards,
 - assaf