Re: 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
> > > 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
- 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?