Return to Question

The Gates are open for Drupal.org Code Contributions, so now you can promote sandbox projects to full projects with releases if you have accepted the git terms of service.

But what is the actual use of the legacy Project Application issue queue (which is now named Drupal.org security advisory coverage applications?

I post this question because I have a module in revision there a some users that says that the code is OK, they made some suggestions and I made the changes until the last comment that says:

When a node Add is disabled, you should at minimum highlight which content type won't accept new content (in fact providing node edition instead).

This is a UX change that don't affect the security and don't affect the module functionalities. The module works fine without this. And now the module is promoted to full project this is an impediment to approve the module in the new Drupal.org security advisory coverage applications queue?

What are now the procedures to go ahead wit the revisions?

^{Disclosure: I'm the maintainer of the module OnlyOne. I'm not looking for promotion, I just want to know how to finish the review process.}

The Gates are open for Drupal.org Code Contributions, so now you can promote sandbox projects to full projects with releases if you have accepted the git terms of service.

But what is the actual use of the legacy Project Application issue queue (which is now named Drupal.org security advisory coverage applications?

I post this question because I have a module in revision there a some users that says that the code is OK, they made some suggestions and I made the changes until the last comment that says:

When a node Add is disabled, you should at minimum highlight which content type won't accept new content (in fact providing node edition instead).

This is a UX change that don't affect the security and don't affect the module functionalities. The module works fine without this. And now the module is promoted to full project this is an impediment to approve the module in the new Drupal.org security advisory coverage applications queue?

What are now the procedures to go ahead wit the revisions?

^{Disclosure: I'm the maintainer of the module Only One. I'm not looking for promotion, I just want to know how to finish the review process.}

Te Gates are open for Drupal.org Code Contributions, so now you can promote sandbox projects to full projects with releases if you have accepted the git terms of service.

But what is the actual use of the legacy Project Application issue queue (which is now named Drupal.org security advisory coverage applications?

I post this question because I have a module in revision there a some users that says that the code is OK, they made some suggestions and I made the changes until the last comment that says:

When a node Add is disabled, you should at minimum highlight which content type won't accept new content (in fact providing node edition instead).

This is a UX change that don't affect the security and don't affect the module functionalities. The module works fine without this. And now the module is promoted to full project this is an impediment to approve the module in the new Drupal.org security advisory coverage applications queue?

What are now the procedures to go ahead wit the revisions?

^{Disclosure: I'm the maintainer of the module OnlyOne. I'm not looking for promotion, I just want to know how to finish the review process.}

The Gates are open for Drupal.org Code Contributions, so now you can promote sandbox projects to full projects with releases if you have accepted the git terms of service.

But what is the actual use of the legacy Project Application issue queue (which is now named Drupal.org security advisory coverage applications?

I post this question because I have a module in revision there a some users that says that the code is OK, they made some suggestions and I made the changes until the last comment that says:

When a node Add is disabled, you should at minimum highlight which content type won't accept new content (in fact providing node edition instead).

This is a UX change that don't affect the security and don't affect the module functionalities. The module works fine without this. And now the module is promoted to full project this is an impediment to approve the module in the new Drupal.org security advisory coverage applications queue?

What are now the procedures to go ahead wit the revisions?

^{Disclosure: I'm the maintainer of the module OnlyOne. I'm not looking for promotion, I just want to know how to finish the review process.}

Now that the Gates are open for Drupal.org Code Contributions and you can promote sandbox projects to full projects with releases if you has accepted the git terms of service. What are the really use of the ancient Project Application issue queue that is now named Drupal.org security advisory coverage applications?

I post this question because I have a module in revision there a some users that says that the code is ok, they made some suggestions and I made the changes until the last comment that says:

When a node Add is disabled, you should at minimum highlight which content type won't accept new content (in fact providing node edition instead).

This is a UX change that don't affect the security and don't affect the module functionalities. The module works fine without this. And now the module is promoted to full project this is an impediment to aprove the module in the new Drupal.org security advisory coverage applications queue?

What are now the procedures to go ahead wit the revisions?

^{Disclosure: I'm the maintainer of the module OnlyOne. I'm not looking for promotion, I just want to know how to finish the review process.}

Te Gates are open for Drupal.org Code Contributions, so now you can promote sandbox projects to full projects with releases if you have accepted the git terms of service.

But what is the actual use of the legacy Project Application issue queue (which is now named Drupal.org security advisory coverage applications?

I post this question because I have a module in revision there a some users that says that the code is OK, they made some suggestions and I made the changes until the last comment that says:

When a node Add is disabled, you should at minimum highlight which content type won't accept new content (in fact providing node edition instead).

This is a UX change that don't affect the security and don't affect the module functionalities. The module works fine without this. And now the module is promoted to full project this is an impediment to approve the module in the new Drupal.org security advisory coverage applications queue?

What are now the procedures to go ahead wit the revisions?

^{Disclosure: I'm the maintainer of the module OnlyOne. I'm not looking for promotion, I just want to know how to finish the review process.}