On Mon, 6 Apr 2020, 21:26 clime, <clime@xxxxxxxxxxxxxxxxx> wrote:
On Mon, 6 Apr 2020 at 17:52, Leigh Griffin <lgriffin@xxxxxxxxxx> wrote:
>
>
>
> On Mon, Apr 6, 2020 at 4:25 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> 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.
Let me add here: we had conversation on CI with CPE both as Fedora CI SIG and as RHEL CI team.
We do want to keep existing CI infrastructure based on message exchange with distributed CI systems. As Gitlab has API and messages in a certain form, I don't expect huge problems here.
And we mentioned Zuul in that conversation. We discussed the possibility for Zuul to work with Gitlab at Devconf in January. And my understanding alignes with what Fabien said in this thread, that Zuul _can_ work with Gitlab. Though it might require some adjustments.
Personally, I believe that Zuul is superior to any other CI system when it comes to managing pull-requests workflow, and I would like to see its usage increased in Fedora and beyond. But I think changing the Git Forge to Gitlab doesn't on its own create a problem for this view.
What I would consider a problem: if we take Gitlab as GitForge, but then users start to request more "nice features", more "easy integrations" and more Gitlab-specific workflows... The git forge itself is not as harmful, as the scope creep in can bring.
But this is not something the CPE team should manage alone, it is us as users who need to be disciplined in the usage of this tool and our requests to it.
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@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>
>
>
> --
>
> Leigh Griffin
>
> Engineering Manager
>
> Red Hat Waterford
>
> Communications House
>
> Cork Road, Waterford City
>
> lgriffin@xxxxxxxxxx
> M: +353877545162 IM: lgriffin
>
> @redhatjobs redhatjobs @redhatjobs
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
