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

[Marcus Hardt]

[..]

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

My suggestion is to implement everything with an if{$sys_hierarchy=='enabled) 
inside the CERN tree. These parts can be merged to the main trunk at a much 
later point.

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

Well, but very manual and with a lot of project types, which is not nice. (As 
described below.)

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

Yes, that's why, in my current implementation I'm filling a selection field 
with available subdirectories and use a similar string like %PROJECT for the 
subdirectory I create. This way it's rather safe.

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

Yes and no:
First it does not make a difference for the admin, if things are implemented 
in one or the other way. (many group_types or enhanced group_type).
The no part: B is a subproject of A. When B is approved, people will find a 
subdirectory B in their toplevel directory, which they cannot write, unless 
being member of B. B members cannot write into A's directories per se. I 
think of it like for instance in the savannah cvs you have the frontend and 
the backend people, who work in the same project-type called savannah. This 
gives liberty to the frontend people to set up a forum, a bugs and an admin 
group.

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

This is an interesting idea: One could declare a whole project subproject of 
another project and download-dir, website-dir and cvsdir of B would be 
subdirectories of A. B would then only be approved, if A AND the savannah 
admin agree. Maybe admin of A should then also be admin of B.

The system can reflect these information inside most entries which are already 
in the DB. Only a project would need to know, if it's a subproject, and who 
is the parent.

Might be even cleaner to implement. What do you think about this?

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

If I understand correctly I will need more than 20 group_types only for 
CrossGrid.

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

Yes, you can think of the '.' as a '/'.

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

I could do that. Right. Will think and experiment with this one.

Btw. concerning security it like this in our implementation: Server admin 
decides on project approval, which directory is adequate.
Perhaps this feature needs only to be put on the "register new project" pages 
and can then be approved by the admin.

[..]

-- 
Marcus