Hello guys, I'm currently in the middle of migrating git.gnome.org to a new machine and have RHEL6 installed on it. I feel it's a good time for me to report, discuss some proposals and security concerns I have on how the things currently work.
The very first thing I would like to propose is changing the way we currently manage tarballs. The current workflow: 1. You become a maintainer of a specific module 2. You request access to [email protected] to manage releases / tarballs and have access to master.gnome.org 3. The accounts team grants SSH access to the server (by adding the user on the ftpadmin LDAP group) 4. The maintainer logs in into the machine and do the release I have a big security concern about how this currently works, theoretically anyone with access to master.gnome.org can modify every single directory of the /ftp mount and that shouldn't be a problem since all the module's maintainers are trusted developers but what scares me much is giving access to a machine to dozens of people like we do now. Too many SSH keys involved, too many logins. (git.gnome.org works in a different way, SSH is allowed there *just* for pushing to Git, logins are obviously not allowed) The real question is: are tarballs really useful in some way? JHBuild and the new build.gnome.org based on OSTree don't require tarballs at all, they both clone all the needed modules and do the build. I see tarballs being useful for distribution's packagers but shouldn't cgit's snapshots be enough for that? (this is a new feature I've introduced yesterday at git.gnome.org, you can see it in action at [1]) My proposal: 1. Keep ftp.gnome.org as an historycal archive for past releases 2. Change our Git's workflow and introduce pristine-tars / release "tags" (*many* modules do that already) 3. Have cgit manage snapshots / tarballs for all the people that need them (i.e packagers, distributions) 4. Finally drop logins to master.gnome.org. I see another benefit for doing this and that would be reducing the burden of doing new releases to announcing them to the relevant mailing list. Maintainers won't have to scp / install the tarballs to master anymore since that will be done automagically by cgit. --- The next thing I would like to discuss is what the release team feels as a possible improvement for git.gnome.org. Do we need something like Gitlab / Gitorious? [2] - [3] Do we need a code review tool like Gerrit [4] or Review Board [5]? (note that we currently use Owen's splinter on bugzilla for doing code / patches reviews) Are the tools listed above useless for our infrastructure and should we just keep cgit around? if not, what would you like to see installed and deployed on the GNOME Infrastructure to speed up and improve how the GNOME development works? I'm also CCing Colin Walters which might be interested in the whole discussion. Please keep us CCed. Have an awesome day, [1] https://git.gnome.org/browse/evolution [2] http://gitlab.org/ [3] http://gitorious.org/ [4] https://code.google.com/p/gerrit/ [5] http://www.reviewboard.org/ -- Cheers, Andrea Debian Developer, Fedora / EPEL packager, GNOME Sysadmin, GNOME Foundation Membership & Elections Committee Chairman Homepage: http://www.gnome.org/~av
_______________________________________________ [email protected] https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
