Objective

  1. Some major disruption patches are scheduled directly before the first beta release.

  2. This issue collects the planned operations (and points out additional candidates).

Planned Disruptions

  1. #2247991: [May 27] Move all module code from …/lib/Drupal/… to …/src/… for PSR-4

  2. Fix service ID names to be (1) properly namespaced and (2) use proper . ↔ _ delimiters (Container::camelize()).

    #2155909-3: Standardize controller service names and hierarchy

  3. #2191303: Ensure the service definition files are alphabetical in order

  4. #2158871: [Policy, no patch] Clearly denote when @deprecated code is slated to be removed

Candidates

  1. #7269: [meta] Add .php extension to PHP files

    Old → New
    foo.module → foo.php
    foo.install → foo.install.php
    foo.inc → foo.inc.php
    bar.theme → bar.php
    baz.profile → baz.php

  2. #2135291: [Policy, no patch] PHP 5.4 short array syntax coding standards for Drupal 8

    Old → New
    array("foo", "bar", "baz") → ["foo", "bar", "baz"]

Comments

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Issue summary: View changes
sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Issue summary: View changes

#2219393: Menu Local Tasks should be sorted by alphabet if there is no weight set was a mistake/misinterpretation and is irrelevant here; hence removing it from the summary.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

I think a lot of these could be done during the standard "disruptive patch window" after any alpha release. We're only holding those like PSR-4 (and .php would qualify if we really want to do that) because they will literally break almost every patch in the queue. I don't think that's true for e.g. service IDs, YAML ordering, etc.

Otherwise, just tag 'em as "Will cause commit conflicts" (or whatever the tag is) and they can go in either during a disruptive patch window, or whenever else we're out of criticals/majors to commit.

drifter’s picture

drifter commented
Issue summary: View changes

Adding #2135291: [Policy, no patch] PHP 5.4 short array syntax coding standards for Drupal 8 as a very iffy candidate, there is no consensus, but a major disruption window would be the only chance to do it globally.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

@webchick: Hm. That makes sense.

The reason for why I also listed the "re-order YAML files alphabetically" issue(s) here is that we obviously don't want a patch that is re-rolled after that change to re-introduce definitions in non-alphabetical order ;)

Hence if part of a larger disruption window, we could possibly limit the re-roll communication to "Here's how: (1) PSR-4 (2) YAML: alphabetical (3) ..."

But I could be wrong. Perhaps those YAML standard changes could even be covered by a unit test that simply parses all .yml files + asserts that definitions are alphabetical + stuff...

xjm’s picture

xjm
she/her
Primary language English
commented

I can write one shell script that will download and reroll every NR patch in the queue for PSR-4 (using the script that @donquixote has already provided); not so much if we are lumping in N non-essential, non-beta-blocking tasks with it. So -1 from me. :)

mallezie’s picture

mallezie
Primary language Dutch
Location Loenhout
commented

Combining those disruptive patches makes it indeed neerly impossible to automate the rerollling.
But what if we schedule them the day before the drupalcon austin contribution sprint. That solves the problem 'find an issue you're able to work on' for all 200+ new contributers attending the sprint.
I remember the /core move issue, which caused the reroll need for every single patch, and that was actually done very fast with the community.
Just dropping the idea here.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

It's a fair idea, but I'd personally rather new eager contributors be working on something more valuable as their first contribution than re-rolling busy work. :) However definitely could do as a fallback.

xjm’s picture

xjm
she/her
Primary language English
commented

It's not strategically sound to break every patch in the queue right before DrupalCon Austin. Rerolling for the beta-blocker-patch-breaker is a task that a computer can do, so we should let a computer do it. There will be plenty of other rerolls out there. :)

xjm’s picture

xjm
she/her
Primary language English
commented

#2247991: [May 27] Move all module code from …/lib/Drupal/… to …/src/… for PSR-4 is now planned to go in on May 27, separately from other changes proposed here.

damienmckenna’s picture

damienmckenna
Location TN, USA
commented

Is this an RC target now?

xjm’s picture

xjm
she/her
Primary language English
commented
Status: Active » Closed (fixed)
Issue tags: -beta target

Ah nope, I think it's just fixed. :)