Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
According to doxygen the @file should appear first in file and not after the use statements as in bootstrap.inc
patch coming
Comment | File | Size | Author |
---|---|---|---|
#1 | 2242585 - docchanges - 1.patch | 593 bytes | filijonka |
Comments
Comment #1
filijonka CreditAttribution: filijonka commentedComment #2
jhodgdonThanks! Committed to 8.x.
Comment #4
sunFWIW, this patch + #2237767: use statements before doc file caused needless re-rolls for 10+ RTBC patches (just counting my own) that are modernizing/converting the legacy code in these files.
It's too late now, but yeah, the
use
statements are in between the phpDoc that has been moved, causing a diff context conflict for many patches that are adding/touching those use statements.Comment #5
jhodgdonSorry. I did check the "avoid commit conflicts" queue, which was empty. The patch touched only one file and I didn't realize it would have such wide repercussions, so I didn't think it qualified as a "disruptive" patch. It sounds like those 10+ patches will all most likely conflict with each other anyway?
Comment #6
filijonka CreditAttribution: filijonka commentedHi
first of all; I do apologize for the problems caused by #2237767 (and most likely this too), it was issued by me and I failed in making people to understand that it shouldn't be commited before parent issue which I had included in the issue. Hopefully someone with better knowledge will teach me how to make it properly.
Secondly: if 10+ patches is affected by this it must means they affect eachother; If they aren't already they should defintly not be worked on individually but structured up in a way so they are solved top to bottom and not seperated.
Comment #7
sunThe ship has sailed, so it's OK. :-)
Just to clarify on the aspect of the other patches: (1) They're all different and not related to each other, so there is no hierarchy involved. (2) They're RTBC and waiting for commits. (3) It is true that some of them might have to be re-rolled after another one lands, but yeah, that's "expected breakage" of making substantial progress in modernizing our awkward legacy code, whereas a breakage caused by a nitpicky documentation fix like this doesn't contribute to that progress and only causes unnecessary delays instead...
But yeah, that's an epic topic on its own. The situation would be drastically improved already if we wouldn't operate on patches, but merging branches instead (because git is smart enough to figure out diff context conflicts as long as the same line is not changed)... but at this point that's a pipe-dream.
Now that we're entering the very active (+ usually heated) phase towards a beta release, it might make sense to temporarily slow down documentation patches again, but yes, I'm fully aware that that is a debatable approach, too... :-)