[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: UDD access from Alioth(s children) (Was: Alioth status update, take 3)


* Stephen Gran <sgran@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)

 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.

 I wonder if this is bothering just myself and whether I rather should
provide myself with some scripts that I call via ssh to vasks and have
the output locally (and offer access to the script to other users and
document it in my alioth page) or whether this is something that can be
reconsidered to get working again and that are others bitten by, too.

 From my understanding, deploying stuff on UDD is to be done after a
test period or at least after the involved people consider it useful for
ther broader audience, which the current approach has cut off now. For
instance, I still had used my stable-RC.php page instead of lucas'
UDD/bugs.cgi script because of some finer differences that might be
considered personal preferences but which did suit my workflow better
(and I have received input for that from others, too).

 My unarchived-bugs.php page is nowhere found yet on UDD or QA site and
does also offer digging up targets of packages for looking at bugreports
for inconsistencies that happened over time, for easier bug triaging.

 Also, I was asked today whether it is possible to query the UDD for
bugreports against unknown packages, and I would have liked to offer an
interface for that for people to look at so they can be more
conveniently digged up, only to find out that this possibility is cut
off now, at least in the way it was possible before and to my
understanding the encouraged way to go, the main background behind
having access to UDD from alioth in the first place.

 Generating those files statically and copy them over through a specific
ssh key chained command when the pages are not that regularly looked at
would unneededly add load to UDD that I really would like to avoid. For
the same purpose I even added a caching mechanism in the script that
did hook in on constant reloads of the page. I intentionally did do
these things in a defensive way.

 Is there some place that is willing to host such service queries that
probably only a handful people would be interested to look at (because
QA work is boring but needs to get done anyway) that has both the
possibility to do on-demand website generation and also has UDD read
access? I'm not opposed to move the pages, I just would like to know
_where_ to, and it would had been rather convenient to have been made
aware of disabling that possibility beforehand, but I can understand
that this usage might not be that widely known, even though I mentioned
it in serveral different places from time to time ...

<tl;dr>Is there some host for php/cgi and UDD access?

Fühlst du dich mutlos, fass endlich Mut, los      |
Fühlst du dich hilflos, geh raus und hilf, los    | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los    |

Reply to: