On 8 August 2016 at 11:53, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Mon, Aug 8, 2016 at 10:23 AM, Miroslav Suchý
<msuchy(a)redhat.com> wrote:
> At Flock, sever people asked me why Mock is not on github or pagure as it
> would easy the contribution process.
> I am thinking the same for some time. But I was just lazy to initialize it.
> So here it comes now:
>
> Does anyone object if I move it? What is your preference? Github or Pagure?
>
> And BTW: I am preparing new release (with F25 configs), so if you have some
> patches lying somewhere, it is good time to send them my way right now.
I don't like either of those choices very much for the following reasons:
GitHub:
* Proprietary
* No integration with existing account services
Pagure:
* Slow and often unreliable
* Releases don't work as expected
* UX is not intuitive
These were part of the reasons people didn't like Gitlab which kind of
says to me... UX is always intuitive in the eye of someone and hard in
everyone elses eye. It was also slow and things didn't work the way
people thought they should.
I'd prefer GitLab (either hosted by Fedora or on
GitLab.com), as it is
open-source, has a good user experience, supports the contribution
model everyone wants, has a more flexible integrated CI (you can use
Fedora docker images to have a Fedora environment with GitLab CI) and
supports most existing account services for sign-on. GitLab doesn't
currently integrate with FAS, but I doubt it would take much for it to
do so. GitLab CE is FOSS, too.
I'm honestly surprised we don't have a GitLab instance in Fedora infra yet...
Mainly because when it was evaluated it was not in the state that
would work in our infrastructure very well.
1. It is ruby. We have not had good luck with ruby software and do not
have any 'experts' in supporting it. [This is important because when
bugs occur we end up dealing with outages which affect building
software but no one can fix.]
2. It is not packaged in Fedora (and no one was interested in
packaging it in Fedora).
Those aren't permanent blockers but they are pretty big ones that need
to be addressed.
--
Stephen J Smoogen.