Hi, On Mon, 23 May 2011, Roland Mas wrote: > We should now be in the phase where we pretend it's done, wait for the > complaints, and fix the problems as they are reported (or laugh them off > when they come from the too-common expectation that Alioth can be used > to run any random stuff by anyone).
1/ We lost all the ACL in the migration. Many teams rely on ACL to grant commit rights to all DD, they are also used to ensure the entire team keeps full write access (even when someone with a restrictive umask pushes new files). See how the script /srv/git.debian.org/bin/newrepo setup the ACL and while I was part of the team I have run dozens of time the scripts /srv/home/rhertzog/bin/add-Debian-acl.sh or /srv/home/rhertzog/bin/add-group-acl.sh on various SCM directories. The issue has been brought up on IRC a couple of times but I have yet to see an answer on this topic. It would be a major step backwards for collaborative maintenance if ACL were no longer allowed. And if you plan to allow ACL again, will you restore the old ACL or shall we request them again one by one? It might be a good idea to setup a system where you store the ACL in a textual file so that you can easily restore them without going through the pain of backing them up explicitly. By default each SCM directory should have write access for its own group but any other ACL would be explicitly listed in a file: /srv/git.debian.org/git/collab-maint g:Debian:rwX /srv/svn.debian.org/svn/collab-maint g:Debian:rwX And a simple script could do the restore: (while read dir right; do sudo setfacl -R -m d:$right $dir; sudo setfacl -R -m $right $dir; done) <list-of-acl 2/ Commit mails cannot be sent from vasks, I get a local bounce: | From MAILER-DAEMON Tue May 24 06:14:49 2011 | Return-path: <> | Envelope-to: hert...@vasks.debian.org | Delivery-date: Tue, 24 May 2011 06:14:49 +0000 | Received: from Debian-exim by vasks.debian.org with local (Exim 4.72) | id 1QOktF-00048B-BO | for hert...@vasks.debian.org; Tue, 24 May 2011 06:14:49 +0000 | Date: Tue, 24 May 2011 06:14:49 +0000 | Message-Id: <e1qoktf-00048b...@vasks.debian.org> | X-Failed-Recipients: debian-dpkg-...@lists.debian.org, | dpkg_...@packages.qa.debian.org | Auto-Submitted: auto-replied | From: Mail Delivery System <mailer-dae...@vasks.debian.org> | To: hert...@vasks.debian.org | Subject: Mail delivery failed: returning message to sender | | This message was created automatically by mail delivery software. | | A message that you sent could not be delivered to one or more of its | recipients. This is a permanent error. The following address(es) failed: | | debian-dpkg-...@lists.debian.org | Mailing to remote domains not supported | dpkg_...@packages.qa.debian.org | Mailing to remote domains not supported 3/ Others have already pointed it out, but I also agree that breaking git:// or svn:// URLs for anonymous access is not really a good idea. I don't know the reason for the change but I would be interested to hear it. I don't know if git or svn supports SRV records, but if they do it would be great to setup those so that they automatically use the new host. In general I think it's a good idea to offload anonymous read-only access so that we have the best performance for commits and similar stuff but this should be mostly transparent for the user. Having to remember to switch to "anonscm" is annoying. Anyway, thank you all for the continued work on Alioth. I know how painful that can be at times. ;-) Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110524070912.ga32...@rivendell.home.ouaza.com
