Reserve the Composer namespace drupal/toolbar for this project

These offers need to be created in the project issue queue, even when the person asking for more permissions is already co-maintainer or maintainer. As per Offering to become a project owner, maintainer, or co-maintainer, they can be moved in the Drupal.org project ownership queue, 14 days after the offer was posted/moved in the project queue, if the offer has not been declined by maintainers (including the project owner).
Remember to give the project link, when the issue is moved.

As a side note, only the person who made the offer can move the issue.

@dydave:

This isn’t even a Project Ownership issue, you will need to request Infrastructure makes the change (through project_composer queue).

A sample of the type of issue you want:
https://git.drupalcode.org/project/project_composer/-/work_items/3567860

Note:
https://www.drupal.org/project/drupal/issues/3579778 is related issue and has been holding up these changes IIUC.

Your fellow co-developers that have been deprecating core modules should have more info for you.

The module is abandoned with the former module maintainer not being active anymore in the Drupal community and he has passed full maintainership over to me.

Truly, he made you a maintainer, which is what you asked in #3607179: Applying for 'Maintainer' role for the project Toolbar. (Full maintainer does not mean project owner.)

Since he has not posted a comment saying he would like to make you the new project owner, project moderators cannot make you the new project owner without following the usual procedure.
The offer is required to be posted in the project issue queue to give it visibility not only to project maintainers, but also to people who may be interested in this offer, in a way or another.

@dydave Are you still interested in taking over this namespace?

@dydave, I believe @avpaderno is asking if you wish to move from Maintainer to Owner of https://www.drupal.org/project/toolbar/.

To my knowledge @avpaderno is treating your request as a standard Drupal.org project takeover request, without understanding your initial request was to resolve https://git.drupalcode.org/project/project_composer/-/work_items/3567861.

To the best of my knowledge, you becoming owner of https://www.drupal.org/project/toolbar/ will not fix problem that you must use composer require 'drupal/toolbar-toolbar:1.x-dev@dev to install the module. To the best of my knowledge only the Infra team can change that. You becoming owner will not break that issue, it will just not help it.

Thanks for the update @dydave, @avpaderno for the follow up, and @cmlara for clearing things up. About getting the Owner-role, I checked a few other contrib modules like Redirect and Pathauto, and only "Administrator @root-admin" has the Owner-role, so getting that role seems not necessary.

I was about to update the "Remaining tasks" in the issue summary to clarify that the Composer name update is what is needed first and foremost, and the aim of this issue:

Remaining tasks

@Drupal Infra team: Update the Composer name to drupal/toolbar (currently drupal/toolbar-toolbar) in Gitlab issue #3567861: Ensure that Toolbar does not get special core treatment.

This will allow @dydave to complete the steps from How to deprecate and remove an extension > Create the contrib project with a stable release.

In light of #3576667-14: [meta] Tasks to deprecate Settings Tray where the new contrib maintainers of another Drupal core module set for deprecation with 11.5.0 release priority are nudged to "... Create the contrib project with a stable release so we can finish the deprecation?" it would nice if the Composer name could be updated to drupal/toolbar, since it is currently a blocker for this project.

@ressa On git.drupalcode.org, none of the project owners has the Owner GitLab role; that is normal, and expected, since having that GitLab role would give permissions Drupal.org does not want to give.

When one of the Drupal core modules is moved to a contributed project, the project owner (on drupal.org side) for the existing project (when there is already one which uses the namespace used by the Drupal core module) is usually changed. That happened for the Shortcut module, for example, where the project owner has been changed in #3575102: Taking over the Keyboard shortcut namespace.
dydave does not seem interested in being the project owner and asked for that thinking that being the project owner would allow him fixing the namespace issue.

Heh, let's face it @dydave, it's all very confusing with a lot of moving parts, but thanks for explaining the details, and sticking with us @avpaderno :)

