Sysadmin Load Reduction: Subversion Infrastructure

[Ben Cooksley]

On Sun, Nov 10, 2019 at 10:21 AM Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
>
> Am Samstag, 9. November 2019, 21:35:47 CET schrieb 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.
>
> It stays an obstacle for everyone on first contact though. And makes one feel
> in begging position, when one should not, by ideas of the manifesto.

As noted by Michael, this issue will likely be resolved as part of the
transition to Gitlab CI.

While it was never our intention to not provide developers with the
ability to start jobs should they wish to, it has unfortunately ended
up being something we can't provide on a group basis with the current
Jenkins setup using Phabricator authentication (we did provide that in
the past). Hence the current model of that access being provided on
request.

> And often enough one needs access _now_, instead of having to hope some
> sysadmin is around in the near time.
>
> > > 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?
>
> The usual scenarios where one needs to manually trigger build jobs:
> a) build metadata changed (e.g. dependencies)
> b) builds failed for bko-internal issues
> c) branches changed, need manual first-run trigger
>
> All things normal developers want or need to do once in a while, if they care
> for their project on KDE CI.
>
> > > 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.
>
> "When a release is being made" should mean, when a new stabe branch has been
> created, I guess? That would be an improvement. Still leaves scenarios a) &
> b).

That is correct.

>
> Cheers
> Friedrich
>

Regards,
Ben