Change Details

It would be handy to somehow build metadata of from-git builds - blocks of each contributing source -- where they were put in the source tree -- which VCS type they are from -- VCS url -- VCS branch (if applicable?) -- what the VCS revision was (git hash) Putting a file into the actual source tarball would be tricky to do architecturally. Putting it in debian/ might be a possibility though.

It would be handy to somehow build metadata of from-git builds - blocks of each contributing source -- where they were put in the source tree -- which VCS type they are from -- VCS url -- VCS branch (if applicable?) -- what the VCS revision was (git hash) Putting a file into the actual source tarball would be tricky to do architecturally. Putting it in debian/ might be a possibility though. After some musing and discussion this is the proposed course of action: - ECM to get a new module which encapsulates retrieval of git metadata -- iff git is installed and .git is present the data is fetched through the git cli -- else if `.scm_metadata` (or somesuch) is present the data is read from there. this specifically allows a build/distribution scope to resolve the metadata ahead of time and not have to shovel around git. this would also allow tarballs to contain this sort of information, at this time it's unclear if there is a use case for it and it is worth the added complexity of detaching a git tag with the metadata (IOW the file would need to be in the tag, but not actually the running branch) The module allows developers to pick up the git sha and embed it in the binary somewhere such that it may be used for debugging / bug reporting. For the purposes of simplicity we'd ignore submodules and the like for the time being. Ultimately source composition through submodules (or in terms of deb packages the packaging+source) are not all that useful in the grand scheme of things. Knowing that a given build was made from git sha 1123abc however is invaluable information when dealing with bug reports on development versions. With a standardized way of handling data retrieval we are then also able to more conveniently consume the data. Notably KAboutData could be extended to automatically pick up the new metadata. All KDE Software would then get git metadata injected into its about data without any additional work.

It would be handy to somehow build metadata of from-git builds - blocks of each contributing source -- where they were put in the source tree -- which VCS type they are from -- VCS url -- VCS branch (if applicable?) -- what the VCS revision was (git hash) Putting a file into the actual source tarball would be tricky to do architecturally. Putting it in debian/ might be a possibility though. After some musing and discussion this is the proposed course of action: - ECM to get a new module which encapsulates retrieval of git metadata -- iff git is installed and .git is present the data is fetched through the git cli -- else if `.scm_metadata` (or somesuch) is present the data is read from there. this specifically allows a build/distribution scope to resolve the metadata ahead of time and not have to shovel around git. this would also allow tarballs to contain this sort of information, at this time it's unclear if there is a use case for it and it is worth the added complexity of detaching a git tag with the metadata (IOW the file would need to be in the tag, but not actually the running branch) The module allows developers to pick up the git sha and embed it in the binary somewhere such that it may be used for debugging / bug reporting. For the purposes of simplicity we'd ignore submodules and the like for the time being. Ultimately source composition through submodules (or in terms of deb packages the packaging+source) are not all that useful in the grand scheme of things. Knowing that a given build was made from git sha 1123abc however is invaluable information when dealing with bug reports on development versions. With a standardized way of handling data retrieval we are then also able to more conveniently consume the data. Notably KAboutData could be extended to automatically pick up the new metadata. All KDE Software would then get git metadata injected into its about data without any additional work.