Hello, > On Feb 4, 2017, at 13:25, Brigham Keys, Esq. <[email protected]> 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
