On 14/06/11 at 21:03 +0100, Stephen Gran wrote: > This one time, at band camp, Gerfried Fuchs said: > > Hi! > > > > * Stephen Gran <sg...@debian.org> [2011-06-11 16:06:58 CEST]: > > > This one time, at band camp, Andreas Tille said: > > > > I would like to repeat my question about UDD access from alioth (or one > > > > / both of its successors): Is there anybody working to reenable the UDD > > > > access? > > > > > > This is now reenabled. I had hoped to get postgres streaming > > > replication working, but unfortunately udd is running on a 32bit system, > > > while wagner and vasks are 64bit, so it didn't work out. localhost/5441 > > > will get you access to udd over a tunnel for now until we can think of > > > something better/different. > > > > Thanks. Some findings about this: Formerly a plain "service=udd" was > > working as convenience. Is it planned to put the pg_service.conf into > > place again? That way the backend connection could be transparently > > switched (though, my guess would be that the tunnel is there for the > > same purpose) > > I've restored the pg_service config now. Sorry, I forgot that that had > been set up in the first place, so it dropped off my todo list. > > > Also, it is working on wagner, but not on vasks. As I understood it > > this is intentional. On the other hand, the public_html sites are hosted > > on vasks, not on wagner, so services that would want to query UDD and > > offer results are out of scope in the new alioth setup. > > [ lot more good reasons snipped ] > > <alioth admin hat> > I have to say that I'm not very happy about general purpose hosting on > the 'alioth' servers. While I agree QA work is useful and should be > encouraged rather than discouraged, I don't know if alioth is the place > for development work of this sort. > </alioth admin hat> > > <dsa hat> > qa.d.o has a dedicated machine, udd has a dedicated machine, and I'm > sure it would be straight forward enough to set up a playpen on one > or the other of those machines for DDs who want to do QA tasks without > formally joining the QA team (just a gid debian writable subdirectory > of the web root where users could create their own spaces would probably > be sufficient?). This is just musing off the top of my head - I don't > speak for the QA team or lucas about access to these services - the > machines are open to all DDs, however, so I don't see any compelling > issues to be resolved off hand. > </dsa hat>
Well, there are a few reasons why this would be suboptimal: - both qa.debian.org and udd.debian.org websites are managed using SVN, so it's a bit inconvenient to create a playpen as a subdirectory. - I have the impression that most of the work that people were doing on alioth cannot be labelled as QA. For example, in the ruby team, we are running a daily cronjob that creates a web page about a transition. - qa and udd are not accessible to non-DDs. There are some teams that rely on a large number of non-DDs, and I don't like the idea of limiting the ability to update some script to DDs. (re-using the example of the ruby cronjob above, it was developed by Antonio Terceiro, who is still in NM). - qa and udd don't know about alioth teams. While I understand that it's not desirable to have the load induced by those third-party scripts affect the performance of alioth like it used to be the case, I think that it's very important for Debian to have a machine accessible to packaging team members (including non-DDs) where they can easily develop and run team-specific infrastructure. It would be a big regression if such infrastructure would have to be hosted outside Debian. - Lucas -- 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/20110614202317.ga28...@xanadu.blop.info
