On Mon, Oct 07, 2013 at 09:47:18AM +0200, Massimiliano Torromeo wrote:
What about handling mass-edits?
Right now I feel the approach of having one repo for core/extra and one for community with branches for testing would be better, my only issue with this being that I wouldn't tag each package release in it and I don't really see the need for it.
I am unconvinced on the advantages of having separate repos for each package.
I think the following approach would be a very flexible one: main repo's: * core with branches: * staging * testing * master (stable) * extra with branches: * staging * testing * master (stable) * community with branches: * staging * testing * master (stable) All packages would be submodules of the specific repo's, this means if you want to do mass editing you can do it from within the main repo and push all your submodules from there. With some scripting this can be done in an easy way. The tagging of every package would be pointless in this scenario because you can just indicate it in the commit and people wanting to see the whole history can check the tags and commits in the package specific repo's. Depending on the repo and branch we could detect how the package must be build. Which could make it as simple as just having a build-i686 and build-x86_64, those can detect repo/branch and determine what pacman configuration must be used, with *-testing, with *-staging. The biggest problem with git is the removal of submodules, but soon [1] it will be improved. [1] https://github.com/git/git/commit/95c1641 -- Ike