Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sun’s picture

drupal8.dep-tags.0.patch queued for re-testing.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

This is pretty straightforward.

webchick’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs change record

We seem to be missing a change record about this? https://drupal.org/list-changes/published?keywords_description=drupal_im...

sun’s picture

Status: Needs work » Reviewed & tested by the community
Issue tags: -Needs change record

The change notice should have been created for #2003568: Convert tags,attributes, diff and url validation unit tests to phpunit already...

Change notice: https://drupal.org/node/2212099

catch’s picture

Status: Reviewed & tested by the community » Needs work

Please split this into two issues/patches - that reduces the chance of cross-commits with other patches in the queue. And if they do cross-commit, only the 'removal' patch needs to be reverted + re-rolled instead of the whole thing.

sun’s picture

Status: Needs work » Needs review

@catch: Not sure I'm able to follow in this case — as visible in this patch, those tag explosion/implosion utility functions are used by 4 core modules only, they are barely used in contrib, and I don't think the amount of consumers is going to radically change anytime soon...?

Therefore, splitting this patch into conversions-only vs. removal-only doesn't make sense to me. If the conversions happen to cause conflicts, then it makes no difference whether the full patch or just the conversions are reverted.

ianthomas_uk’s picture

@sun I think it's more about having a consistent policy so people know what to do when they are creating patches. I agree this patch is simple so is unlikely to cause problems.

Here's a version that keeps the functions themselves.

sun’s picture

Status: Needs review » Reviewed & tested by the community

Thanks! I still disagree with the split and would recommend to commit #0, but not my decision.

catch’s picture

Status: Reviewed & tested by the community » Fixed

@sun I think it's more about having a consistent policy so people know what to do when they are creating patches.

Yes that's really it. If it's a not-really-api function in an optional module then it's less of an issue, but it takes a lot longer to discuss each individual case how much the function is used than just to roll the extra very simple patch, and HEAD getting broken from cross-commits is not a theoretical issue, has happened several times.

Committed/pushed to 8.x, thanks!

sun’s picture

Status: Fixed » Needs review
FileSize
917 bytes

Nothing broke or conflicted, so here's the second part again.

ianthomas_uk’s picture

Status: Needs review » Reviewed & tested by the community

Comfirmed there are no remaining calls or references to these functions in core. This is already fully covered by a change record: https://drupal.org/node/2212099

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed to 8.x. Thanks!

  • Commit 672ac3f on 8.x by webchick:
    Issue #2204143 by sun, ianthomas_uk: Remove deprecated...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.