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

[Mathieu Roy]

Marcus Hardt <address@hidden> a tapoté :

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

Once no bug will remain in the branch.

> I think starting a branch from the CERN one does not make sense.

Sure.

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

Why not simply make a group type for each projects that should go in a
subdirectory:

        - you have a group which would be the parent project, it have
          a specific CVS directory configured by hand by the
          administrator

        - each child project got the default configuration for the
          group type as CVS, which actually is a subdirectory

Example

1) you create a group type Blabla
2) you create a group called Blabla, in the group type Blabla, and you
configure it's cvs directory to disregard group type setting, by using
the directory /whereismycvs/blabla
3) you configure the group type default cvs directory to be something
like /whereismycvs/blabla/%PROJECT

This way, you have your hierarchy.
   


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

Well, that kind of things can only apply to tools of the web
interface. Project admin should never been allowed to specify a
directory for their download directory on the server. They should be
able to change the url if they want to use something specific, but not
messing with the filesystem itself.

Only server admin should do that.


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

I think it particularly dangerous to implement, since projects are
always considered as autonomous: there is currently no way to know
whether the admin of one project should be allowed to give himself
rights to write on the CVS of another project.

If you really want to do that, you should implement group association,
to allow admin of a project to mess with the administration of another
project.

It seems lot easier to follow the method I proposed on top of this
mail, which would permit any project to edit a specific subdirectory
of a CVS.

This is actually what we do at GNU with the CVS for homepage. Each
groups got a subdirectory in a big cvs called webcvs. 

However, most of the time, were are in the simple case where the
subdirectory have depth equal to 1.

Otherwise (like /webcvs/blab/bla/bla instead of /webcvs/blab), were
forced to edit by hand, in the groupedit page, the appropriate
directory. This is painy but we have less than twenty groups in that
case ; and anyway, there's no other way to handle that.


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

This page allows projects admins to change links! Nothing more, it
does not involve anything real on the server. It just involves the
information printed on the web interface.


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

I'm not sure that I understand what is WP-1, WP-1.2.1 etc...

Is WP-1.2 a subdirectory of WP-1?


If you have 5 directories each time in a subdirectory, I think that
you'll be forced to edit by hand the path each time: in this case, it
is even simpler to edit directory the subdirectory by hand in the
groupedit page, reserved to server admin.


>> 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'm pretty calm, don't worry :)



-- 
Mathieu Roy

  +---------------------------------------------------------------------+
  | General Homepage:           http://yeupou.coleumes.org/             |
  | Computing Homepage:         http://alberich.coleumes.org/           |
  | Not a native english speaker:                                       |
  |     http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english  |
  +---------------------------------------------------------------------+