[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-dev] Re: Merging GNU Savannah and the CERN branch
From: |
Marcus Hardt |
Subject: |
[Savannah-dev] Re: Merging GNU Savannah and the CERN branch |
Date: |
Thu, 4 Sep 2003 15:46:04 +0200 |
User-agent: |
KMail/1.5.3 |
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