Taking a helicopter view, I think @dydave should be granted the highest role, ownership and permissions possible on drupal.org and git.drupalcode.org of https://www.drupal.org/project/toolbar, since he will be the head maintainer.

Or in other words, he should eventually have the same role/permissions/etc. as if he had created the project from scratch, in my opinion.

I have added this in the "Problem/motivation" in the Issue Summary:

For the most efficient workflow, and to future proof the administration of permissions, @dydave should be granted the ownership and/or highest possible roles on drupal.org and git.drupalcode.org of https://www.drupal.org/project/toolbar, since he will be the main maintainer. In other words, he should be granted the same role/permissions/etc. as if he had created the project from scratch.

I hope this suggestion does not seem heavy handed, but the original creators and maintainers have happened by chance to now have ownership and the highest possible roles ("Maintainer") in what may become one of the most installed modules. I don't expect anything bad to happen, but control over email accounts can get lost, or otherwise get compromised. To be on the safe side, anytime an old namespace is taken over, perhaps the previous maintainers ought to be removed, as part of a policy? This could maybe deserve its own issue, to reach a decision about what to do in such situations?

And yes @dydave, I thought the same thing about this issue 😊

We can keep it open until you have the highest possible role, permission, etc. on drupal.org and git.drupalcode.org, and the Composer name has been fixed, to keep track of theses last structural tasks? I have attempted to update the remaining tasks in the Issue Summary to reflect this.

Thinking more about this, after seeing here and in other issues how much time contrib maintainers spend on taking over an old namespace in a core-to-contrib situation, wouldn't it be better if the Drupal Organisation took care of these necessary changes?

Again, it may seem heavy handed, but it's in the interest of all the Drupal users to maintain the highest security, by only vetted users having the Maintainer-role, or being owner of a core-to-contrib project. With that in mind, for situations like these, perhaps the Drupal Organisation can expropriate the name space for the common good, and hand it over to the new maintainer, who have graciously volunteered to maintain the core module as contrib module in the future?

how much time contrib maintainers spend on taking over an old namespace in a core-to-contrib situation, wouldn't it be better if the Drupal Organisation took care of these necessary changes?

D.O. already does through its project ownership process (that @avpadenro was treating this initial issue as).

Very little time is needed by a maintainer to start this process, only a few minutes, a quick message to the maintainer via the contact form and the basic outline of this issue. After that its primarily just waiting with zero interaction from the propsective owner.

For context: this entire response took about as much of my human time as I have spent on an a full project ownership application from applying to receiving ownership.

but it's in the interest of all the Drupal users to maintain the highest security, by only vetted users having the Maintainer-role, or being owner of a core-to-contrib project

You're not wrong in that assessment, IMO any developer would even consider taking over a module like this without being the owner does need to answer some questions about how they are protecting the module from attack. It does help that most of these modules in recent years have gone to contrib to die rather than be maintained. I'm not a fan of the project ownership takeover system, however I've often said if one is going to use it, they should always use it for the owner role so that they can lock down the module from others ( @avpaderno has argued that letting a new person take over owner would be less secure, and the existing owner is not a security risk).

There are already several open issues related to the adoption process that I suggest reviewing that should be taken into consideration especially since transferring these namespaces poses a risk to older sites as well (even D7). https://www.drupal.org/project/securitydrupalorg/issues/3452326 as a meta.

There is also a belief among some that Drupal Core shouldn't take over existing namespaces/reusing the core namespace and instead should create new namespaces for the modules (@drumm from Infra has raised this in Slack and I tend to agree).

There are also some issues arguing that some of these dual name faults are issues with the metadata server itself:

https://git.drupalcode.org/project/project_composer/-/work_items/3582324
https://git.drupalcode.org/project/project_composer/-/work_items/3304661

Thank you very much for your thorough and considerate reply @cmlara.

I do feel that comparing the time spent by someone such as yourself, with deep knowledge and experience about the details and processes which govern Drupal's infrastructure, to someone who is mainly a module developer and maintainer, will end with a skewed result ...

