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

[Marcus Hardt]

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'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. Get an account at savannah.fzk.de and I can add you as and admin 
to
        the testproject so you can see the Administrative frontend as well.
          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.

> 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.

-- 
Marcus