Marcus Hardt <[EMAIL PROTECTED]> a tapoté : > On Thursday 04 September 2003 13:34, Mathieu Roy wrote: > > Marcus Hardt <[EMAIL PROTECTED]> a tapoté : > > > Hi! > > > > > > The database removing/renaming/adding seems a serious step to me, which > > > should only be done once. > > > > > > At savannah.fzk.de we added two extra tables to the database which I'd > > > like to find in the refurbished savannah once we start merging our > > > branch. > > > > > > For the way we handle the subdirectories of CVS we need these entries in > > > the groups table: > > > CREATE TABLE groups ( > > > cvs_subdir varchar(100) NOT NULL default '', > > > cvs_subdir_of varchar(100) NOT NULL default '', > > > use_cvs_subdir int(11) NOT NULL default '0', > > > } > > > > > > In case you plan to change the cvs handling itself I'd like to be > > > involved in the discussion > > > > We will change the cvs handling itself because we'll add some modular > > support for cvs/arch/subversions. We will surely not keep database > > field with "cvs" within their name but names less specific. > > o.k. I'm not happy with how I added my extensions. I modified > gnuscripts/sv_aliases just before all its changes where reset to a way older > version. Best will be if I participate when you redesign these codesnippets > in order keep our functionality available.
Basically, we are going to clean the database, so we need to know exactly what kind of information you need to provide. > > Basically, we'll make a proposal for a new database structure, > > we'll post it on that list and we hope to get your comments. > > > > The new database will surely be incompatible with the previous one but > > we'll write script to automate the update. > > > > Plans common between GNU and CERN: > > - the bug tracker codebase will be the codebase for any > > trackers > > - inclusion of the PAM support from CERN, removal of the > > Kerberos stuff (kerberos can use PAM) > > - each link on the top menu will be configurable by the > > projects leaders, as long as the whole system admin accepted > > it for a group type. > > - the user management will be slightly modified, in the spirit > > of the CERN work: > > - a user can propose himself for a project, the admin > > must approve him > > - a project admin can use a search tool to get a list > > of user he can add by selecting them on a list. > > - mailing list stuff will be modular like the cvs stuff. > > (function that determine whether you use mailman or > > majordomo or something > > > > GNU plans: > > - mail interface to trackers with gpg > > FZK plans: > - keep the Forum. We have extended it to be a hypernews-like > mailinglist. > i.e. the "monitor forum" feature now properly handles replies to the > monitor- > mails. That's fine, we would be glad to see the forum reworking on the CVS. > Get an account at savannah.fzk.de and I can add you as and > admin to the testproject I'll do it. > so you can see the Administrative frontend as well Ok. >. For this > we will need the following tables: o forum o forum_group_list > o forum_monitored_forums o forum_saved_place o forum_thread_id > Currently unused is this table: o forum_agg_msg_count > > In source that is: > -- > -- Table structure for table 'forum' > -- > > CREATE TABLE forum ( > msg_id int(11) NOT NULL auto_increment, > group_forum_id int(11) NOT NULL default '0', > posted_by int(11) NOT NULL default '0', > subject text NOT NULL, > body text NOT NULL, > date int(11) NOT NULL default '0', > is_followup_to int(11) NOT NULL default '0', > thread_id int(11) NOT NULL default '0', > has_followups int(11) default '0', > PRIMARY KEY (msg_id), > KEY idx_forum_group_forum_id (group_forum_id), > KEY idx_forum_is_followup_to (is_followup_to), > KEY idx_forum_thread_id (thread_id), > KEY idx_forum_id_date (group_forum_id,date), > KEY idx_forum_id_date_followup (group_forum_id,date,is_followup_to), > KEY idx_forum_thread_date_followup (thread_id,date,is_followup_to) > ) TYPE=MyISAM; > > -- > -- Table structure for table 'forum_group_list' > -- > > CREATE TABLE forum_group_list ( > group_forum_id int(11) NOT NULL auto_increment, > group_id int(11) NOT NULL default '0', > forum_name text NOT NULL, > is_public int(11) NOT NULL default '0', > description text, > PRIMARY KEY (group_forum_id), > KEY idx_forum_group_list_group_id (group_id) > ) TYPE=MyISAM; > > -- > -- Table structure for table 'forum_monitored_forums' > -- > > CREATE TABLE forum_monitored_forums ( > monitor_id int(11) NOT NULL auto_increment, > forum_id int(11) NOT NULL default '0', > user_id int(11) NOT NULL default '0', > PRIMARY KEY (monitor_id), > KEY idx_forum_monitor_thread_id (forum_id), > KEY idx_forum_monitor_combo_id (forum_id,user_id) > ) TYPE=MyISAM; > > -- > -- Table structure for table 'forum_saved_place' > -- > > CREATE TABLE forum_saved_place ( > saved_place_id int(11) NOT NULL auto_increment, > user_id int(11) NOT NULL default '0', > forum_id int(11) NOT NULL default '0', > save_date int(11) NOT NULL default '0', > PRIMARY KEY (saved_place_id) > ) TYPE=MyISAM; > > -- > -- Table structure for table 'forum_thread_id' > -- > > CREATE TABLE forum_thread_id ( > thread_id int(11) NOT NULL auto_increment, > PRIMARY KEY (thread_id) > ) TYPE=MyISAM; > > In case you're interested in details of the source, the following files are > relevant: > http://savannah.fzk.de/cgi-bin/viewcvs.cgi/internal/gridportal/gridportal/gnuscripts/sv_aliases > http://savannah.fzk.de/cgi-bin/viewcvs.cgi/internal/gridportal/gridportal/www/forum/ > > Please Note that "savannah as of June 2003" in CVS already contains quite > some > modifications to what I took from your CVS. Ok. > > > > Please, list us what kind of database field you would like to see > > and why (apart for the ones you already mentionned), and more > > generally on which feature you plan to work that would require new > > fields/table. > > > > Since there was a lack of communication between GNU and CERN, we would > > like in the future to avoid any bad experience like that, being forced > > to do a big merge. It means that modifications people made on Savannah > > should never be on the codebase until they plan to commit them soon on > > the GNU savannah CVS. Everything that need to be changed/implemented > > must be done in a way to permit everyone to use the same CVS. Which > > means that every specific stuff should only be in configuration parts. > > > > Marcus, you're not member of the project if I'm not mistaken. If you > > have to implement stuff on savannah and want to give it back to > > project -- which is the more convenient way for you to benefit of the > > progress of savannah, tell us what you plan to do. Once we agree on > > what needs to be done in the better way for GNU savannah, we'll give > > you CVS write access. > > Yep, we have implemented quite a bit concerning the forums and the cvs. We > never committed them back because there was no way to do this without > possibly breaking savanna.gnu.org accidentially. Thus our merger became a big > pile of work which we keep on pushing ahead until somebody here does the > work. The intention stays to participate in development, however, manpower is > somewhat short. Ok. In the future, every cosmetic/bugfixes should directly included in Savannah and the others parts should be done on cvs branches that can be merged easily. Regards, -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