It seems to me that these take-over issues show that the task of taking over a (more or less) old or unused project is not a trivial task. It can become a drain on the new contrib maintainer, since it is not clear what needs to be done, to make it all click together.

Ideally, using Toolbar as a use case, @dydave would have requested ownership transfer of https://www.drupal.org/project/toolbar. But the method to use was not clear from the issue #3484850: [meta] Tasks to deprecate Toolbar module. In hindsight, it would have been fantastic if instead of this:

1. Find someone to maintain the contrib version of the extension.

... it said something like this:

1. Find someone to maintain the contrib version of the extension. The new maintainer should request transfer of ownership of an existing namespace, or create a new one.

And thanks for all the links to related issues, which I skimmed through, clicked further to even more issues and subscribed to them all. It was really nice to see all the different perspectives getting aired in them, and the lively discussion.

About core-to-contrib situations, as I see it there are two scenarios:

1. Take over old namespace, D.O handles everything
   If we continue with the current "take over existing contrib module"-method, then the D.O team should handle the entire process, as a natural step in the "Deprecate Drupal core module XYZ"-issue, where a "Remove original owners/maintainers from drupal.org/project/xyz, and hand it over to new core-to-contrib"-maintainer" step is added, doing these tasks:
   • Remove old owners/maintainers
   • Transfer ownership to new contrib maintainer
   • Set the correct Composer naming (i.e. fix drupal/toolbar-toolbar)

   The new contrib maintainer will get everything handed over on a silver platter, ready to use, well in advance of the actual deprecation. However, this would probably require policy changes, so getting to this scenario could take time, or never happen.

2. Use a new namespace
   It was heartening for me to learn about another view point which you and @drumm from Infra share: A new namespace should be created for a deprecated Drupal Core module. I could not find an issue with this exact proposal, it seems the closest is #3452328: Prohibit the ability to adopt a project. I support this method, since it would prevent much take-over confusion, be more secure, prevent the Composer conflicts you linked to, and even the annoying drupal/toolbar-toolbar situation. So in the case of Toolbar, @dydave would instead have created a new project, for example under https://www.drupal.org/project/toolbar-core for a totally fresh start, with him as the only project member, as project-owner on drupal.org, and with Maintainer-role on https://git.drupalcode.org/project/toolbar-core. This would also prevent old cruft, like unrelated Drupal 6 issues in the issue queue, old unrelated code in Git clones, etc.

Returning to this issue, it's great so see that you agree that @dydave ought to become owner of https://www.drupal.org/project/toolbar/.

Since dydave is not interested in becoming the new project owner, the @dydave should be granted the ownership and/or highest possible roles on drupal.org part should be removed.
Furthermore, dydave is already maintainer for this project (with which I mean he has all the permissions on this project). He already has the highest possible role he could have on the project without being the project owner.

Truly, I argued that that adding a new person as project owner would not make the project more secure. The CVE-2024-3094 incident shows exactly that, although it was perpetrated by a co-maintainer. (I am not sure GitHub uses that term in the same way we use it on drupal.org.)
Imagine what could have happened if that person was made the new project owner (which is possible, site XZ Utils is an organization project).

I have reverted the title and Issue Summary, it was premature to add it, and I should have waited for @dydave's feedback about becoming project owner.

As a side note, not even a project owner can fix the Composer namespace issue.
Truly, a project owner is merely a project maintainer for which the permissions on the project cannot be changed. In fact, on https://www.drupal.org/node/748492/maintainers, none of the checkboxes for the project owner can be deselected, contrarily to the checkboxes for the other maintainers or for the co-maintainers.

This issue was "mixing up" two different issues which essentially are not related to each other. I would keep them separated and possibly open a new issue to take over the project, in the case dydave changes idea.

Thanks for fast feedback @dydave and @avpaderno, it's great. It sounds fantastic that you are open for suggestions @dydave :)

