Do lsm files provide us any value or serve any purpose?
Should we continue maintaining them or purge them from the source tree?
http://lsm.execpc.com/LSM.README http://en.wikipedia.org/wiki/Linux_Software_Map
Darrell
On 05/22/2012 02:23 PM, Darrell Anderson wrote:
Do lsm files provide us any value or serve any purpose?
Should we continue maintaining them or purge them from the source tree?
http://lsm.execpc.com/LSM.README http://en.wikipedia.org/wiki/Linux_Software_Map
Darrell
This may be a distro dependent thing. Arch doesn't use them at all, but IIRC, the deb system made use of them somehow. Dunno - somebody using one of the distros that uses them will have to help us out here.
Do lsm files provide us any value or serve any purpose?
Should we continue maintaining them or purge them from the source tree?
http://lsm.execpc.com/LSM.README http://en.wikipedia.org/wiki/Linux_Software_Map
This may be a distro dependent thing. Arch doesn't use them at all, but IIRC, the deb system made use of them somehow. Dunno - somebody using one of the distros that uses them will have to help us out here.
I am willing to do the grunt work to update these files.
Yet after updating various branding issues, a remaining challenge is with each release the files all need updating again. Anything like that is best suited for the computer with scripts. Two fields should be updated with each release:
Version Entered-date
Both fields should be updated to the release version/date. I prefer to see something built into the build process, such that even GIT builds reflect correct information.
Another challenge is whether these files are still maintained and whether we should resubmit our updated files to the lsm database.
Tim,
What is a good way to automate this? Comments?
Darrell
Tim,
What is a good way to automate this? Comments?
Darrell
One way to automate this would be to have a script that is run just before each release that finds/replaces placeholder strings in each lsm file with the current information.
Of more concern is the fact that many of the lsm files are completely out of date or just plain wrong, referencing KDE in many cases.
Tim
What is a good way to automate this? Comments?
One way to automate this would be to have a script that is run just before each release that finds/replaces placeholder strings in each lsm file with the current information.
Is this something we can automate as part of the automake/cmake build process? Or is this something we relegate to the etherpad release check list?
Of more concern is the fact that many of the lsm files are completely out of date or just plain wrong, referencing KDE in many cases.
Yes, that is how I got started on this. I am about to embark on another branding cleanup exercise. Yet there is a method to the lsm madness and we should not blindly search and replace. There are fields for recognizing the original authors, for example, and they should be retained or updated as necessary.
I found 104 lsm files in the GIT source tree. Not bad, and many are part of the same module, which means only one patch each.
Darrell
-
Darrell Anderson -
David C. Rankin -
Timothy Pearson