FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 06-11-2011, 02:06 PM
Stephen Gran
 
Default UDD access from Alioth(s children) (Was: Alioth status update, take 3)

This one time, at band camp, Andreas Tille said:
> Hi again,
>
> 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.

Cheers,
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
 
Old 06-14-2011, 03:05 PM
Lucas Nussbaum
 
Default UDD access from Alioth(s children) (Was: Alioth status update, take 3)

On 14/06/11 at 16:49 +0200, Gerfried Fuchs wrote:
> <tl;dr>Is there some host for php/cgi and UDD access?

Hi,

Maybe we need a general-purpose machine accessible by all alioth users,
without any performance-critical services, to execute all the random
development-supporting scripts that generate web status pages such as
PET, UDD-backed scripts, etc.

So far, I read the alioth transition as:
- old alioth: slow, useful
- new alioth: much faster, less useful

- Lucas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110614150500.GA1808@xanadu.blop.info">http://lists.debian.org/20110614150500.GA1808@xanadu.blop.info
 
Old 06-14-2011, 08:03 PM
Stephen Gran
 
Default UDD access from Alioth(s children) (Was: Alioth status update, take 3)

This one time, at band camp, Gerfried Fuchs said:
> Hi!
>
> * 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)

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>

Cheers,
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
 
Old 06-14-2011, 08:03 PM
Stephen Gran
 
Default UDD access from Alioth(s children) (Was: Alioth status update, take 3)

This one time, at band camp, Gerfried Fuchs said:
> Hi!
>
> * 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)

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>

Cheers,
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
 
Old 06-14-2011, 08:23 PM
Lucas Nussbaum
 
Default UDD access from Alioth(s children) (Was: Alioth status update, take 3)

On 14/06/11 at 21:03 +0100, Stephen Gran wrote:
> This one time, at band camp, Gerfried Fuchs said:
> > Hi!
> >
> > * 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)
>
> 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110614202317.GA28847@xanadu.blop.info">http://lists.debian.org/20110614202317.GA28847@xanadu.blop.info
 
Old 06-14-2011, 08:23 PM
Lucas Nussbaum
 
Default UDD access from Alioth(s children) (Was: Alioth status update, take 3)

On 14/06/11 at 21:03 +0100, Stephen Gran wrote:
> This one time, at band camp, Gerfried Fuchs said:
> > Hi!
> >
> > * 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)
>
> 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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110614202317.GA28847@xanadu.blop.info">http://lists.debian.org/20110614202317.GA28847@xanadu.blop.info
 
Old 06-15-2011, 07:36 AM
Stephen Gran
 
Default UDD access from Alioth(s children) (Was: Alioth status update, take 3)

This one time, at band camp, Lucas Nussbaum said:
> 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.

That's a minor technical issue that can be resolved with the equivalent of
svn ignore on a subdirectory. I can't believe that it's a serious bocker.

> - 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).

I think maybe we're talking at cross purposes here. wagner.d.o has
access to UDD, and runs the project web sites (eg, adduser.alioth.d.o).
If teams need to make use of UDD to track status for their projects,
that is a perfectly reasonable and fine use of the alioth service.

I am talking about the larger, project-wide work Rhonda and others do that
doesn't fit under the umbrella of work done on a particular code base.
This work, while good and useful work, is not really what alioth is
intended for. This is what I'm talking about shifting.

As a secondary issue, I think it might be useful to let DDs 'scratch
their itch' when it comes to QA work in a light weight way. However,
I'm not in the QA team, so I can't make decisions about what sort of
access the QA team wants to give to other project members. In general,
I am in favor of open access to resources and self-service, but you may
not be.

Also, I don't think it's a good idea in general for the project to
rely on anything in someone's $HOME, as we've seen that go wrong far
too often. I would like to encourage people to move services that are
useful to an appropriate place.

Cheers,
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
 
Old 06-15-2011, 08:16 AM
Lucas Nussbaum
 
Default UDD access from Alioth(s children) (Was: Alioth status update, take 3)

On 15/06/11 at 08:36 +0100, Stephen Gran wrote:
> As a secondary issue, I think it might be useful to let DDs 'scratch
> their itch' when it comes to QA work in a light weight way. However,
> I'm not in the QA team, so I can't make decisions about what sort of
> access the QA team wants to give to other project members. In general,
> I am in favor of open access to resources and self-service, but you may
> not be.

The QA team is very open to welcoming new members and their
contributions. However, not everything can be labelled as QA work, and
not everybody wants to do work inside a team, so I'm relunctant to use
the QA infrastructure as a placeholder for every script people want to
run on alioth.

> Also, I don't think it's a good idea in general for the project to
> rely on anything in someone's $HOME, as we've seen that go wrong far
> too often. I would like to encourage people to move services that are
> useful to an appropriate place.

