On Sat, Nov 9, 2019, 4:21 PM Friedrich W. H. Kossebau <[email protected]> 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 > > > > <[email protected]> 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 <[email protected]> > 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.
