> > Incidentally I would like to see more operations on the projects (like > > rename, delete, propagate a group type change...) in the backend, but > > I guess that's something we'll discuss later - there're other > > priorities right now :) > > Can you details what would each action mean. > For rename, when it happens, I usually rename the group via the > frontend, and a few hours later move the content of the previous cvs. > In delete case, well the backend handle it (without touching cvs > trees).
That's not something I though a lot about. But anyway: - rename: the goal is to avoid the manual 'cvs move' step (among others); it would still require admin approval, but not admin work :) - delete: when a project is deleted, it should be completely deleted IMHO. If I want to keep its contents (eg. a project that became proprietary), I just remove everybody from the project. If it is a redirection, then: - group type change: when setting up a redirection (ie. a project from Savannah moved to Gna!), I close all active features, and I want to remove the contents to avoid any confusion (some people could still try to cvs update). That's not the same thing as simply deactivating all 'active features'. Likewise, when moving a project from non-GNU to GNU, the webpages and the mailing lists have to be moved. Using a more complex Group model (with the pros and the cons this implies) would avoid manual admin work, as well as get rid of using too much site-specific scripts. All operations would be made by the backend. Each project type would be given a few procedures implementing a standard interface like Create, Move, Delete, etc. It would be more sophisticated than 'present in the system/not present in the system'. This would also allow people with admin privs but no root access to still perform some easy tasks. -- Sylvain PS: speaking of redirections, how is the wesnoth project's move going?
