[TIP] [unittest2] Issues DB migrated off of google code.

Robert Collins robertc at robertcollins.net
Wed Mar 18 21:35:39 PDT 2015

On 19 March 2015 at 14:52, Ben Finney <ben+python at benfinney.id.au> wrote:
> Robert Collins <robertc at robertcollins.net> writes:
>> With Google code shutting down, we needed a new home for the issue tracker.
>> https://github.com/testing-cabal/unittest-ext
> Can we put it on GitLab, which is federated, instead of yet another
> proprietary service?


There are a bunch of reasons.

Firstly, Michael and I, the current two maintainers of unittest2 both
already have Github accounts. I don't know about Michael but I don't
have a gitlab account, and I won't get one until forced too - simply
because new doesn't imply better and I've way too many things that
matter to poke at than migrating projects to Yet Another Hosting
Service. If I was going to advocate migrating anywhere it would be
back to LP, since the bug tracking there is IMO superior to Githubs,
and that can be discussed once it's git support is online.

Secondly, the source code is irrelevant in that repo - as it says in
the description. The source for unittest2 is on hg.python.org.
GitLab's issue tracker isn't federated. (Few are).

Thirdly, GitLab is no more or less federated than Github AFAICT -
certainly googling found
which shows its not federated today. It certainly appears that you
need to push to GitLab to have a pull request handled there. Or thats
stale and their docs need updating.... but even if its stale docs - an
issue in GitHub can easily refer to another arbitrary url and I can
pull from there, if the code for unittest2 was in git etc.

Fourthly, there's absolutely nothing morally wrong with utilising
gratis resources to host development of F/LOSS projects. Contributions
are contributions, and as long as things that matter - like control,
transparency, code accessibility etc are not compromised, I don't see
an issue at all. Github are happy to pay for server space for
publically accessible repositories, we should be happy to use that.
They provide a high quality (not perfect but what is) service, and
while something where the basic infra is open would allow us in
principle to submit PR's to change it - there's a strong tendency to
forget that any company-sponsored project of that nature - e.g. today
thats Launchpad, GitLab and SourceForge - all have some particular
goals and visions and they won't accept every PR ever, only the ones
that make sense to them. So you really need to get to the next stage -
open governance& open product design - to have something which is
directly end user modifiable (or something you run locally - and then
you're paying for sysadmin time, one way or another - and thats
expensive!) Debian, for instance, heavily depends on contributions of
hardware to run its systems on, and thats as valid a contribution as
compute cycles such as OpenStacks development infrastructure depends
on, or the application layer contributions that projects like
unittest2 depend on (project forge hosting).

Fourthly GitLab *service* is absolutely proprietary. We don't know
what code is actually running on the gitlab.com services - whether its
the CE edition, or enterprise, or some unholy combination. Its only by
running the CE edition ourselves that it wouldn't be proprietary, and
I'm don't have the time to volunteer to do that. If it was a
non-profit organisation running CE on a server somewhere, that would
be different, since they are much more auditable. That is, if you care
about the proprietariness or not of the service, which in this case I
don't :)


Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud

More information about the testing-in-python mailing list