Before you can prove that a service is useful, you need to develop it.
For that, it's convenient to have a place which is similar to the final
destination of the service, where you can easily hack. Also, it's often
not desirable to hack on the production version of a service.

A good solution could be to serve public_html from wagner instead of
vasks. I don't really see the point in serving it from vasks.

Alternatively, we could use collab-maint's htdocs, but there's an ACL
missing on wagner:/home/groups/collab-maint/htdocs.

- Lucas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110615081654.GA10941@xanadu.blop.info">http://lists.debian.org/20110615081654.GA10941@xanadu.blop.info
 
Old 06-15-2011, 07:00 PM
Stephen Gran
 
Default UDD access from Alioth(s children) (Was: Alioth status update, take 3)

This one time, at band camp, Lucas Nussbaum said:
> On 15/06/11 at 08:36 +0100, Stephen Gran wrote:
> > As a secondary issue, I think it might be useful to let DDs 'scratch
> > their itch' when it comes to QA work in a light weight way.
> > However, I'm not in the QA team, so I can't make decisions about
> > what sort of access the QA team wants to give to other project
> > members. In general, I am in favor of open access to resources and
> > self-service, but you may not be.
>
> The QA team is very open to welcoming new members and their
> contributions. However, not everything can be labelled as QA work, and
> not everybody wants to do work inside a team, so I'm relunctant to use
> the QA infrastructure as a placeholder for every script people want to
> run on alioth.

I can't decide if you're deliberately choosing to not understand me, or
if we've just reached that point of a thread where people repeat
themselves, so I'm going to stop after this mail.

> > Also, I don't think it's a good idea in general for the project to
> > rely on anything in someone's $HOME, as we've seen that go wrong far
> > too often. I would like to encourage people to move services that
> > are useful to an appropriate place.
>
> Before you can prove that a service is useful, you need to develop it.
> For that, it's convenient to have a place which is similar to the
> final destination of the service, where you can easily hack. Also,
> it's often not desirable to hack on the production version of a
> service.

You seem to be agreeing with me about the usefulness of having a scratch
area on quantz or samosa, and then:

> A good solution could be to serve public_html from wagner instead of
> vasks.

You reach the opposite conclusion.

I'll leave it there.

Cheers,
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
 
Old 06-15-2011, 07:13 PM
Lucas Nussbaum
 
Default UDD access from Alioth(s children) (Was: Alioth status update, take 3)

On 15/06/11 at 20:00 +0100, Stephen Gran wrote:
> This one time, at band camp, Lucas Nussbaum said:
> > On 15/06/11 at 08:36 +0100, Stephen Gran wrote:
> > > As a secondary issue, I think it might be useful to let DDs 'scratch
> > > their itch' when it comes to QA work in a light weight way.
> > > However, I'm not in the QA team, so I can't make decisions about
> > > what sort of access the QA team wants to give to other project
> > > members. In general, I am in favor of open access to resources and
> > > self-service, but you may not be.
> >
> > The QA team is very open to welcoming new members and their
> > contributions. However, not everything can be labelled as QA work, and
> > not everybody wants to do work inside a team, so I'm relunctant to use
> > the QA infrastructure as a placeholder for every script people want to
> > run on alioth.
>
> I can't decide if you're deliberately choosing to not understand me, or
> if we've just reached that point of a thread where people repeat
> themselves, so I'm going to stop after this mail.

Usually, when that happens, a constructive way to move forward is to
rephrase opinions to make sure that they were correctly understood.
I understand your position as "if it's QA, then it should be done inside
the QA infrastructure (qa.debian.org, svn, etc.), not in a scratch area
on wagner."

> > > Also, I don't think it's a good idea in general for the project to
> > > rely on anything in someone's $HOME, as we've seen that go wrong far
> > > too often. I would like to encourage people to move services that
> > > are useful to an appropriate place.
> >
> > Before you can prove that a service is useful, you need to develop it.
> > For that, it's convenient to have a place which is similar to the
> > final destination of the service, where you can easily hack. Also,
> > it's often not desirable to hack on the production version of a
> > service.
>
> You seem to be agreeing with me about the usefulness of having a scratch
> area on quantz or samosa, and then:

Scratch areas on quantz or samosa are useful, but:
- I don't think that it should be my role or the role of the QA team to
manage them, so they shouldn't live under /org/qa.debian.org or
/org/udd.debian.org.
- quantz and samosa are not accessible to non-DDs.

> > A good solution could be to serve public_html from wagner instead of
> > vasks.
>
> You reach the opposite conclusion.

How is that an opposite conclusion?

- Lucas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110615191316.GA27911@xanadu.blop.info">http://lists.debian.org/20110615191316.GA27911@xanadu.blop.info
 

Thread Tools




All times are GMT. The time now is 10:13 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org