[Savannah-dev] Re: Merging GNU Savannah and the CERN branch

[Mathieu Roy]

Marcus Hardt <address@hidden> a tapoté :

> On Thursday 04 September 2003 13:34, Mathieu Roy wrote:
> > Marcus Hardt <address@hidden> 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