[ARCHIVAL] OpenEBS #1051
Comments
|
Hi @RichiH. Reached out in the community slack channel. The feedback I got it is the project is actively being used for the engines that have already reached maturity - so the number of commits to those are less. With regards to Mayastor engine - there is active development and adoption. |
|
As I noted in the Kubernetes Slack #openebs channel, I think one of the visible concerns for the project is that there are a batch of Github issues at https://github.com/openebs/openebs/issues that have not been acknowledged in the last 45 days, and another batch (under "closed") that were closed automatically by a bot without being acked in 90 days. Having techinical issues and bug reports and documentation errors be reported and not acked and be automatically closed is not a good look for any project. |
|
Cross posting here for reference: #905 (comment) The active OpenEBS engine issues are being worked under: https://github.com/openebs/mayastor/issues |
|
Digging a bit more with the existing maintainers - there is growing adoption of Mayastor. If the maintainers have to keep the project active - what is the information that needs to be presented? Would preparing an annual review be the right way to approach this at this point? |
|
Just FYI I see activity on the project. |
|
Thanks everyone! To be clear, the end result of the discussion phase does not automatically need to be a vote; that's why we have the discussion phase. Cross-references of relevant data:
|
|
A the global Prod Mgr of OpenEBS, here is some recent major news on adoption. The project is very much alive and extremely well used by the K8s community. We had a major validation of the project in the last few days. Microsoft Azure Cloud has recognized OpenEBS (Mayastor Data-Engine) as a core enabling technology for their new "Azure Container Storage Cloud Services" and has built their entire new Container storage service stack & offering ontop of the OpenEBS Project (Maystor NVMe Data-Engine). The Microsoft Azure launch announcement and OpenEBS details are below. In my discussion with the MSFT Azure PM, R&D and Eng teams during the design & evolution of Microsoft's Azure Container service... MSFT revealed that they expect 100'000's - 1,000,000's of Azure Container customers will deploy their new Azure Container Storage services (which are all driven by OpenEBS Mayastor NVMe Data-Engine). It would be somewhat sad to archive the project now that we've just had a major validation milestone event that... (I believe) no other CNCF Container Storage project can claim to have achieved. Info 1: https://azure.microsoft.com/en-gb/updates/public-preview-azure-container-storage/ |
|
We committed to OpenEbs not realizing that the project was at this point, very sad as it really does meet a huge need in Kubernetes. We are committed to ZFS and openebs is perfect for what we require. For us it was the zfs-local pv but we are looking at mayastor as well .. but it seems we should be looking elsewhere now .. Our prime concern was the lack of support and testing on recent Kubernetes releases, we are now restricted to 1.26, as zfs-localpv has a bug and it won't deploy on 1.27 May I suggest you add a note on each product page pointing out that this discussion is taking place and save some people some angst to implement a technology that may well disappear? No one wants to commit to core storage technology if it does not have the support and backing of the developers |
|
As one of the engineering leaders for OpenEBS, I'd like to assure that OpenEBS is very much active and the parent company is invested full-time on its growth.
As with any long-term projects that undergo changes, we too underwent a leadership change and there could be certain areas where we were not able to focus as much as we wanted to. But we are all learning and becoming better with each passing day. As regards to supporting the project and it's plethora of data engines, Mayastor is where most of the engineering is currently invested as we believe this to be a game-changer in the Kubernetes containerised storage domain. The Mayastor roadmap will be updated here. As regards to other data engines like Jiva, CStor and LocalPV variants, majority of them have reached feature-completeness and there are no new features being planned. We will make the best efforts to maintain these engines w.r.t. security and K8s API updates. We will always welcome contributions from our community users and open-source enthusiasts. |
|
Thanks everyone; it's clear that there's interest in the project, but also that it's not in a fully healthy state. Replies & questions@RealHarshThakur can you see Civo investing engineering resources in any way? @MarkCupitt can you, or someone else, confirm, if Kubernetes 1.27, released on April 11, 2023, is supported as of today? @kmova I couldn't find a Slack message anywhere, could you try again please? As an alternative, we can also have a call via . @kmova going through https://github.com/cncf/toc/blob/main/process/sandbox-annual-review.md does certainly not hurt @avishnu OpenEBS itself seems largely stale with five releases being
3.7.0's only change is the adding of new maintainers with no new commits in the repository since May 26, three weeks ago as of time of writing. I went back through the commits until early 2021 and it all seemed janitorial. https://github.com/openebs/mayastor looks a lot better, of course. Current state & way forwardIt's good to see new maintainers being added openebs/openebs@ac61a81 While there was some end user support, it was not a huge outpouring. This is not a deciding factor on its own, but it's still a signal. Other than the initial replies, there was no further information or specific plans for the future over the last few weeks, something I would expect to come from a project which might be archived. There's other health signals, i.e. I would expect the license scan badge in OpenEBS' readme or the Jenkins integration for Mayastor to be working correctly, or be fixed over the last few weeks. NB: I am using "expect" in the "that seems like a natural thing to do for a project and matches my experience in the field" not as in "[silently] demand that it must be done". Does deprecating parts of the overall projects and focusing on other parts make sense from the project's perspective? Is there a path to getting users to contribute directly or indirectly? There's no clear opinion discernible on TOC side at the moment, so I would prefer waiting for more input and data rather than call for, or cancel, the actual vote. |
|
Thanks @RichiH!! Looking forward to connect and review the plan the team has put together to address these concerns. While all the info provided in the comment is super helpful, we should discuss how to change this perception about the project.
https://github.com/openebs/openebs is not a code repo, rather a landing/info repo. There is not going to be much commits going in for every release. The release notes calls out the changes that went in Mayastor and Local PV engines as well as adding new contributors to the project. |
|
Thanks @RichiH for your inputs and suggestions and @kmova for the clarification about https://github.com/openebs/openebs being a landing project. Can I request to be invited to the call that is being discussed? |
|
@RichiH I can confirm that We ARE using it successfully on Kubernetes 1.26, with no identified issues so far |
|
@kmova I know it's a top-level repo, yet it used to get a lot more attention, doc changes, etc until a time aligned with a company purchase; same as other repos. @avishnu yes, of course! @kmova would you be willing to coordinate on OpenEBS side? @MarkCupitt thanks! Given the spike of activity in late May 2023, maybe that issue will get fixed as well |
|
@avishnu I took them from https://github.com/openebs/openebs/tags -- this data is taken from the git commit's date, and the respective tags that point to said commits. I confirmed on CLI to make sure the data in GitHub is correct, and noticed that 3.5.0 & 3.6.0 point to the same commit for some reason: I can't tell off-hand when the tags were created, but I can confirm that 3.4.0 points to a commit made in 2022: |
|
I just realized that GitHub persists the date of when a tag is pushed in the Releases, so as per https://github.com/openebs/openebs/releases the tag for 3.4.0 was pushed in Feb 17, but based on code in main repo which was old at that time. Maybe 9bda22d4810f7ab031536bedd9bd3d47a35fbe0d from Feb 16 was intended to be released? @niladrih might know. 3.5.0 was pushed on Mar 15, 3.6.0 on Apr 27, with the only change according to changelog being Mayastor 2.0.1 -> 2.1.0. |
|
@RichiH I'd like clarify here (re-iterate what @kmova commented above) that https://github.com/openebs/openebs is NOT a code repository. It is a Landing project and a placeholder for the community guidelines. Commits happen to this repository contents only when are changes to any of these guidelines, which is not very often. As you said above, it was janitorial early 2021 as well and the company purchase event happened much later towards the end of 2021. So, there is no correlation between the two. |
|
@avishnu I know that it's a top level repository. Claiming that there's no correlation at end of 2021 is not entirely correct, though |
|
TOC had an in-person offsite this week and also discussed inactive projects in general and OpenEBS in particular. After reaching out to TAG Storage Slack channel and based on private feedback, I have asked @chira001 and @xing-yang, TAG Storage co-chairs, if the TAG could come up with specific suggestions and/or requirements of how an active and healthy OpenEBS could look like. TOC will enter a six month observation phase and make a decision based on project actions and community feedback in March 2024. Also see https://cloud-native.slack.com/archives/C6PK4RLF7/p1694208906778189 |
Vote statusSo far Summary
Binding votes (7)
|
| User | Vote | Timestamp |
|---|---|---|
| avishnu | Against | 2024-01-16 17:30:36.0 +00:00:00 |
| orville-wright | Against | 2024-01-16 17:31:07.0 +00:00:00 |
| tiagolobocastro | Against | 2024-01-16 17:31:22.0 +00:00:00 |
| RealHarshThakur | Against | 2024-01-16 17:41:27.0 +00:00:00 |
| edrob999 | Against | 2024-01-16 18:43:47.0 +00:00:00 |
| MarkCupitt | Against | 2024-01-17 0:28:09.0 +00:00:00 |
| shaun-forgie | Against | 2024-01-17 1:01:04.0 +00:00:00 |
| cvsuotaku | Against | 2024-01-17 4:53:54.0 +00:00:00 |
| DIanAguilar28 | Against | 2024-01-17 8:19:25.0 +00:00:00 |
| Abhinandan-Purkait | Against | 2024-01-17 14:18:40.0 +00:00:00 |
| kmova | Against | 2024-01-17 17:26:47.0 +00:00:00 |
| niladrih | Against | 2024-01-17 19:10:38.0 +00:00:00 |
| w3aman | Against | 2024-01-18 5:49:42.0 +00:00:00 |
| dsharma-dc | Against | 2024-01-18 7:18:23.0 +00:00:00 |
| datacore-vvarakantham | Against | 2024-01-18 7:27:15.0 +00:00:00 |
| hrudaya21 | Against | 2024-01-19 4:48:52.0 +00:00:00 |
| chira001 | In favor | 2024-01-20 15:01:55.0 +00:00:00 |
| sagarkrsd | Against | 2024-01-21 5:44:52.0 +00:00:00 |
| ispeakc0de | Against | 2024-01-21 10:32:24.0 +00:00:00 |
| shovanmaity | Against | 2024-01-22 5:24:17.0 +00:00:00 |
| rohan2794 | Against | 2024-01-22 10:42:16.0 +00:00:00 |
| cswaas | Against | 2024-01-22 19:52:44.0 +00:00:00 |
| ksatchit | Against | 2024-01-23 16:19:05.0 +00:00:00 |
|
/check-vote |
|
Votes can only be checked once a day. |
|
It is clear that there are people who care deeply about OpenEBS and it's also clear that there are large/important users and use cases and no clear replacement. Yet, it's also evident that there's a repeating pattern of a flurry of communication and commitments every time TOC moves towards implementing the policies in place, with a seemingly inevitable fall-off shortly after. We have gone through this cycle repeatedly over the last 19 months. While there are several possible "official" ways to communicate specific and committed plans -- such as Slack, this GH issue, #905, or TAG Storage, none have been used to communicate said plans. As communicated previously, GitHub is preferred as it's public, searchable, and time-stamped. The outcome of the TOC vote is not certain either way. No matter the outcome of the vote, a good outcome for the project and the wider community would be a communication of committed plans and then their subsequent execution. Again, if the archival vote succeeds, the door does not close. While trademark and marketing are impacted, the GitHub repositories are not. Development can, and arguably should, continue. This can also be seen as a forcing function for both the management of existing contributors and large users who are currently not contributing; as a loud cry for help and investment. An archived project can re-apply for sandbox at any time. As communicated previously this is the best possible outcome of a successful archival vote. |
|
@RichiH, you are absolutely correct in your observation as we simply have not communicated as we should have. That will not happen again as I am now holding weekly all hands stand ups and funding a full time community lead (in addition to 20 dedicated devs). I will ask the dev team to post the detailed plan to GitHub as you request. I hope the ToC will see that while the communication has not been consistent, the commitment to the project has been. |
|
OpenEBS - Project Health Improvements.pdf |
|
Thanks. For convenience, https://docs.google.com/document/d/1QyWBa1ksJTyv6RawPrD9uJDqz4DEMIhSuTU5xs6OjFI/edit is the direct link the the GDoc underlying the PDF. |
|
@RichiH Agree that OpenEBS is a useful project, used by a lot of Kubernetes users in production. Also agree the communication needs improvement, and requests haven't been dealt with. As I've watched the project and talked to some of our members, people in the OpenEBS community contribute because they're interested in storage + Kubernetes. Many are not confident to communicate with CNCF on project issues. I (Ed Robinson) am happy to steward improving this, to understanding the CNCF guidelines, making sure the project agrees a path compliant, communicating with CNCF + resolving issues. I'll also set up a process so that the OpenEBS community can vote for a new steward. Moving the project to archive doesn't solve the communication problem. I'm hoping we can keep the project from being archived, and I will actively act as steward to make sure we are communicating, responding, and dealing with requests. Ed |
|
👋🏻 Hello everyone, in order to avoid future confusion as to the outstanding requests for OpenEBS and the impetus behind moving to an archive vote, the TOC has pulled together the following information to share with the project and all interested parties. Decision to move to Archive VoteThe TOC has made the decision to bring the OpenEBS project to a vote for archival in keeping with our Archive process; end users were notified on May 17th, 2023 of the proposal to archive. Archive processThe Archive process encompasses the TOC evaluating different indicators that were observed by community members and brought to the TOC's attention. Project health is one but not the only indicator the TOC weighed in moving this project to a vote for archive. While the TOC does anticipate project’s to shift their scope in response to contributors’ and adopter feedback, we expect Sandbox projects to experiment and make progress towards incubation, documenting their decisions transparently, demonstrating alignment with CNCF Values, and completing or responding to recommendations provided by the TOC and TAGs to enable the project to be successful within the CNCF. Past engagement with OpenEBSThe TOC has engaged the OpenEBS project on several occasions since this issue and its predecessor were opened on the repo. Issue #905 was filed after a low point of commit activity during the acquisition of Mayadata. It is anticipated companies who donate projects to CNCF could become acquired, which may result in decreased or stalled activity, occasionally withdrawing from a project altogether. Since OpenEBS was accepted into the CNCF as a Sandbox project, numerous issues with the project have occurred, in varying states of resolution with limited tracking. The OpenEBS project also made several, significant changes to their focus, most notably concerning the storage engines, and finally with the control plane, eventually concentrating its development efforts around Mayastor. Over several years of discussions with the project, its maintainers, and TAG Storage, the TOC has evaluated the project’s governance, documentation, activity, and general practices against those we expect of a Sandbox project. The last Annual review the project provided to the TOC, prior to removing manual annual reviews (2023) in favor of automation (coming 2024), was in 2021. The project applied to incubation level in 2020, received feedback from TAG Storage in August 2020, January 2021, and March 2022, but ultimately paused the incubation application in June 2022 and subsequently closed in May 2023 after highlighting continued areas of improvement needed by the project to be ready for incubation. Outstanding problemsIn addition to prior requests for resolution of feedback and action items, the TOC has reviewed the project’s governance practices and documentation, determining that:
Sandbox expectationsFurther, in re-evaluating OpenEBS against expectations of projects in a sandbox status (refer to the Sandbox Annual Review guide introduced with the TAGs in 2023 before removing manual annual reviews) the following is observed:
What to expect nextTypically, the findings and recommendations from sandbox annual reviews are filed with the project as an issue on their repo for tracking to completion, however given the continued recommendations over the past 3 years by TAG Storage and the TOC to bring the project back into alignment with these expectations, the TOC has called a vote to archive OpenEBS. This vote has been called to place the project in a state of archive. For more information on the expectations of an archive state in CNCF please refer to our Archive Status section, please note that archived projects may continue development in its repositories, ideally with a goal to reapply. If the Archive vote passesIn the event the Archive vote passes, the following recommendations are made to OpenEBS and Mayastor, should they choose to reapply:
If the Archive vote does not passIn the event the Archive vote does not pass, we fully expect the OpenEBS project to file an issue or series of issues on their repo, cross linked/referenced with this Issue so the TOC may monitor and track the above recommendations and the expectations to conclusion with the OpenEBS project, with substantive progress by the end of August 2024. Final NoteWe appreciate the OpenEBS project and its maintainers engaging on this issue recently, and thank everyone for their insights, observations, and efforts in bringing this discussion to closure. As a reminder, the TOC maintains several official communication mediums by which project maintainers, contributors, and interested parties may reach out to the TOC. We may be reached on slack in the #toc channel, by email at [email protected] or [email protected] (for sensitive matters), through our Repo by filing an issue, or by joining our twice monthly public meetings. This ensures all TOC members are kept apprised of discussions, statuses, and commitments of projects and the TOC. We have several CNCF staff that support the TOC in monitoring these communication methods. Directly contacting TOC members individually is generally discouraged as we perform this function in addition to our regular work and such contact may be lost amid day-to-day tasks, illnesses, holidays, or other events. |
|
Thanks @TheFoxAtWork for this info. It is the project team's request that OpenEBS is NOT archived. We commit to resolving the issues you have identified, using the cross linked/referenced process you suggest, and making substantive progress before end of August 2024. |
Vote statusSo far Summary
Binding votes (10)
|
| User | Vote | Timestamp |
|---|---|---|
| avishnu | Against | 2024-01-16 17:30:36.0 +00:00:00 |
| orville-wright | Against | 2024-01-16 17:31:07.0 +00:00:00 |
| tiagolobocastro | Against | 2024-01-16 17:31:22.0 +00:00:00 |
| RealHarshThakur | Against | 2024-01-16 17:41:27.0 +00:00:00 |
| edrob999 | Against | 2024-01-16 18:43:47.0 +00:00:00 |
| MarkCupitt | Against | 2024-01-17 0:28:09.0 +00:00:00 |
| shaun-forgie | Against | 2024-01-17 1:01:04.0 +00:00:00 |
| cvsuotaku | Against | 2024-01-17 4:53:54.0 +00:00:00 |
| DIanAguilar28 | Against | 2024-01-17 8:19:25.0 +00:00:00 |
| Abhinandan-Purkait | Against | 2024-01-17 14:18:40.0 +00:00:00 |
| kmova | Against | 2024-01-17 17:26:47.0 +00:00:00 |
| niladrih | Against | 2024-01-17 19:10:38.0 +00:00:00 |
| w3aman | Against | 2024-01-18 5:49:42.0 +00:00:00 |
| dsharma-dc | Against | 2024-01-18 7:18:23.0 +00:00:00 |
| datacore-vvarakantham | Against | 2024-01-18 7:27:15.0 +00:00:00 |
| hrudaya21 | Against | 2024-01-19 4:48:52.0 +00:00:00 |
| chira001 | In favor | 2024-01-20 15:01:55.0 +00:00:00 |
| sagarkrsd | Against | 2024-01-21 5:44:52.0 +00:00:00 |
| ispeakc0de | Against | 2024-01-21 10:32:24.0 +00:00:00 |
| shovanmaity | Against | 2024-01-22 5:24:17.0 +00:00:00 |
| rohan2794 | Against | 2024-01-22 10:42:16.0 +00:00:00 |
| cswaas | Against | 2024-01-22 19:52:44.0 +00:00:00 |
| ksatchit | Against | 2024-01-23 16:19:05.0 +00:00:00 |
| imrajdas | Against | 2024-01-24 20:23:01.0 +00:00:00 |
| lukaszgryglicki | Against | 2024-01-24 20:43:13.0 +00:00:00 |
| akhilerm | Against | 2024-01-25 12:49:58.0 +00:00:00 |
| sinhaashish | Against | 2024-01-31 4:49:33.0 +00:00:00 |
github-project-automation
bot
moved this from Active Review & Discussion
to Done
in CNCF TOC Board
Vote closedThe vote passed! 🎉
Summary
Binding votes (10)
|
| User | Vote | Timestamp |
|---|---|---|
| @avishnu | Against | 2024-01-16 17:30:36.0 +00:00:00 |
| @orville-wright | Against | 2024-01-16 17:31:07.0 +00:00:00 |
| @tiagolobocastro | Against | 2024-01-16 17:31:22.0 +00:00:00 |
| @RealHarshThakur | Against | 2024-01-16 17:41:27.0 +00:00:00 |
| @edrob999 | Against | 2024-01-16 18:43:47.0 +00:00:00 |
| @MarkCupitt | Against | 2024-01-17 0:28:09.0 +00:00:00 |
| @shaun-forgie | Against | 2024-01-17 1:01:04.0 +00:00:00 |
| @cvsuotaku | Against | 2024-01-17 4:53:54.0 +00:00:00 |
| @DIanAguilar28 | Against | 2024-01-17 8:19:25.0 +00:00:00 |
| @Abhinandan-Purkait | Against | 2024-01-17 14:18:40.0 +00:00:00 |
| @kmova | Against | 2024-01-17 17:26:47.0 +00:00:00 |
| @niladrih | Against | 2024-01-17 19:10:38.0 +00:00:00 |
| @w3aman | Against | 2024-01-18 5:49:42.0 +00:00:00 |
| @dsharma-dc | Against | 2024-01-18 7:18:23.0 +00:00:00 |
| @datacore-vvarakantham | Against | 2024-01-18 7:27:15.0 +00:00:00 |
| @hrudaya21 | Against | 2024-01-19 4:48:52.0 +00:00:00 |
| @chira001 | In favor | 2024-01-20 15:01:55.0 +00:00:00 |
| @sagarkrsd | Against | 2024-01-21 5:44:52.0 +00:00:00 |
| @ispeakc0de | Against | 2024-01-21 10:32:24.0 +00:00:00 |
| @shovanmaity | Against | 2024-01-22 5:24:17.0 +00:00:00 |
| @rohan2794 | Against | 2024-01-22 10:42:16.0 +00:00:00 |
| @cswaas | Against | 2024-01-22 19:52:44.0 +00:00:00 |
| @ksatchit | Against | 2024-01-23 16:19:05.0 +00:00:00 |
| @imrajdas | Against | 2024-01-24 20:23:01.0 +00:00:00 |
| @lukaszgryglicki | Against | 2024-01-24 20:43:13.0 +00:00:00 |
| @akhilerm | Against | 2024-01-25 12:49:58.0 +00:00:00 |
| @sinhaashish | Against | 2024-01-31 4:49:33.0 +00:00:00 |
|
After the OpenEBS project status was changed to "Archive", we discussed what happened and decided as a team we will adopt the changes recommended by TOC members, and follow the advice to formally re-apply as a sandbox project once we are ready. We have about 700,000 OpenEBS users that rely on the project, we owe it to them to move as quickly as we can. We're tracking the changes in a GitHub parent issue @avishnu cross-linked above. |
|
@edrob999 thanks for the update. This seems to be great plan to go forward with. Looking forward to OpenEBS resubmitting in the future! |
|
@RichiH and @TheFoxAtWork I want to highlight that while OpenEBS is trying to get readmitted, this readmittence should not be accepted within any reasonable timeframe. During their changes to become readmitted, they managed to break their Helm Charts, affecting MANY production users, multiple times by making incredible amateuristic mistakes. They managed to do so 3 times in just 2024. There also seems to be no reflection what so ever on how bad these mistakes where and the ability to take responsibility for these significant mistakes, seems to be completely lacking. In short: |
|
Hello again @Ornias1993. In response to your other suggestions: No we are not going to fire the person responsible. No this was not done by a beginner intern. If you want to talk, just ping me. We're all on the same side, and sometimes talking helps us understand each other better. @Ornias1993 is correct. What happened is: On the TOC's recommendation, the OpenEBS maintainers gave notice we would be archiving engines/repos that were deprecated/no longer maintained. We then archived about 66% of the project, and sought to keep the archived versions installable + working. This stuff is complicated! When we archived the engines some helm charts had problems. You can see the team jumped on it quickly, and made fixes. We didn't want this to happen. We responded really quickly when it did. Every member of our community is important - I'm sorry for your hurt @Ornias1993, let me know if you want to talk thru it. |
I was indeed made aware of it.
You indeed posted such a notice and keep pointing to that.
ZFS Local-PV wasn't an achieved version on that list
Actually, realising that nuking a helm-repo index file causes breakage for users is absolutely minimally trivial.
I appreciate the guy breaking your helm charts jumping on it within a few days to fix his mistakes again.
I sincerely hope so. At the very lesat the staff member involved should've been put on a heavy coaching and training course. But the fact there is always an excuse for these entry-level mistakes, show that OpenEBS and Mayadata is still not taking actual accountability. This time it's, yet again, pointing at an unrelated announcement about things being archived. Which: I'm not hurt or angry in any way, I just objectively came to the conclussion that OpenEBS is not ready for readmittance due to the way it is actually handling its attempt at being readmitted. |
|
@Ornias1993 Don't you feel you are being unreasonably rude here? Appreciate if you show bit more gratitude for open-source developers. We acknowledged the mistakes and tried to contain the impact within reasonable time-frames by revoking the affected changes and providing the fix there-after. The users who brought this to our attention, were satisfied with our responses. Open-source is about collaboration. If you could have helped in the review of the change request which led to the ZFS LocalPV Helm chart bug, we might have avoided the situation. We always appreciate and value constructive insights from external contributors, including criticism. Sorry to say, your words are hurtful. You willing, we'd be happy to have you help us on Helm-related changes in the future. |
|
@Ornias1993 you've posted this on multiple forums. Everyone sees your problem. In the OpenEBS project, we try to be respectful of differing opinions, viewpoints, and experiences. Its OK to criticize the project, but not derogatory comments about the contributors. Again I'm happy to talk it thru. |
No I do not feel i'm unreasonable. A post about OpenEBS being not being ready for readmittence is not the place "to show gratitude", i'm not going to sugarcoat that with "american service" level nonesense by first writhing a whole piece about how gratefull I am.
"ohh yes this is a mistake we need to fix" is not the same as "Our procedures where sub par and our review was completely lacking. We've done X, Y and Z to prevent this in the future" The later is actually taking accountability. Just admitting something was a mistake, then making 2 similair entry-level mistakes in the months following, does not show actual understanding of the severity.
I was not, nor where our 20-35k users.
It's not like I get daily updates on each PR opened on each software package I use... As a downstream user, I trusted OpenEBS as a trustworthy upstream. Without any actual accountability taken, which means: Actually reflecting on mistakes and how they are going to be prevented in the future.
Your, as in OpenEBS maintainers, actions where factually damaging. Simply put: Instead of: Even after these 3(!) big mistakes in a few months they could've shown said accountability. It isn't about feelings, mine nor theirs, it's about trustworthy software. |
OpenEBS has been archived ref: cncf/toc#1051 Signed-off-by: Bob Killen <[email protected]>
I would like to propose an archival vote for the OpenEBS project.
As per #905 , #506 (comment) , and https://app.slack.com/client/T08PSQ7BQ/C0MP69YF4 there have been substantial concerns about the continued health of the project for almost a year by now, with no equally substantial actions by the project to counteract or alleviate said concerns.
As per yesterday's TOC call, we are already following #1050 in spirit even though it is not accepted yet. The only material difference for this process is that the two week mandatory discussion phase does not trigger immediately after informing the maintainers, the end user community must also be informed prior to the discussion phase beginning.
As this is in favor of OpenEBS, I see no issues with applying the updated process. At the active request of OpenEBS maintainers, we can also follow the old process.
CC @gila @GlennBullingham @kmova @nconnolly1 @pawanpraka1 @vishnuitta
The text was updated successfully, but these errors were encountered: