Rockbox General > Rockbox General Discussion
I think the daily builds should be less dishonest about changes
Jason Arthur Taylor:
Right now a compression package is apparently given flags to create daily [device][today'sdate].zip builds which are downloadable here: http://build.rockbox.org/ . This date is today even if the last binary change was a long time ago. This obfuscates if there was any change, and is bad because this information is useful if you are debugging and because it wastes bandwidth. For example, I wrote up a few bugs this week, and others do as well, but it is harder to know if anyone might have made changes to fix any of these many bugs.
But, it is worse. A flag given to the compression program apparently gives inside files in the daily build the compression date, even if the files inside are really old, and the same as before. This obfuscates if there was a change. I hereby propose not obfuscating if there was a binary change. The date of the files should be the date of each was last changed (i.e., modified), and the overall file name should not be set to today's date. Rather, it should be set to the newest modification date of the inside files.
The "-f" "freshen: only changed files" zip option is what does this automatically, although the purpose of that option is largely to reduce cpu usage during the packaging of the compiled files.
I assume this proposal will not be allowed, as development is rather dead here, but I wanted to put this out there.
pamaury:
Hi,
The daily builds are rebuilt on each commit and the commit log is publicily available (https://www.rockbox.org/recent.shtml#code and https://git.rockbox.org/?p=rockbox.git;a=summary) so I am not sure what you mean by binary change. Some commits may not affect a particular device and thus produce exactly the same binary but given than we have over 50 builds, there is no way we can track this by hand. I don't see what is dishonest about this.
Jason Arthur Taylor:
First, the default is usually to NOT alter the file modification dates but to retain them. So I think there was some effort to obfuscate that. But whatever.
"there is no way we can track this [changes] by hand"
I think that is wrong in two ways. First you are imply that I'm saying it should be done by hand. I'm not. Where did I say you should do anything by hand?
Second, there are an infinite number of ways to have accurate last-modified modification times, and many are very easy.
For example, if you don't want to do this via git, you can probably just use something like the -f option on zip or whatever the compression routine is and then none of the other zip files would have changed. You could also just write a line to make a file renamer script.
So for example, the last commit changed only the files for the nwz-e470. Actually it was one line of code. So probably one file. Then one downloadable would have a new date and only one file in that downloadable would have the commit date, since the -f option would only modify one file in that one zip. Then, the date checker that puts the modification date in the file name would only rename one file. Done.
I sometimes think that you mods spend more time here arguing that one cannot or should not improve rockbox than it would take to just do it.
saratoga:
^^ we do actually have daily builds, although no one actually uses them :
https://www.rockbox.org/dl.cgi?bin=sansac200
I think he is suggesting changing the script to only generate a daily build on days in which there is a commit.
saratoga:
--- Quote from: Jason Arthur Taylor on November 18, 2016, 04:27:47 PM ---
So for example, the last commit changed only the files for the nwz-e470. Actually it was one line of code. So probably one file. Then one downloadable would have a new date and only one file in that downloadable would have the commit date, since the -f option would only modify one file in that one zip. Then, the date checker that puts the modification date in the file name would only rename one file. Done.
--- End quote ---
Can you suggest an algorithm for determining what builds a given line of c code will alter? This is actually a pretty hard thing to do correctly.
Navigation
[0] Message Index
[#] Next page
Go to full version