[all][foundation][ecosystem] External projects under the foundation hat

Clark Boylan cboylan at sapwetik.org
Wed Jun 22 15:33:10 UTC 2022

On Wed, Jun 22, 2022, at 7:38 AM, Artem Goncharov wrote:
>> On 22. Jun 2022, at 15:12, Jeremy Stanley <fungi at yuggoth.org> wrote:

Snipped to address a particular item inline below.

>> I think supporting multiple commit workflows and code review tools
>> within the OpenDev Collaboratory would be even more confusing and
>> add further conceptual barrier (what do you mean to commit to
>> OpenStackSDK I need to use a different set of tools and review
>> process than gophercloud, even though they're both in OpenDev?).
>> But from a technical feasibility standpoint, it's also more than
>> just the lack of a Gitea driver for Zuul: our current Gitea server
>> farm is read-only for technical reasons including lack of support in
>> Gitea for a shared writeable storage backend, the fact that we would
>> need to set up separate authentication/account management (we still
>> need help from more people to make progress on our Keycloak SSO
>> deployment), not to mention it would effectively double the security
>> risk profile.
> Thanks for adding more technical infos here, it was just an idea. 

To clarify we believe Gitea does support all of the functionality necessary to run Gitea in a true cluster fashion. The last remaining piece that was missing was the shared code search index. This was addressed through the addition of elasticsearch (we would use opensearch) support for code indexing.

At this point the main technical hurdle is that someone (or some group of people) need to completely re-architect how we run and deploy Gitea. This includes testing that the above solution actually fixes the problem, building new deployment tooling, creating a migration plan, and so on.

But even then I agree with Jeremy that supporting multiple tools is a massive burden. It is twice the number of tools I need to help people debug ssh for, twice the number of tools we need documentation for since the workflows vary so completely, twice the number of tools to curate content on should that become necessary, twice the number of tools to fix accounts on, and the list goes on. It will only lead to confusion for users and burn out for the small number of people remaining that actually support these tools anymore.

> On the other side you mentioned Gitea is lacking support for required 
> piece and that is exactly the case where you eventually can’t chase 
> open source anymore. We can try, but I doubt we are able to re-implement 
> so many things in the purely open source style. I guess not even any 
> car now runs with a purely open source firmware. Would you not use it 
> because of that?

I would actually say this is an argument in favor of open source not against it. We identified a deficiency in the tool, described a use case for why change would be beneficial, worked with upstream, and they addressed it. Unfortunately, in the same period of time we lost help for running the Gitea service and haven't been able to take advantage of the new features that were added.

It often feels that the problem isn't so much that open source is flawed, and instead that those few of us willing to make it work regularly have to defend why it is worth improving and maintained instead of giving up.

More information about the openstack-discuss mailing list