Sysadmin Load Reduction: Subversion Infrastructure

[Ben Cooksley]

On Sun, Nov 10, 2019 at 9:14 AM Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
>
> Am Samstag, 9. November 2019, 19:16:20 CET schrieb Ben Cooksley:
> > On Sun, Nov 10, 2019 at 6:04 AM Ingo Klöcker <kloecker at kde.org> wrote:
> > > On Samstag, 9. November 2019 01:20:01 CET Ben Cooksley wrote:
> > > > On top of this, i'd also like to remove commit access to it for
> > > > everyone but translators and those who need to work on the small
> > > > number of websites remaining on Subversion and only provision this for
> > > > people on an as-needed basis.
> > > >
> > > > In the next year or so i'd expect the remaining websites to complete
> > > > their migrations to Git, after which only translators would receive
> > > > access.
> > >
> > > Restricting access to the translations repository is against the letter of
> > > our manifesto which states
> > > "All source materials are hosted on infrastructure available to and
> > > writable by all KDE contributor accounts"
> > > https://manifesto.kde.org/commitments.html
> > >
> > > AFAIK, "all source materials" includes translations.
> > >
> > > There are a few reasonable exceptions for this requirement, e.g. for the
> > > sources of our websites, but I don't see a good reason for restricting
> > > access to the translations.
> > >
> > > I think restricting access to the translations will create a precedent for
> > > restricting access to other source materials and undermines the values
> > > stated in our manifesto. Therefore, I don't think we should go down this
> > > route.
> > The access isn't being *restricted* at all.
> > It is just something you have to request be enabled separately, and it
> > won't be withheld from anyone with a developer account should they
> > feel they need it.
>
> This is a model we also see with rights to kick off build jobs on
> build.kde.org, and I think it does not work out:
> having to beg for access and having to wait for access being granted is an
> obstacle.
> Even more when this is nowhere documented, but a secret traded only in
> people's minds.

As a general principle, filing a Sysadmin ticket has always been the
way to get access to systems (developer accounts being the only
exception), and the same applies to the CI system. Hence why there is
no explicit documentation around this.

For the most part, we've not seen many people request those rights -
and all the requests we have received have been granted.

> So, by default there are de-facto restrictions experienced, and they get in
> the way of developer work-flows.
>

It's a bit unusual that a lack of access to the CI system would impact
someone's workflow, as the CI system is supposed to automatically
trigger itself.
Do you have a specific scenario in mind here?

> My 2 cent on this matter when it comes to conditions decided about.
>
> Otherwise, thanks for all the admin work you are doing here once again :)
>
> Cheers
> Friedrich, who only an hour ago had to help someone kicking off builds jobs on
> CI, as he once got the access granted after poking a few times informally...
>
>

Fortunately switching to Gitlab CI will resolve that specific scenario
(needing the DSL Job run when a release is being made) as the DSL Job
will be rendered unnecessary.

Cheers,
Ben