According to doxygen the @file should appear first in file and not after the use statements as in bootstrap.inc

patch coming

CommentFileSizeAuthor
#1 2242585 - docchanges - 1.patch593 bytesfilijonka
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

filijonka’s picture

FileSize
593 bytes
jhodgdon’s picture

Status: Needs review » Fixed

Thanks! Committed to 8.x.

  • Commit 7f1f993 on 8.x by jhodgdon:
    Issue #2242585 by filijonka: Fix file docs in bootstrap.inc
    
sun’s picture

FWIW, 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.

jhodgdon’s picture

Sorry. 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?

filijonka’s picture

Hi

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.

sun’s picture

The 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... :-)

Status: Fixed » Closed (fixed)

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