On 22. Jun 2022, at 15:12, Jeremy Stanley <fungi@yuggoth.org> wrote:

On 2022-06-22 10:12:16 +0200 (+0200), Artem Goncharov wrote:
[...]

I went multiple times through explaining “change” model to both
experienced and unexperienced people and is usually painful.

And you also have less trouble explaining the convoluted GitHub
"pull request" workflow to someone who has never heard of Git or
GitHub?

In the Outreachy we also have same practice each time and this is
for people just harder to understand (I see project on GitHub, why
can’t I open PR here like I would do for every other project on
GitHub).

[...]

OpenStack does its best in the org and repo descriptions on GitHub
to highlight that they're convenience mirrors, and to point to the
community's accepted workflows. Does that get overlooked? Is there
something better that could be done to make it clear?

[...]

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.

I agree we need to support making landscape flexible. But I am not
100% sure we should currently (due to general lack of
contributions) simply refuse those willing to contribute into
OpenStack . Terraform is a very prominent example here as well -
you must be on GitHub to publish your artefacts. Don’t we want to
have official TF provider following our best practices (therefore
this is not an infrastructure only question)?

[...]

Is a source code mirror on GitHub not sufficiently "on GitHub" from
Terraform's perspective?

we may explore publishing to GitHub mirror releases while still
doing development on gitea. That requires having GH app token
though (that is actually where those Vault plugins are being
useful - you just fetch the token from vault and it expires
afterwards).

[...]

OpenStack's GitHub mirroring relies on a Zuul job with account
credentials for the openstack org encoded as a secret in the job
definition, and other projects do similarly for mirrors to their
respective orgs as well. Performing other API interactions in jobs
is similarly possible, so telling GitHub to make a "release" of
something there would probably be a trivial addition.

I would rather disagree with such statement: just because you host
your code on a proprietary hosting (but make it freely available)
does not mean your are violating this mission. I also believe we
should be using open source tools (and we do that), but that
doesn’t mean everyone else is breaking bad [not meant to be
abusive statement].

You're spending your valuable time producing open source software,
so you must see some value in your choice to make it open source and
would rather users picked it over proprietary alternatives. I
personally would feel rather hypocritical were I to claim that open
source development is a good thing when it's the software I'm
creating, but that I don't find the open source alternatives to
proprietary code hosting and development tools similarly valuable
and would rather choose what's convenient or popular instead. How
can I expect the communities producing those tools to make traction
against proprietary platforms if I choose to be part of that problem

rather than part of the solution? I feel similarly disheartened when
I attend an open source software conference and see someone give a
presentation extolling the virtues of these practices, while clearly
running their slide deck from MacOS or Windows.

Generally we have again here the same “infra” concerns in the
discussion (which are already known historically, but anyway
thanks for making them clear again), but what about other
opinions? Are there any other thoughts or am I the only one
interested to get this sorted out?

If I can try to restate your request, it seems like you want to
develop software using some different tool choices than those
available in the OpenDev Collaboratory. All the software we run in
OpenDev (and all the software we use to develop and maintain the
services and deployment in OpenDev) is 100% open source, along with
its configuration. If you want to run a different combination of
those services for your community while reusing some of OpenDev's
solutions, you absolutely can do that and a number of people do so
already.

Just to repeat, my current case is really about a very strong
desire and, I would say even need, to have gophercloud be very
close to OpenStackSDK. Can we at least think about placing them
under OpenStack GitHub org without Zuul access to have a better
affiliation with OpenStack (gopher folks, hope you do not mind of
such step. Or maybe we try to demonstrate here how to make this
manageable with Zuul - reach me out if there is interest)?

[...]

I'm probably still misunderstanding what you mean by "very close to"
in this statement. If the most important aspect of this is that
gophercloud appears in the openstack org on GitHub, but you don't
wish to actually use the development methodology and code review
workflow of the OpenStack community, then that doesn't seem close at
all. But maybe you mean "close" from a marketing perspective?
Mirrors to GitHub are not something OpenDev sysadmins really even
get involved with, it's just automation individual projects implement
and maintain for themselves, so it's the OpenStack TC's choice as to
what projects they'll allow to appear in their GitHub org, and
really nothing to do with the OpenDev Collaboratory itself.

And one thing I still don't feel like you've covered is your earlier
assertion that gophercloud project leadership was told the OpenInfra
Foundation refused to legally represent them unless they hosted
their development in the OpenDev Collaboratory. As I mentioned in my
earlier reply, there are already OpenInfra projects which do all
their software development in GitHub and run their own CI systems
completely separate from OpenDev, so I really doubt you've been
given an accurate account of what was discussed between foundation
leadership and gophercloud folks. It would probably be good to seek
further clarification there.