Personally, I have become more and more convinced that in a core-to-contrib take over situation, the new maintainer (you) should by default be made project owner automatically. Since it is not the policy yet (fingers crossed that it might happen), the new maintainer has to do this themselves, through the official process.

The feedback that the project owner (@lelizondo) has left the Drupal community, makes it to me a no-brainer: Then you should definitely become project owner. Anything else would be reckless in my opinion, and I believe it would be ideal if you requested to become project owner in a fresh issue.

@avpaderno:

As a side note, not even a project owner can fix the Composer namespace issue.

Thanks for sharing, that was also my conclusion following another core-to-contrib issue Ensure that Telephone does not get special core treatment, where the new maintainer needed help from the Drupal Infra team to fix this.

@ressa:

NOTE: This is all getting significantly off topic, I might suggest it may be better to open a dedicated issue or converse in Slack.

Taking a step back on your recent questions, I would suggest that first, we need to ask why did Drupal Core feel entitled to use the Drupal\toolbar namespace in Drupal Core when a contrib module was using it?

This goes back to a few issues we have had with Core not reviewing the ecosystem when choosing module names. In the past other modules have became unusable after the core team decided to use a contrib module name in core I don't have the issue in front of me however I recently (past week?) saw arguments in favor of repeating this for a new core module.

That would be the first issue to resolve, prevent that and there is no need for a project ownership takeover request in the future, there would be no contrib owner to try and adopt from. The infra team currently blocks new core module namespaces preventing new registrations. That would allow following your more direct "D.O. handles the request" method, as the would create the new project and assign it to a maintainer. Given the need to request ownership is directly tied to decisions the core team made in the past I don't view it as fair to expedite it bypassing existing process. While we haven't seen a case yet it could have been the existing maintainers do want to use the namespace now that core is releasing it, and we shouldn't be advocating in favor of stealing from other hard working developers.

The dual name issue would still exist with that IIRC since Core would be using the name requiring infra to make infrastructure changes related to de-duplicate the name when the module is ready for production (they have intentionally NOT de-duplicated in the past to avoid a module under test not break the rest of the Drupal ecosystem).

Note: Given the title is now "Reserve the Composer namespace drupal/toolbar for this project" shouldn't this issue be closed as a duplicate of https://www.drupal.org/project/toolbar/issues/3607814 ?

https://www.drupal.org/project/toolbar/issues/3607814 is this very issue. I take the other comment meant https://git.drupalcode.org/project/project_composer/-/work_items/3567861.

@dydave Yes, please, create an offer for taking over the Toolbar namespace. I will contact the project owner.

Thanks @cmlara for detailing the challenges. And yes, I am sorry that this issue branched out into a discussion about a related subject. You are right, it should be taken elsewhere, like in a new or existing issue. So I'll just add this comment, and we can leave this issue to its purpose of keeping an eye on the Composer name issue, and see that it gets fixed.

And I do agree, ideally it should just be in situations (like this) where a Drupal 6 module has been left behind, and there are no plans to resurrect it, that owner transfer happens. Grabbing a namespace which someone has plans for would seem harsh, and a new namespace could be considered instead. But it's a grey area ... and nobody has any ill intent, things just happened to end up this way, due to a lot of external factors and historical decisions, and it's very challenging to get them all to match up.

But it's nice to hear that namespaces for new Drupal core modules are blocked in contrib, a great step to prevent future problems.

And about being a duplicate of the Composer name issue on Gitlab, I think it's nice to be able to have Toolbar-related issues here on drupal.org, to keep track of them, so the Composer name challenge is not forgotten.

@dydave: That sounds great! Thanks for links to previous ownership issues, it was interesting reading through the comments, and the heated debate taking place in some of them.

As of today when we require drupal/admin_toolbar in Drupal 11.3.x we get a dev release of the drupal/toolbar module I think because drupal/admin_toolbar depends on something called "drupal/toolbar" which is no longer drupal core's toolbar? It's an issue because we get a whitescreen error. When I run composer why it says it installed admin_toolbar needs drupal/toolbar

