I think the days of running this stuff yourselves are disappearing… I think many OSS projects rely on SAS for this now - outsource it. We already do Travis - and maybe can leverage that more (but it seems a bit cumbersome) - OR there are fuller service solutions like what AWS does, or GitLab CI - but they will take time to migrate to.
Tim > On 23 Nov 2017, at 12:18, Christophe Demarey <[email protected]> > wrote: > >> >> Le 23 nov. 2017 à 12:34, Norbert Hartl <[email protected]> a écrit : >> >> >> >>> Am 23.11.2017 um 11:39 schrieb Christophe Demarey >>> <[email protected]>: >>> >>> Hi Norbert, >>> >>> I understand your point of view that others probably share. >>> I also agree the situation is very bad: Inria took too much time to >>> investigate the problem and now, renater also … >>> The question is: would it be really better outside Inria? Maybe ... maybe >>> not … >> >> Maybe that is the point. It is not a question if it works better outside >> because it will. The problem we have is so serious that it will be hard to >> find elsewhere. I can only repeat: It is not the download that fails which >> TCP wise means that exactly the thing is downloaded that inria offered. So >> something below the web server is broken and most probably they have a >> corrupt storage solution meaning only if you give it broken to the web >> server the broken thing can be transported in a sane manner. > > I’m not confident with the diagnostic. > I never encountered this problem and we got no such feedback from people in > the team. So it is really strange. Indeed, if CRC is worn it does not mean > slowness but corrupted data … I do not see any reason that we do have CRC > from outside Inria but not inside. > If no solution is found today or tomorrow, we will probably see to host a > solution outside Inria.
