On Tue, Jul 02, 2019 at 11:09:41PM +0200, Albert Astals Cid wrote: > That makes no sense, we incubated projects before we were on gitlab, saying > "oh no, if people can't use gitlab issues the incubation will collapse" is a > bit alarmist IMGO
Not my point at all, I am not saying Gitlab issues would be cause which makes the incubation fail. I am saying that if we continue with such twisted policy which denies access to service A already present because service B is used by rest of community is what will make incubation fail. To expand, What I am saying is, - KDE Incubates a project - We have a two differet things for some thing, let's take example of build.kde.org and Gitlab CI. - We introduce a rule that people can't use Gitlab CI despite being there and force them to use build.kde.org That kind of rules are not getting us anywhere. If it was case of someone using Travis CI instead of build.kde.org, we can ask them to not use it or enforce it. But if both services are hosted on KDE infrastructure, requires no further maintainence or other KDE contributors are able to access the service, just because one piece of software is broken or requires change (drkonqi) denying projects use of Gitlab Issues is not a good idea. Projects come to KDE because they find our community attractive, in hope that they get more contributors, but if we want to stick with some old infrastructure, and actively deny them usage of something new, then they better be on infrastructre outside of KDE. Thanks -- Bhushan Shah http://blog.bshah.in IRC Nick : bshah on Freenode GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
signature.asc
Description: PGP signature
