On Tue, 23 Dec 2008, Allan McRae wrote: > Abhishek Dasgupta wrote: > > 2008/12/23 Eric Bélanger <belan...@astro.umontreal.ca>: > > > >> I think it all boils down to what would be the easiest/best solution in > >> terms of permissions handling. If we don't give them access to the > >> server, then a separate community-testing that would be updated with a > >> daemon like community might be better. We also want the TU to only be > >> able to put only community package in testing, modify them in testing if > >> needed > >> and then move them back to community. If they have access to the server to > >> run the db scripts and we can set proper permissions on the testing repo > >> then we could just have one testing repo. > >> > >> > > > > Why not merge extra and community, and give permissions accordingly? Even > > now there are quite a few packages in extra that are orphaned or have > > not been updated in ages. Some popular packages were moved to > > community recently, for example. Thus we need to shift around > > packages between repositories depending on who is maintaining it > > (dev or TU). If extra and community were merged, such problems > > would not be there. Some packages are more important, and permissions > > could be set to allow only certain people to write to that package > > directory. > > > > AFAIK, it is a lot easier to give permissions for certain repos rather > than parts of repos, though I could be wrong. Having the [community] > repo set up like [core] and [extra] would mean that moving packages > to/from community would involve running a single script, much like > currently moving packages from [testing] to the main repos. > > Allan >
I was thinking the same thing. If we merge extra and community, we'll need to set permissions on a package-by-package basis instead of a repo-by-repo basis. Better keep them separate. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.