On 2 September 2013 13:39, Dr. Trigon <dr.trigon(a)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