On Mon, 6 Apr 2020 at 17:52, Leigh Griffin <lgrif...@redhat.com> wrote: > > > > On Mon, Apr 6, 2020 at 4:25 PM Adam Williamson <adamw...@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@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@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 > > lgrif...@redhat.com > M: +353877545162 IM: lgriffin > > @redhatjobs redhatjobs @redhatjobs > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
