---- On Fri, 24 Jun 2022 11:44:27 -0500 Kendall Nelson <kennelson11@gmail.com> wrote ---
On Thu, Jun 23, 2022 at 7:43 PM Ghanshyam Mann <gmann@ghanshyammann.com> wrote: ---- On Thu, 23 Jun 2022 15:02:57 -0500 Kendall Nelson <kennelson11@gmail.com> wrote ----
On Thu, Jun 23, 2022 at 12:55 PM Jeremy Stanley <fungi@yuggoth.org> wrote: On 2022-06-23 12:13:50 -0500 (-0500), Ghanshyam Mann wrote:
---- On Thu, 23 Jun 2022 10:30:24 -0500 Jeremy Stanley <fungi@yuggoth.org> wrote ----
On 2022-06-23 10:02:14 -0500 (-0500), Ghanshyam Mann wrote: [...]
Yes, both are separate things and I think we are mixing both or at least if we have such impression or governance is not so clear about it then we should fix it. I replied in another reply about governance point of view and IMO yes we should allow such new projects hosted on new tooling or so but they need to make sure all the help on CI/CD, release etc are taken care by them self or they help opendev team to support such things. If either of them cannot be done and they do not fulfill the PTI or any other new project requirement criteria then they cannot be in OpenStack. [...]
"Governance" (the new project requirements document) right now clearly states that new projects need to perform their code review and gating tests on the "OpenStack Infrastructure" (the former name for the OpenDev Collaboratory because that document hasn't been updated to reflect the new name). You'll at a minimum need a vote of the TC to remove those restrictions, so all this assumes that the rest of the TC agrees with you that doing code review in GitHub with a separate GitHub-connected CI system is allowable for new official OpenStack project teams and deliverables.
This is not "governance point of view" it's *your* point of view, so please be clear that the decision is one the TC as a whole will need to make.
I think there is some misunderstanding here. I have never said anywhere that this is "TC agreed view" off-course this is my opinion as a community member as well as TC member.
Any community member or TC members can provide their opinion but that should not be considered as "TC agreed plan" until that is explicitly mentioned in email or TC pass the resolution. We can have different views from TC members or chair but any of that should not be considered as "TC agreement" unless mentioned. I think this is how every email discussion is.
You referred to it above as the "governance point of view" so I just wanted to make certain you don't actually believe the governing documents are unclear on this particular point, and understand that OpenStack absolutely will need TC consensus on lifting a longstanding restriction in order to allow an official deliverable to be hosted outside the "OpenStack Infrastructure" (a.k.a. OpenDev Collaboratory).
As a TC member, I do not think that any project that is a part of OpenStack should be hosted outside OpenDev. To be a part of OpenStack, you have to be hosted in OpenDev. I think that splitting to use Github + OpenDev will create too much complexity for new contributors in addition to everything else already mentioned about CI and release management further up in this thread.
Well, I am not sure how valid the new contributors criteria is nowadays because we hardly get any new contributors in any of the OpenStack project. But here we are denying the interested contributors to contribute their project to OpenStack because of the tooling they want to use in developing their code. I am not sure if we will get other new contributors in gophercloud if it is hosted on opendev.
I feel like that is kind of a defeatist attitude- that we shouldn't keep new contributors to OpenStack in mind. There are new peoplecoming in every round of outreachy, every semester at NDSU, BU, Northwestern... I am in contact with 3 more universities since the Berlin summit looking to form similar relationships with us. That's not nothing? If the process of getting started becomes more complex, I think we will struggle even more to get new people involved and buildthem into the next generation of contributors to step up when the current folks have to/ want to move on. Many projects already have a very short bench and I can only see fracturing our development processes as making it harder to build up the number ofcontributors we have to support our teams and those that have been in leadership roles so long they are looking to step down soon.
No, it's not a defeatist attitude but instead a practical attitude and move forward to progress the things rather than stuck on currently-not-working stuff. Being practical based on facts and not being optimistic is not defeat. I think Artem also explained it what I meant by 'new contributor' in this context. But let me elaborate on my statement. There are two different sets of new contributors 1. short-term: outreach, intern or so 2. Long-term. I am talking about the 2nd one here as 1st one is anyways going after a short time and it is the same for them to learn Gerrit or GitHub. Long-term new contributors are someone we need to think that our process/tooling are ok for them to sustain as long term or it is too complex/split to work. For example: "Hey, my company is asking me to be a new long-term maintainer in OpenStack but I deny it because OpenStack uses more than one set of tooling to develop the code or run the tests". In this example, before saying more than one tooling will be difficult for new contributors we should answer two very practical questions: 1. How many of such new contributors do we have in OpenStack 2. If there is, do they need to learn two processes? I think they will be contributing to a single project following a single process/tool. If we get some super contributor to all projects then it is a different thing. And practical data is "we do not get new contributors helping us with help needed things", Below points can justify it: 1. no help on our help needed (upstream investment opportunity) list "because of fewer contributors". 2. Many projects get retired in every cycle "because of fewer contributors". 3. OpenStack Infra (OpenDev) is shrinking, many services are shutting down "because of fewer contributors". 4. OpenStack Community is not able to finish user-facing features like RBAC, OSC on time "because of fewer contributors". 5. Most of our existing contributors are overloaded and slowly burnout "because of fewer contributors". OpenDev maintainer overloaded is a good example. 6. OpenStack supporting teams like QA, infra, requirement, stable branch, and releases do not have enough maintainers that they require. I am saying what strategy or program will work to fix these but in the current situation, we have to accept that these are problems because we do not get new contributors. If we cannot fix them then we have to adjust ourself as per current situation even change the things which previously agreed or worked. I am starting another discussion here to fix this new contributor problem in this thread but I am saying that considering the new contributors criteria in this email thread context and not changing the things is not relevant, -gmann
-gmann
I have this in my list to give a clear picture from TC as an agreed plan:
Step1: Continue the discussion in ML (here) Step2: After having a good amount of feedback here and we still not resolved the things, I will add this topic to TC meeting and get the TC consensus. Step3: Propose Governance resolution or documentation update Step4: Update the same in ML as "TC agreed plan".
Thanks, this looks like a reasonable way forward.
Documents should definitely get updated! +2! -- Jeremy Stanley
-Kendall Nelson
-Kendall Nelson