./composer.json has been updated
Running composer update drupal/admin_toolbar
Gathering patches for root package.
Loading composer repositories with package information
Updating dependencies                                 
Lock file operations: 2 installs, 0 updates, 0 removals
  - Locking drupal/admin_toolbar (3.6.3)
  - Locking drupal/toolbar (dev-1.x cd817d4)

At one of the dev releases for this module. I'm not sure if this module is the issue or admin toolbar or what really. But any chance of maybe unpublishing the 1.x release for this module? Maybe that'll unconfuse composer or the Drupal packaging system.

 composer why drupal/toolbar
drupal/admin_toolbar 3.5.3 requires drupal/toolbar (*) 

The website encountered an unexpected error. Try again later.

AssertionError: CSS must be nested under a category. See https://www.drupal.org/node/2274843. in assert() (line 198 of core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php).
Drupal\Core\Asset\LibraryDiscoveryParser->buildByExtension('toolbar') (Line: 87)
Drupal\Core\Asset\LibraryDiscoveryCollector->getLibraryDefinitions('toolbar') (Line: 66)
Drupal\Core\Asset\LibraryDiscoveryCollector->resolveCacheMiss('toolbar') (Line: 149)
Drupal\Core\Cache\CacheCollector->get('toolbar') (Line: 166)
Drupal\Core\Asset\LibraryDiscoveryCollector->getLibrariesByExtension('toolbar') (Line: 173)
Drupal\Core\Asset\LibraryDiscoveryCollector->getLibraryByName('toolbar', 'toolbar') (Line: 68)
Drupal\Core\Asset\LibraryDependencyResolver->doGetDependencies(Array) (Line: 41)
Drupal\Core\Asset\LibraryDependencyResolver->getLibrariesWithDependencies(Array) (Line: 132)
Drupal\Core\Asset\AssetResolver->getLibrariesToLoad(Object, 'css') (Line: 191)
Drupal\Core\Asset\AssetResolver->getCssAssets(Object, , Object) (Line: 288)
Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAssetLibraries(Object, Array) (Line: 132)
Drupal\Core\Render\HtmlResponseAttachmentsProcessor->processAttachments(Object) (Line: 97)
Drupal\big_pipe\Render\BigPipeResponseAttachmentsProcessor->processAttachments(Object) (Line: 45)
Drupal\Core\EventSubscriber\HtmlResponseSubscriber->onRespond(Object, 'kernel.response', Object) (Line: 254)
Symfony\Component\EventDispatcher\EventDispatcher::{closure:Symfony\Component\EventDispatcher\EventDispatcher::optimizeListeners():249}(Object, 'kernel.response', Object) (Line: 206)
Symfony\Component\EventDispatcher\EventDispatcher->callListeners(Array, 'kernel.response', Object) (Line: 56)
Symfony\Component\EventDispatcher\EventDispatcher->dispatch(Object, 'kernel.response') (Line: 218)
Symfony\Component\HttpKernel\HttpKernel->filterResponse(Object, Object, 1) (Line: 206)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle(Object, 1, 1) (Line: 118)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 92)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 53)
Asm89\Stack\Cors->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 53)
Drupal\Core\StackMiddleware\AjaxPageState->handle(Object, 1, 1) (Line: 54)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 745)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I can create a separate issue if you prefer but since this was open about the composer namespace I posted it here.

Same per #35, incredibly derailing.

You can however workaround it by telling Composer that your project already has it:

 "replace": {                                                                                                                                                                                            
   "drupal/toolbar": "*"                                                                                                                                                                               
 },  

But be careful not to let it come along for the next upgrade.

Also, #3630983: Cannot update to latest 11.3.x or 10.6.x core version due to impossible drupal/toolbar dependency

We are having the problem described in #35 and the fix in #36 is working for us.