You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to respectfully raise a broader governance and package ownership concern around the Pomelo ecosystem.
The 10.0 cycle seems like the right opportunity to revisit this, because there are already several long standing issues related to NuGet ownership, deprecated packages, legacy packages, organization authority, maintainer support, and project governance. These issues have remained unresolved for years, while the main provider continues to be widely used as critical infrastructure by many .NET projects.
This issue is not intended to blame the current maintainer for the 10.0 delay. The opposite is true: if the project currently depends heavily on one active volunteer maintainer, then the organization and package ownership model should reflect that reality and support that maintainer more clearly.
This affects user trust, package discovery, maintenance responsibility, release management, security related package management, public attribution, and the public credit model around the project.
Pomelo.EntityFrameworkCore.MySql has a very large number of downloads and many downstream packages and repositories depending on it. Because of that, users should be able to clearly understand:
who maintains the provider today
which packages are active today
which packages are deprecated or legacy
which NuGet owners are responsible for package management today
whether the organization account has sufficient control over all active packages
whether historical authorship is clearly separated from current operational responsibility
whether the current maintainer has the GitHub organization authority needed to manage the project going forward
whether 10.0 release expectations are being set realistically for a volunteer maintained project
There are already several open issues that point to the same underlying problem.
In Consolidate NuGet packages under new organization account #1172, @lauxjpn proposed consolidating NuGet packages under the PomeloFoundation organization account. The issue was opened in 2020, is still open, and is currently assigned to the 10.0.0 milestone. The proposal there was that all Pomelo related packages should add PomeloFoundation as an owner, so that all packages can be managed through the organization.
In Deprecate older NuGet packages #1148, @lauxjpn proposed deprecating older NuGet packages, because Pomelo has released many packages over the years while only a few are still maintained. That issue is also still open and assigned to the 10.0.0 milestone.
In Should we join the .NET Foundation? #646, the question of joining the .NET Foundation has been open since 2018 and is still marked as blocked. That suggests that project governance has been a long standing unresolved topic.
In What's in a name? Lolita#22, there was already a concrete example where package naming, NuGet ownership, package reputation, and project identity intersected. That issue remains a useful example of why package identity and public project reputation matter.
Taken together, these issues suggest a recurring problem: technical maintenance can continue for the main provider, while package ownership, legacy package cleanup, public project identity, organization authority, and responsibility for old packages remain unclear.
Current 10.0 pressure and maintainer support
There has recently been visible user pressure around the lack of a stable 10.0 compatible release. I understand why users are concerned, because many downstream projects depend on this provider and .NET 10 adoption is blocked for some of them.
At the same time, this is an open source volunteer maintained project. The current maintainer should not be treated as if they were a paid vendor with a guaranteed release SLA. The EF Core 10 tracking issue and the EF Core 10 upgrade pull request show that work has been started, but this kind of provider upgrade requires compatibility work, CI updates, database version testing, query baseline updates, and a large test matrix across MySQL and MariaDB versions.
This is exactly why the governance issue matters. If most recent maintenance work depends on one volunteer maintainer, then the project should make that reality explicit and support that maintainer with clear organization authority, clear NuGet ownership, clear package governance, and a clear public release policy.
A lack of clear governance can make user frustration worse. Users see a widely downloaded package under a foundation name and may assume there is a larger active organization behind it. From the outside, they may not understand whether delays are caused by technical blockers, lack of maintainer time, lack of release authority, unresolved NuGet ownership, unclear organization permissions, or historical package governance issues.
The goal should not be to put more personal pressure on the current maintainer. The goal should be to reduce that pressure by clarifying:
who is actively maintaining the provider
who has authority to publish packages
who can manage NuGet ownership
who can make organization level decisions
what the realistic 10.0 release plan is
what kind of help is actually useful from contributors
whether any release or cleanup work is blocked by historical ownership or organization permissions
A clearer governance model would help users set realistic expectations, help contributors understand where to help, and help avoid unfairly directing all frustration at the one person who appears to be doing most of the current maintenance work.
Historical authorship and current operational responsibility
There is a specific governance concern around the mismatch between historical authorship, current maintenance work, organization membership, and package ownership.
The current project wiki lists 8.x through 3.x under @lauxjpn, 2.x under @caleblloyd, and 1.x under @yukozh:
That appears to reflect the actual later maintenance history of the provider. Recent major version support work and public maintainer activity have primarily been associated with @lauxjpn.
However, there is also a concrete example showing why historical credit and current maintenance responsibility need to be separated more clearly.
In this wiki revision from Aug 8, 2023, edited by Yuko Zheng, the Main Authors table listed 8.x under @yukozh, while 7.x through 3.x were listed under @lauxjpn:
The current wiki page later changed 8.x back to @lauxjpn.
This raises a reasonable governance question. If a historical creator can still change public project attribution for a major version that was not actually maintained by them, while the current maintainer does not appear on the public PomeloFoundation organization members page, then the project does not have a clear public separation between historical authorship, current maintainership, and organization level authority.
There are also issues from the 7.0 to 8.0 period, such as #1779 and #1781, that are assigned to @yukozh and are now still open under the 10.0.0 milestone. This raises further questions about whether assignment, authorship metadata, and governance authority have consistently reflected actual maintenance work during recent major release cycles.
Could the project clarify whether @yukozh performed active maintenance work for the 8.0 cycle, and if so, where that work is documented?
If @yukozh did not perform active maintenance work for the 8.0 cycle, could the project explain why 8.x was at one point attributed to @yukozh in the wiki, and what safeguards now exist to keep public authorship metadata aligned with actual maintenance work?
From the outside, @lauxjpn does not appear on that public organization members page, even though the project wiki attributes 3.x through 8.x to @lauxjpn, and @lauxjpn appears to be the main active maintainer of the provider.
This creates an unclear governance model. The person doing the main provider maintenance appears to have less visible organization level standing than accounts that do not appear to be actively maintaining the provider.
Could the project clarify why @lauxjpn is not publicly listed as a PomeloFoundation organization member?
Could the project also clarify whether @lauxjpn has the necessary organization level authority for:
repository administration
release management
NuGet ownership management
package deprecation
package unlisting
security related package actions
future maintainer onboarding
owner invitation and removal
organization level governance decisions
If @lauxjpn already has that authority, it would be helpful to document it clearly. If not, I think that is a governance problem that should be resolved before or during the 10.0 release cycle.
NuGet ownership and package identity
NuGet ownership is publicly visible and can be interpreted by users, employers, contributors, and downstream projects as an indication of current maintenance responsibility.
The main package currently lists individual owners and the organization account together:
Some of these packages appear to be obsolete, prerelease only, unrelated to the currently maintained provider, or last updated many years ago. This makes it difficult for users to distinguish the actively maintained Pomelo provider ecosystem from historical, abandoned, experimental, or unrelated Pomelo prefixed projects.
This is not about removing historical credit. Early authors and former maintainers should continue to be acknowledged in the README, wiki, release notes, credits section, or project history.
The concern is that historical credit and operational authority are currently mixed together. A historical creator or early maintainer can remain visibly associated with the package and organization long after active maintenance has moved to other people. That is appropriate for historical credit, but it becomes problematic if the same accounts still affect package ownership, organization control, package deprecation, owner invitations, package metadata, security related package management, or cleanup of legacy Pomelo packages.
Maintaining clear operational ownership is also aligned with standard package registry guidelines regarding abandoned or absentee-owned packages, ensuring supply chain security and clear accountability.
Users need a reliable way to identify:
who currently maintains the package
who can publish packages
who can deprecate or unlist obsolete packages
who can add or remove package owners
who controls the organization account
which Pomelo prefixed packages are still part of the active provider ecosystem
which Pomelo prefixed packages are historical, obsolete, or unrelated
Suggested actions
I think the 10.0 cycle is the right time to finish this cleanup, or at least publish a clear plan.
Suggested actions:
Add PomeloFoundation as owner to all active Pomelo related NuGet packages.
Make PomeloFoundation the primary operational owner for active packages.
Clarify whether historical individual owners are still expected to act as maintainers, package owners, or organization administrators.
If historical individual owners are no longer active maintainers, move their role to documented historical credit while keeping operational control with the current maintainers and the organization account.
Add @lauxjpn to PomeloFoundation with the necessary organization role if that has not already been done privately.
Publish a list in the repository README or wiki that clearly separates:
active packages
deprecated packages
legacy packages kept only for restore compatibility
packages no longer related to the current provider
historical or experimental Pomelo prefixed packages
Deprecate obsolete packages on NuGet.org with a clear recommended replacement where one exists.
Unlist packages that should no longer be discovered by new users, while keeping them available for exact version restore.
Clarify who the current maintainers are for the main provider and related packages.
Clarify who has permission to publish, deprecate, unlist, or transfer NuGet packages.
Publish a realistic 10.0 release status note, including what is already working, what remains blocked, what contributors can help with, and whether a preview package is expected.
Document a simple governance policy for future major releases, including:
who can publish packages
who can accept new package owners
who is responsible for deprecating old packages
how inactive owners should be handled
how public version authorship should be assigned
how successor packages should be announced
how organization membership should reflect active maintenance responsibility
how user expectations should be handled for volunteer maintained major release upgrades
Clarify whether there are any blockers that require action from historical package owners or organization administrators. If the organizational and ownership blockers cannot be resolved due to absentee ownership, and considering the urgent community need for .NET 10 compatibility, does the active maintainer or the community have a contingency plan? For example, would it be appropriate to consider a community fork under a new organizational namespace to ensure the project can move forward without governance blockers?
Whether @lauxjpn is currently the sole active maintainer of the main provider.
Whether @lauxjpn has full GitHub organization authority for PomeloFoundation.
If @lauxjpn does not have full organization authority, why the current main maintainer has not been added to PomeloFoundation with the necessary role.
Whether @yukozh still has any active operational responsibility for the main provider.
Whether @yukozh still has any active operational responsibility for PomeloFoundation organization governance.
Whether @yukozh still has any active operational responsibility for Pomelo prefixed NuGet packages.
Whether any cleanup work is blocked by @yukozh (AmamiyaYuuko), or other historical owners.
Whether all active Pomelo packages can be owned by PomeloFoundation.
Whether PomeloFoundation should become the primary operational owner of all active Pomelo packages on NuGet.
Whether historical individual owners should remain package owners, or be moved to documented historical credit instead.
Which Pomelo packages are considered active today.
Which older Pomelo packages should be deprecated or unlisted.
Which Pomelo prefixed packages are unrelated to the currently maintained provider ecosystem.
Whether obsolete Pomelo prefixed packages under historical ownership will be deprecated, unlisted, renamed, archived, or documented as legacy.
Whether the project intends to document current maintainers, package ownership, organization authority, and release governance more clearly before or during the 10.0 release cycle.
Whether there is a policy to prevent public version authorship metadata from being changed in a way that does not reflect actual maintenance work.
Whether current 10.0 progress, remaining blockers, and useful contributor tasks can be documented in one place.
Whether any lack of organization authority, NuGet ownership authority, or historical owner action is slowing down 10.0 release management or package cleanup.
Thank you to everyone who has maintained the provider over the years, especially the maintainers who continue to handle releases, compatibility work, CI, database version testing, user support, and EF Core major version upgrades.
This cleanup would make the project easier to trust, easier to contribute to, and easier for users to evaluate going forward. It would also help reduce unfair pressure on the current maintainer by making the actual maintenance structure, authority model, and release expectations clear.
I would like to respectfully raise a broader governance and package ownership concern around the Pomelo ecosystem.
The 10.0 cycle seems like the right opportunity to revisit this, because there are already several long standing issues related to NuGet ownership, deprecated packages, legacy packages, organization authority, maintainer support, and project governance. These issues have remained unresolved for years, while the main provider continues to be widely used as critical infrastructure by many .NET projects.
This issue is not intended to blame the current maintainer for the 10.0 delay. The opposite is true: if the project currently depends heavily on one active volunteer maintainer, then the organization and package ownership model should reflect that reality and support that maintainer more clearly.
This affects user trust, package discovery, maintenance responsibility, release management, security related package management, public attribution, and the public credit model around the project.
Pomelo.EntityFrameworkCore.MySqlhas a very large number of downloads and many downstream packages and repositories depending on it. Because of that, users should be able to clearly understand:There are already several open issues that point to the same underlying problem.
In Consolidate NuGet packages under new organization account #1172, @lauxjpn proposed consolidating NuGet packages under the
PomeloFoundationorganization account. The issue was opened in 2020, is still open, and is currently assigned to the 10.0.0 milestone. The proposal there was that all Pomelo related packages should addPomeloFoundationas an owner, so that all packages can be managed through the organization.In Deprecate older NuGet packages #1148, @lauxjpn proposed deprecating older NuGet packages, because Pomelo has released many packages over the years while only a few are still maintained. That issue is also still open and assigned to the 10.0.0 milestone.
In Should we join the .NET Foundation? #646, the question of joining the .NET Foundation has been open since 2018 and is still marked as blocked. That suggests that project governance has been a long standing unresolved topic.
In What's in a name? Lolita#22, there was already a concrete example where package naming, NuGet ownership, package reputation, and project identity intersected. That issue remains a useful example of why package identity and public project reputation matter.
Taken together, these issues suggest a recurring problem: technical maintenance can continue for the main provider, while package ownership, legacy package cleanup, public project identity, organization authority, and responsibility for old packages remain unclear.
Current 10.0 pressure and maintainer support
There has recently been visible user pressure around the lack of a stable 10.0 compatible release. I understand why users are concerned, because many downstream projects depend on this provider and .NET 10 adoption is blocked for some of them.
At the same time, this is an open source volunteer maintained project. The current maintainer should not be treated as if they were a paid vendor with a guaranteed release SLA. The EF Core 10 tracking issue and the EF Core 10 upgrade pull request show that work has been started, but this kind of provider upgrade requires compatibility work, CI updates, database version testing, query baseline updates, and a large test matrix across MySQL and MariaDB versions.
This is exactly why the governance issue matters. If most recent maintenance work depends on one volunteer maintainer, then the project should make that reality explicit and support that maintainer with clear organization authority, clear NuGet ownership, clear package governance, and a clear public release policy.
A lack of clear governance can make user frustration worse. Users see a widely downloaded package under a foundation name and may assume there is a larger active organization behind it. From the outside, they may not understand whether delays are caused by technical blockers, lack of maintainer time, lack of release authority, unresolved NuGet ownership, unclear organization permissions, or historical package governance issues.
The goal should not be to put more personal pressure on the current maintainer. The goal should be to reduce that pressure by clarifying:
A clearer governance model would help users set realistic expectations, help contributors understand where to help, and help avoid unfairly directing all frustration at the one person who appears to be doing most of the current maintenance work.
Historical authorship and current operational responsibility
There is a specific governance concern around the mismatch between historical authorship, current maintenance work, organization membership, and package ownership.
The current project wiki lists 8.x through 3.x under @lauxjpn, 2.x under @caleblloyd, and 1.x under @yukozh:
https://github.com/PomeloFoundation/Pomelo.EntityFrameworkCore.MySql/wiki/Home
That appears to reflect the actual later maintenance history of the provider. Recent major version support work and public maintainer activity have primarily been associated with @lauxjpn.
However, there is also a concrete example showing why historical credit and current maintenance responsibility need to be separated more clearly.
In this wiki revision from Aug 8, 2023, edited by Yuko Zheng, the Main Authors table listed 8.x under @yukozh, while 7.x through 3.x were listed under @lauxjpn:
https://github.com/PomeloFoundation/Pomelo.EntityFrameworkCore.MySql/wiki/Home/8a1ee9b3167c21087f6dbb6fcbabaa22d5f3093e
The current wiki page later changed 8.x back to @lauxjpn.
This raises a reasonable governance question. If a historical creator can still change public project attribution for a major version that was not actually maintained by them, while the current maintainer does not appear on the public PomeloFoundation organization members page, then the project does not have a clear public separation between historical authorship, current maintainership, and organization level authority.
There are also issues from the 7.0 to 8.0 period, such as #1779 and #1781, that are assigned to @yukozh and are now still open under the 10.0.0 milestone. This raises further questions about whether assignment, authorship metadata, and governance authority have consistently reflected actual maintenance work during recent major release cycles.
Could the project clarify whether @yukozh performed active maintenance work for the 8.0 cycle, and if so, where that work is documented?
If @yukozh did not perform active maintenance work for the 8.0 cycle, could the project explain why 8.x was at one point attributed to @yukozh in the wiki, and what safeguards now exist to keep public authorship metadata aligned with actual maintenance work?
Organization membership and maintainer authority
The public PomeloFoundation organization members page currently lists @AndriySvyryd, @toralux, and @yukozh:
https://github.com/orgs/PomeloFoundation/people
From the outside, @lauxjpn does not appear on that public organization members page, even though the project wiki attributes 3.x through 8.x to @lauxjpn, and @lauxjpn appears to be the main active maintainer of the provider.
This creates an unclear governance model. The person doing the main provider maintenance appears to have less visible organization level standing than accounts that do not appear to be actively maintaining the provider.
Could the project clarify why @lauxjpn is not publicly listed as a PomeloFoundation organization member?
Could the project also clarify whether @lauxjpn has the necessary organization level authority for:
If @lauxjpn already has that authority, it would be helpful to document it clearly. If not, I think that is a governance problem that should be resolved before or during the 10.0 release cycle.
NuGet ownership and package identity
NuGet ownership is publicly visible and can be interpreted by users, employers, contributors, and downstream projects as an indication of current maintenance responsibility.
The main package currently lists individual owners and the organization account together:
https://www.nuget.org/packages/Pomelo.EntityFrameworkCore.MySql
The AmamiyaYuuko NuGet profile also lists many Pomelo prefixed packages:
https://www.nuget.org/profiles/AmamiyaYuuko
Some of these packages appear to be obsolete, prerelease only, unrelated to the currently maintained provider, or last updated many years ago. This makes it difficult for users to distinguish the actively maintained Pomelo provider ecosystem from historical, abandoned, experimental, or unrelated Pomelo prefixed projects.
This is not about removing historical credit. Early authors and former maintainers should continue to be acknowledged in the README, wiki, release notes, credits section, or project history.
The concern is that historical credit and operational authority are currently mixed together. A historical creator or early maintainer can remain visibly associated with the package and organization long after active maintenance has moved to other people. That is appropriate for historical credit, but it becomes problematic if the same accounts still affect package ownership, organization control, package deprecation, owner invitations, package metadata, security related package management, or cleanup of legacy Pomelo packages.
Maintaining clear operational ownership is also aligned with standard package registry guidelines regarding abandoned or absentee-owned packages, ensuring supply chain security and clear accountability.
Users need a reliable way to identify:
Suggested actions
I think the 10.0 cycle is the right time to finish this cleanup, or at least publish a clear plan.
Suggested actions:
Add
PomeloFoundationas owner to all active Pomelo related NuGet packages.Make
PomeloFoundationthe primary operational owner for active packages.Clarify whether historical individual owners are still expected to act as maintainers, package owners, or organization administrators.
If historical individual owners are no longer active maintainers, move their role to documented historical credit while keeping operational control with the current maintainers and the organization account.
Add @lauxjpn to PomeloFoundation with the necessary organization role if that has not already been done privately.
Publish a list in the repository README or wiki that clearly separates:
Deprecate obsolete packages on NuGet.org with a clear recommended replacement where one exists.
Unlist packages that should no longer be discovered by new users, while keeping them available for exact version restore.
Clarify who the current maintainers are for the main provider and related packages.
Clarify who has permission to publish, deprecate, unlist, or transfer NuGet packages.
Publish a realistic 10.0 release status note, including what is already working, what remains blocked, what contributors can help with, and whether a preview package is expected.
Document a simple governance policy for future major releases, including:
Clarify whether there are any blockers that require action from historical package owners or organization administrators. If the organizational and ownership blockers cannot be resolved due to absentee ownership, and considering the urgent community need for .NET 10 compatibility, does the active maintainer or the community have a contingency plan? For example, would it be appropriate to consider a community fork under a new organizational namespace to ensure the project can move forward without governance blockers?
Questions for maintainers
Could the maintainers please confirm:
Whether Consolidate NuGet packages under new organization account #1172 is still intended for 10.0.0.
Whether Deprecate older NuGet packages #1148 is still intended for 10.0.0.
Whether @lauxjpn is currently the sole active maintainer of the main provider.
Whether @lauxjpn has full GitHub organization authority for PomeloFoundation.
If @lauxjpn does not have full organization authority, why the current main maintainer has not been added to PomeloFoundation with the necessary role.
Whether @yukozh still has any active operational responsibility for the main provider.
Whether @yukozh still has any active operational responsibility for PomeloFoundation organization governance.
Whether @yukozh still has any active operational responsibility for Pomelo prefixed NuGet packages.
Whether any cleanup work is blocked by @yukozh (AmamiyaYuuko), or other historical owners.
Whether all active Pomelo packages can be owned by
PomeloFoundation.Whether PomeloFoundation should become the primary operational owner of all active Pomelo packages on NuGet.
Whether historical individual owners should remain package owners, or be moved to documented historical credit instead.
Which Pomelo packages are considered active today.
Which older Pomelo packages should be deprecated or unlisted.
Which Pomelo prefixed packages are unrelated to the currently maintained provider ecosystem.
Whether obsolete Pomelo prefixed packages under historical ownership will be deprecated, unlisted, renamed, archived, or documented as legacy.
Whether the project intends to document current maintainers, package ownership, organization authority, and release governance more clearly before or during the 10.0 release cycle.
Whether there is a policy to prevent public version authorship metadata from being changed in a way that does not reflect actual maintenance work.
Whether current 10.0 progress, remaining blockers, and useful contributor tasks can be documented in one place.
Whether any lack of organization authority, NuGet ownership authority, or historical owner action is slowing down 10.0 release management or package cleanup.
Thank you to everyone who has maintained the provider over the years, especially the maintainers who continue to handle releases, compatibility work, CI, database version testing, user support, and EF Core major version upgrades.
This cleanup would make the project easier to trust, easier to contribute to, and easier for users to evaluate going forward. It would also help reduce unfair pressure on the current maintainer by making the actual maintenance structure, authority model, and release expectations clear.