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

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.


Bhushan Shah
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D

Attachment: signature.asc
Description: PGP signature

Reply via email to