Hi Laura & Mattia, We're talking about the Google-Ads-GoogleAds-Client distribution, right?
I just checked, and MATTIAT has co-maint on all packages in that distribution. So that's not a problem. You didn't say exactly what problem Mattia experienced, but I've found one problem: • In your CPAN directory I can see a release Google-Ads-GoogleAds-Client-33.0.0.tar.gz • In Mattia's directory I can see a release Google-Ads-GoogleAds-Client-33.0.0.tar.gz You can't release the same version number multiple times - this is a security restrictions. I haven't checked the timestamps on the two releases, but given that yours is in the CPAN Index, and you're saying that Mattia's failed, then it's a safe guess that his came second. I suspect that Mattia just needs to bump the version before doing a release, and his release will then be indexed. Cheers, Neil On 4 Aug 2026 at 19:36 +0100, Laura Chevalier via modules <[email protected]>, wrote: > Hey Neil, > > Thanks for the reply. If I understand what you're saying, the "alternative > interface for adding co-maint per module/package" is what I tried for the > last release. I thought I granted per-module co-maintainership to all modules > in the previous release and the non-version-specific modules, similar to how > you handled it for Dora, but that didn't prevent the permission problems > Mattia ran into. Do you have any idea why that didn't work this time? > > For your alternative solution, are you suggesting we include only the latest > Google Ads API version in a given dist version, e.g. > Google::Ads::GoogleAds::V25::* in a separate dist version from previous > Google Ads API versions? Or are you proposing putting them under a separate > distribution altogether (e.g., having the package be > Google::Ads::GoogleAds::V25 instead of Google::Ads::GoogleAds)? If I > understand correctly, either option would pose its own problems and > potentially break users' existing integrations or workflows. Let me know if > I've misunderstood. > > If we can resolve the per-module co-maintainership issue, I think that would > be the preferred and sufficiently future-proof solution. If not, we can look > deeper into shared credentials or potentially changing how we distribute new > versions. > > Many thanks, > > Laura Chevalier > Developer Relations Engineer > [email protected] > > > > On Tue, Aug 4, 2026 at 12:02 PM Neil Bowers <[email protected]> wrote: > > Hi Mattia, > > > > I think what you're saying is that you want multiple people to have > > co-maint on all of the packages in the distribution(s). > > > > But right now you can't use the interface for "give co-maint on the > > distribution", because it times out before it can complete (because of how > > many packages there are in the distribution). > > > > You can use the alternative interface for adding co-maint per > > module/package. I don't think that suffers from the timeout problem, but > > it's a tedious approach for you, given how many packages there are. > > > > Another approach: if I remember rightly, the package explosion is because > > version numbers are embedded in package names, and you want backwards > > compatibility. Could you split off packages to support older versions of > > the API into a separate distribution, or even multiple distributions? > > > > Cheers, > > Neil > >
