Sysadmin Load Reduction: Subversion Infrastructure

[Michael Reeves]

On Sat, Nov 9, 2019, 4:21 PM 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.
> 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).
>
> Cheers
> Friedrich
>
>
> As far as b) goes I had just this scenario with kdiff3 on the new gitlab
> ci. I was able to manually restart the job without sysadmin intervention.
> It's even possible to have gitlab automatically retry for such errors.
> That's what I have done for kdiff3.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20191109/136fc974/attachment.htm>