On Tue, 23 Dec 2008, Allan McRae wrote:
Abhishek Dasgupta wrote:
2008/12/23 Eric Bélanger firstname.lastname@example.org:
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.
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.