On Mon, 6 Apr 2020 at 17:52, Leigh Griffin <lgriffin(a)redhat.com> wrote:
On Mon, Apr 6, 2020 at 4:25 PM Adam Williamson <adamwill(a)fedoraproject.org> wrote:
>
> On Mon, 2020-04-06 at 15:35 +0100, Leigh Griffin wrote:
> >
> > > Does it mean you didn't consider dist-git<->zuul integration vs.
Gitlab
> > > CI? I.e. technical differences and advantages of each? If you did, can
you,
> > > please, publish it? It would be valuable info for the community and
> > > something we can comment on.
> > >
> >
> > Gitlab CI was not part of our evaluation, we are aware it's a service that
> > is offered but did not evaluate it as it wasn't within the scope of our
> > exercise.
>
> So, how does that track with this quote from the decision blog post?
>
> "Some top level requirements which helped us arrive at this decision
> [to choose Gitlab]:
>
> There is a need for CentOS Stream to integrate with a kernel workflow
> that is an automated bot driven merging solution (merge trains). This
> allows for richer CI capabilities and minimises the need for human
> interaction"
>
> If you did not evaluate Gitlab CI (and presumably CI capabilities of
> the three systems more widely), how did the need for a CI feature -
> that is what "merge trains" are - act as a "top level
requirement"
> which "helped us arrive at this decision"?
I'm talking specifically about CI as a capability, in that specific integrations at a
CI level for hooks and other nice stuff which has several known issues in Pagure at an API
level, we evaluated that high level requirement. Some stakeholders do not want to use the
built in Gitlab CI as we have CentOS CI used extensively and some have homebrewed systems
that they use. Hence why we did not go deep on CI at a very functional level outside of
known limitations and desires that came up as direct requirements.
Merge trains and that capability is plugin / CI based and was explicit in it's scope
(it was called out as a need to have merge train functionality) Vs CI in general as it was
named as a need. We had discussed that Zuul was a possibility around Pagure as part of
that.
Discussed with whom, do you have logs? You didn't provide any material
from which the conclusions could be reproducibly drawn, you just came
and told us: "Hey, we decided this and this, you don't have any other
choice than to comply". It doesn't work like that or at least it
shouldn't, in my opinion.
It doesn't seem that you have considered CI future for Fedora _at
all_, i.e. work needed for pagure-based solution vs. work needed for
gitlab-based solution. Sorry but if you don't have a clear and
presentable vision of the different setups and how they compare to
each other with respect to initial setup, maintenance cost, and
feature set relevant for packager workflows, you shouldn't be making
decisions like those. Your "let's go to Gitlab" is shooting in the
dark at best.
clime
>
>
>>
>> --
>> Adam Williamson
>> Fedora QA Community Monkey
>> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
>>
http://www.happyassassin.net
>> _______________________________________________
>> devel mailing list -- devel(a)lists.fedoraproject.org
>> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> --
>
> Leigh Griffin
>
> Engineering Manager
>
> Red Hat Waterford
>
> Communications House
>
> Cork Road, Waterford City
>
> lgriffin(a)redhat.com
> M: +353877545162 IM: lgriffin
>
> @redhatjobs redhatjobs @redhatjobs
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org