All, I think that everyone has been looking at gitorious and gitlab, the main systems with front-ends for their users. We already have a front-end for our users, all we need is the backend. I have given it some thought previously (if you want, look up the mail), and one of the best solutions seems to be gitolite[1]. We would need a way to work with the permission config files based on AUR users signing up and uploading files, however I think that this is doable. On Thu, Jan 09, 2014 at 07:10:27PM +0800, Techlive Zheng wrote:
on 14-01-09, techlive zheng wrote:
I don't think we should support `git-push` at all, the reasons are simple:
* Git allows overwriting the history by doing a force push `git push -f`. As a community PKGBUILD publishing platform, the git history of a PKGBUILD should not be allowed to be tampered with, whether accidently or intentionally, it should reflect how the PKGBUILD envloved from the start, not the one someone carefully crafted.
* Changed history will cause conflit on `git pull`, which is not something we want to deal with everyday.
Instead, we should stick on the `src.tar.gz` tarball submitting, and make the Git commit on the server.
At least, push access should not be granted to normal user, only to TUs.
All of this can be disabled in any good git management platform, I know gitolite does. We could use the aur-dev mailing list to request force-pushes if need be.
Also, if we allow normal user to push directly with Git, it will be harder to do sanity check. One can push anything, not just the packaging files, but anything, binaries, compressed source/build tarballs, even files unrelated to Arch packaging at all. These malformed files can exist not only in the Git HEAD, but can be intentionally hided in the history, makes it hard to control the space quotas.
Not really. We can use git hooks to check the size of the files that are pushed, and it won't make it any harder to control space quotas. If the repository goes over a couple of megabytes, then they can't push. End of story. Another thing that people can do is use submodules[2] in their AUR repositories if they have some kind of binary file they can't get rid of. This would keep the size on the AUR down while also allowing them to have a 4M image in their AUR package.
We'd better only access 'src.tar.gz' tarball and control the commit process on the server on our own, so that we can do necessary sanity check to ensure files to be commited are really what they claim to be.
While this is an option, I don't think that the arguments above make it the better option of the two. In fact, something that we may want to look into is keeping the legacy .src.tar.gz files around, but also having users with the ability to `git push` to their repositories. [1]: http://gitolite.com/gitolite/index.html [2]: http://git-scm.com/book/en/Git-Tools-Submodules Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF