El dimecres, 3 de juliol de 2019, a les 8:01:12 CEST, Bhushan Shah va escriure:
> 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.

drkonqi is not the only reason, the main reason for me is "i don't want to have 
to think about two places when i think about bugs"

> 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.

If the new is much better than the old, let's just remove the old.

As said, having two things that do the same is just confusing for everyone.


> Thanks

Reply via email to