<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 9, 2019, 4:21 PM Friedrich W. H. Kossebau <<a href="mailto:kossebau@kde.org">kossebau@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am Samstag, 9. November 2019, 21:35:47 CET schrieb Ben Cooksley:<br>
> On Sun, Nov 10, 2019 at 9:14 AM Friedrich W. H. Kossebau<br>
> <br>
> <<a href="mailto:kossebau@kde.org" target="_blank" rel="noreferrer">kossebau@kde.org</a>> wrote:<br>
> > Am Samstag, 9. November 2019, 19:16:20 CET schrieb Ben Cooksley:<br>
> > > On Sun, Nov 10, 2019 at 6:04 AM Ingo Klöcker <<a href="mailto:kloecker@kde.org" target="_blank" rel="noreferrer">kloecker@kde.org</a>> wrote:<br>
> > > > On Samstag, 9. November 2019 01:20:01 CET Ben Cooksley wrote:<br>
> > > > > On top of this, i'd also like to remove commit access to it for<br>
> > > > > everyone but translators and those who need to work on the small<br>
> > > > > number of websites remaining on Subversion and only provision this<br>
> > > > > for<br>
> > > > > people on an as-needed basis.<br>
> > > > > <br>
> > > > > In the next year or so i'd expect the remaining websites to complete<br>
> > > > > their migrations to Git, after which only translators would receive<br>
> > > > > access.<br>
> > > > <br>
> > > > Restricting access to the translations repository is against the<br>
> > > > letter of<br>
> > > > our manifesto which states<br>
> > > > "All source materials are hosted on infrastructure available to and<br>
> > > > writable by all KDE contributor accounts"<br>
> > > > <a href="https://manifesto.kde.org/commitments.html" rel="noreferrer noreferrer" target="_blank">https://manifesto.kde.org/commitments.html</a><br>
> > > > <br>
> > > > AFAIK, "all source materials" includes translations.<br>
> > > > <br>
> > > > There are a few reasonable exceptions for this requirement, e.g. for<br>
> > > > the<br>
> > > > sources of our websites, but I don't see a good reason for restricting<br>
> > > > access to the translations.<br>
> > > > <br>
> > > > I think restricting access to the translations will create a precedent<br>
> > > > for<br>
> > > > restricting access to other source materials and undermines the values<br>
> > > > stated in our manifesto. Therefore, I don't think we should go down<br>
> > > > this<br>
> > > > route.<br>
> > > <br>
> > > The access isn't being *restricted* at all.<br>
> > > It is just something you have to request be enabled separately, and it<br>
> > > won't be withheld from anyone with a developer account should they<br>
> > > feel they need it.<br>
> > <br>
> > This is a model we also see with rights to kick off build jobs on<br>
> > <a href="http://build.kde.org" rel="noreferrer noreferrer" target="_blank">build.kde.org</a>, and I think it does not work out:<br>
> > having to beg for access and having to wait for access being granted is an<br>
> > obstacle.<br>
> > Even more when this is nowhere documented, but a secret traded only in<br>
> > people's minds.<br>
> <br>
> As a general principle, filing a Sysadmin ticket has always been the<br>
> way to get access to systems (developer accounts being the only<br>
> exception), and the same applies to the CI system. Hence why there is<br>
> no explicit documentation around this.<br>
<br>
It stays an obstacle for everyone on first contact though. And makes one feel <br>
in begging position, when one should not, by ideas of the manifesto.<br>
And often enough one needs access _now_, instead of having to hope some <br>
sysadmin is around in the near time.<br>
<br>
> > So, by default there are de-facto restrictions experienced, and they get<br>
> > in<br>
> > the way of developer work-flows.<br>
> <br>
> It's a bit unusual that a lack of access to the CI system would impact<br>
> someone's workflow, as the CI system is supposed to automatically<br>
> trigger itself.<br>
> Do you have a specific scenario in mind here?<br>
<br>
The usual scenarios where one needs to manually trigger build jobs:<br>
a) build metadata changed (e.g. dependencies)<br>
b) builds failed for bko-internal issues<br>
c) branches changed, need manual first-run trigger<br>
<br>
All things normal developers want or need to do once in a while, if they care <br>
for their project on KDE CI.<br>
<br>
> > My 2 cent on this matter when it comes to conditions decided about.<br>
> > <br>
> > Otherwise, thanks for all the admin work you are doing here once again :)<br>
> > <br>
> > Cheers<br>
> > Friedrich, who only an hour ago had to help someone kicking off builds<br>
> > jobs on CI, as he once got the access granted after poking a few times<br>
> > informally...<br>
> Fortunately switching to Gitlab CI will resolve that specific scenario<br>
> (needing the DSL Job run when a release is being made) as the DSL Job<br>
> will be rendered unnecessary.<br>
<br>
"When a release is being made" should mean, when a new stabe branch has been <br>
created, I guess? That would be an improvement. Still leaves scenarios a) & </blockquote></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
b).<br>
<br>
Cheers<br>
Friedrich<br><br>
<br>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.</blockquote></div></div></div>