Re: [Savannah-dev] Re: Future of new CVS handling

[Marcus Hardt]

On Tuesday 02 December 2003 09:21, Mathieu Roy wrote:
> Marcus Hardt <address@hidden> a tapoté :
> > Hi Mathieu!
> >
> > I'm just starting with the CVS handling. So far I've seen what you
> > modified in sv_groups, the DB and in the frontend.
> >
> > I will want to add three modifications to that:
> >
> > 1. The dir_type_cvs = "subdir-cvs" creation method will need a parameter.
> > Thus I'd like to add dir_type_cvs_paramset, dir_type_homepage_paramset
> > and dir_type_download_paramset, which would contain a list of parameters,
> > separated by ';' used for future extensions.
>
> I do not clearly understand what would be the content of this
> dir_type_cvs_paramset.
>
> At this status, I'm not exactly open to additions in the database
> unless it is a bugfix.

When is the merge done? I think starting a branch from the CERN one does not 
make sense. I'd rather branch that from the main trunk.

> Why would you like to put a specific set of parameters? You directly
> handle that in the Cvs modules. Giving parameters is only useful when
> there is something to configure.
>
> What would be the creation of a cvs subdir, apart a basic directory?

For the hierachical structurization I need to specify that a project is a 
"child" of another project. So I need to configure a "basic sub directory" 
with the parameter "subdirectory of <unix_group_name>".

> > 2. The dir_type_* tool should be changeable per group as well. I'd add
> > the tables and the code. This will raise the security issue: Project
> > admins could
>
> Please, do not do that. I would not like to end up with an interface
> where everything can take three hours to be configured:
>
> There is no point in having differents groups in the same group type
> if they do not share the same basic configuration. What you propose is
> just to override the group type settings everywhere.

Absolutely not! I read somewhere that it was proposed that every setting can 
be enabled by group-type and in case it's enabled be enabled/disabled/
configured by the group-admin. 

What I am proposing is consequently building on this concept: If the 
group_type says dir_type_cvs="cvs_subdir", the admin will be allowed to 
customize a default "cvs_subdir_of=<another_project>/<my_subdir>".
This is simple and fits into (what I understood of) the configuration concept 
of savannah. Please correct me, if my understanding at this point is wrong.

> The way to go is to create a different group type each time the
> configuration must differ. If it must differ at each group, it is
> surely easier to create groups by hand.

I don't understand how to support hierarchies this way.

> > start hacking, by using a leading '/' for the dir_homepage for
> > instacne. For apache (web and download) that might be save, for cvs
> > this isn't.  We need to rely on proper coding of sv_groups and all
> > the *.pm modules.  This can be done, by treating the directory given
> > for the group as a subdirectory of the group_type. For example:
> > <group_type.dir_cvs>/ <group.dir_cvs>
>
> Project admins MUST NOT be able to modify these settings, in any case.

Sure? What about the "Set Active Features" page. All I'm proposing is one or 
two more lines there. Btw: this page allows the project admins to modify 
similar settings.

> > 3. I foresee that the group configuration will depend on the
> >dir_type_<feature> chosen in the group_type. I.e. the parameters that
> >can be specified by a group-admin might be a checkbox, a selection or
> >an input field.
> >
> > What do you think?
>
> I think that I would prefer if you try using the group type to handle
> different group configuration you have instead of implementing a
> configuration for every field.

What I think of with hierarchies is a project consisting e.g. of the following 
workpackages:

<Project-root>
WP-1
WP-1.2.1
WP-1.2.2
WP-1.3.1
WP-1.3.2
WP-1.3.2.1
WP-1.3.2.2
WP-1.3.2.3
WP-1.4
WP-2.1
WP-2.2
WP-2.3.1
WP-2.3.2
...

If I want to run this with the current implementation of group_types I would 
need to create one group_type per node (not per leaf), (i.e. 7 group_types in 
this short example). To me this seems to be a messy and unmaintainable 
configuration

> Savannah already reached a level of complexity far more important than
> what is actually do. Having a tool that is easily configurable and can
> be installed outside GNU is what we achieved recently.
>
> I would not like to see Savannah going in the other extreme position:
> everything configurable but 5 hours to configure an half of the
> system.
>
> A portable function of creation of a CVS repository should take
> something like 50 parameters. The fastest thing to do is to hardcode
> directly the expected method.

Mathieu, please calm down. I am not going to mess up the complete 
configurability! I can surely make it disabled by default (via /etc/savannah/
savannah.inc.pl)


And btw please have a look at all the questions of the installation script. 
Hard coded assumptions where some of my suggestions.

Friendly,
-- 
Marcus