24 Nov
2011
24 Nov
'11
3:57 p.m.
On Thu, Nov 24, 2011 at 10:20 AM, Paul Poulain <paul.poulain@biblibre.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Le 24/11/2011 13:22, Robin Sheat a écrit : >> Op 25-11-11 00:49, Ian Walls schreef: >>> I do like the idea of hashes... but looking at it, we'd >>> essentially be mimicking the data structure we already have with >>> Git commits. Plus, readability goes down. >> >> Is readability an issue here? I was thinking a process like: >> >> 1) on each page (and this'll improve heaps when we get persistence >> :) the list of patch files is build, concated, CRCed. > There are 2 strong opinions here: > * upgrade is a process you know you're doing, so no need to check on > every page > * upgrade is safer if you check often if you're uptodate: the computer > must fix human mistakes. > > Maybe a middle solution would be to have do a check on the login page > only (or on mainpage.pl ?). As it's mandatory to log-in on the staff > interface, that seems fair. I tend to agree with Paul here. Checking at login for up-to-date deps seems to be the best way to go, introducing the least overall latency from the user's prospective. > >> Perhaps a quick hash/CRC of the filenames of the patches that have >> been applied? Should be quick to generated and test, and will tell >> us immediately if we need to run again. > > In a few months, we will have 40 different files. And hashing/CRCing > 40 files is not negligible. We want to improve perfs, so I think it's > a wrong idea. On the login page though, I think it's something we can > afford. Of course, we could always relegate the hashing/CRCing *and* update check to a cron job which runs once very <a-time-with-low-system-load> and gives an appropriate status indication on mainpage.pl. Kind Regards, Chris