On Tuesday 02 December 2003 15:11, Mathieu Roy wrote:
> Marcus Hardt <[EMAIL PROTECTED]> a tapoté :
> > [..]
> >
> >> > 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.
>
> I cannot agree with that conf variable: we are now talking about
> method to create a CVS directory. Why should it be a system
> configuration parameter? It should just a be a matter of using that
> method or not.Yep, but I think it's easiest to avoid merging these into the main trunk. However, that was a quick shot and is defnitely not clean! > [...] > > >> 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? > > I think that this major change is clearly not going to happen on the > current branch which is supposed to be feature-frozen :)) > > I still think that you can have the desired behavior by using group > types. > > I'd like to point out that it is not just up the interface to permit > that, the backend should handle a third case: no group information ; > not group type information ; but relations between the groups > themselves. > > Possible to do, but not so trivial I'm afraid. Instead of doing > > check group settings > -no settings-> check group type settings > > it would be something like > check group settings > -no settings-> check parent group settings and mix that > settings with the group name > -no settings-> check group type settings and mix that > settings with the group name > > It creates one more level but the purpose is almost like the group > type one. O.k. looks like quite some work. > >> 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. > > Apart from the frontpage, it should not be so problematic. What would > be the problem to have a lot of group types? Well, then I could do most things by hand as well. > I think it would be more interesting to enhance the group type than > building a parallel system with almost the same purpose. I'm ready to enhance the group type ;-) > But you have the exact worse case, a hierarchy with different levels > of depth, while the group type handle only one level of depth - and > creating a group type by level of depth is surely not an option in the > long run. Well, not only would that require one groupt type per depth, there would be one per directory node. > >> 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. > > If you are forced to do an extra-step "this project belongs to this > one", it is maybe even faster to directly edit the group specific > variable, that override the group type, because if I understand well, > in your case very few projects can be satisfied by group type > configuration. > > In your case, the faster solution would maybe even to add a special > PHP or perl script that would feed these settings semi-automatically. > > For instance, you can edit the bottom of the page "groupedit" in > server admin. Maybe you could add a pointer to a PHP page of yours > where you would just have to put in a form the name of the parent > group, and these settings would get automatically fed from that > information. > > It is not the cleanest thing but it is a way that would require very > few changes on to get something working with the current branch. I hope I don't need an additional DB table for that. I will see. Might even be, that I just turn off the backend for my solution until the CERN branch is merged. > Apart from that, if you really think that a way to make project > considered as part of other projects, independantly of group type, > should be implemented, you should details exactly how you would like > to implement that and propose a timeline. It would be a good starting > point to open a new development branch -- but as you said, only after > the current branch is merged in the trunk. > > I understand that your solution is probably the cleanest way to do a > hierarchical system with different level of depth ; so in the end, I > would not be against such an implementation. But right now I'm more > concerned about having every existing things working as expected. > > As said before, you are exactly in our case, at GNU, of /webcvs. But > fortunately, we usually have only one level of depth. O.k. I will think things through and most probably go for an intermediate solution. -- Marcus
