On Mon, Sep 20, 2004 at 03:58:46PM +0200, Mathieu Roy wrote: > Sylvain Beucler <[EMAIL PROTECTED]> tapota : > > > Hi, > > > > After upgrading to Savane a while ago, we had to reinsert a lot of > > custom changes made at Savannah by various people. > > > > backend only?
We have some small changes in the frontend as well. Let's try to detail the current situation: Frontend: - robots.txt: added all admin/ and include/ directories [Elfyn] - account/change.php: updates a list of pending GPG keys to create on the system [sysadmins] - include/sendmail.php: code to send mail in a chroot's environment [corvus] - include/smtp.inc: library using by sendmail.php [corvus] - news/approve.php: unfortunately uncommited change, using URL like 'file.php?param' instead of '?param', which is not supported well by netscape 4 [Sylvain] + mail/admin/index.php and files/add.php: "temporarily unavailable" notices => Check how to add the new sendmail code => Commit the approve.php and robots.txt fixes if wanted => Check whether we keep the GPG keys pending list system Lib [sysadmins]: - DB.pm: functions to manage the list of pending GPG keys to create; hardcoded path to the MySQL socket; - Groups.pm: GPG-related functions: creation of keyrings, and maintainance of a backup of what the system was last time sv_groups was started, allowing to update only the groups' keyrings that did change; we're unsure whether we will keep this complicated, abeilt resource-saving, solution from the sysadmins - User.pm: adding various access restrictions in the beginning of all SSH keys; code to create ~/.gnupg/pubring.gpg => Add a variables for mysql options in the configuration file => Add GPG-related functions and determine what updating method we'll use => Allow the user to customize the authorized_keys file, either via a template (something like $template =~ /<SSH-KEY>/$key/) defined in the configuration file, or using a hook. Backend: - sv_cvstarballs [Sylvain] - sv_users & sv_groups: currently difficult to determine exactly what changed; 2 weeks ago, only sv_groups was modified, with lots of hardcoded stuff, to create the projects, compare the groups and determine which ones should have their GPG info updated, and a clumpsy hack that that makes the project type ignored during project creation. This code was not meant to be integrated in Savane *at all*, and is the main difficulty. Moreover, Elfyn worked on the code to fix the last week's issues at Savannah, and I'm a bit lost right now [all the team] => check if sv_cvstarballs contains interesting code to merge with sv_nightly_cvs_tarball => rewrite sv_groups and sv_users with minimal changes against Savane's; use hooks or temporarily hardcoded functions in lib/ gnu-specific [sv hackers]: => maybe include our version of savannah.el, and some of our scripts; or, remove that directory from Savane > > In order to perform seamless upgrades when new versions of Savane > >are released, we are willing to either: - integrate our changes in > >Savane, - provide a mean to externalize code that is too much > >site-specific (eg, providing a way to add local functions like > >CvsMakeArea in the backend via hooks, as documented in a sv_group's > >FIXME) > > > > Creating a branch would be better to do the job. > > > > Is it ok, and is there any precautions we should take, given that > > another branch is being actively worked on? > > It may create cvs conflicts, depending on how big are the changes > needed. > > For stuff like CvsMakeArea, I think easier, in a first time, to add > directly your own subs within the module, like I did for Gna! ones. > > At a later point (after the release; so after the merge of the dev > branch into the trunk), it will more easy to externalize site-specific > code. What do you think? It is indeed better to do that part of the merge in two steps. -- Sylvain _______________________________________________ Savane-dev mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/savane-dev
