[suggestion] Distinguish public bins and internal ones

[stof]

There are 2 different kinds of executables files in a repository:

• public executables, which are part of the feature set of the package (and which are geenrally referenced in the composer.json to be exposed in vendor/bin)
• internal executable files, used to run CI tasks for instance, which are targetted only at contributors (or even only at maintainers sometimes)

I think it would make sense to distinguish the 2 kinds of executables when defining the package structure (especially for packages needing both of them, and wanting to keep them separate).

It may be worth investigating it. What do you think ?

[stof]

Here are a bunch of folders found in the Other section, which seem related to internal tools (I haven't checked manuall the packages to confirm, I just looked at the 05-dirs.txt file):

• travis
• ci
• build-tools
• ant-scripts
• gulp-tasks
• webpack
• travisci
• travis-ci

[pmjones]

/me nods

Note that the standard does not prohibit those kinds of files and directories; it just doesn't explicitly include them. They're also tool-specific, and the standard should probably leave tool-specific requirements to those specific tools.

Do you get where I'm coming from here?

[pmjones]

@stof If you've no further comments on this issue, I'm leaning toward closing it as "overly tool-specific." Let me know!

[stof]

then it may be a matter of expliciting what the standards means when talking about executables, so that it is clear for everyone that these are about exported ones only, and that internal tools are free to be elsewhere while staying complient.

[pmjones]

Sure -- if you can think of language to use for that, I'll look it over.