On 2 September 2013 13:39, Dr. Trigon dr.trigon@surfeu.ch wrote:

...

Sorry for the inconvenience - but at least we're not going to switch repositories again ;-)

Oooho - are you a oracle? Or are you comming from future? ;)))

I'm fairly certain we are not switching the externals (other than maybe adding one) unless we switch to something non-git, so I think we won't run into this issue again.

By the way - why do we exactly need this "own" httplib2 repo? Can you explain this to me?

Several reasons. The httplib2 repository we used was already a third-party one - httplib2 uses hg. Thus, some unknown third party could change/add/etc code, which is bad for several reasons: they could add malicious code or malicious SSL certificates, for example.

Secondly, having our own repository means it's easy to maintain patches - we track the original repository in a branch, so changes can be merged back to our master branch. For instance, we have a patch to add a more reasonable SSL certificate list and one that makes it possible to actually import the python2 httplib2.

Could we solve that in the same manner than externals in compat (e.g. with a patch)?

What advantage would that have? Now we have a clear source repository, with easily tracable commits. This is much harder with patches. Oh, and we don't need patch.exe.

Who maintains this httplib2 such that it gets merged with updates from its original source??

Anyone with +2 could do this, but there is a script on tool labs that can be run to do this automatically. It's not really an issue as the rate of development in httplib2 is fairly limited (last commit was in march). Basically: we have a branch 'origin' that can be pushed to without going through Gerrit (that would be annoying if there are multiple new commits). That branch directly follows the origin master branch, and we would merge from that branch to master - which would pass through Gerrit.

Merlijn