Wow, okay. A lot to address here. The primary instigator of this migrating of user repositories off to external services came from when we were (and still are) crunched for disk space after restructuring our Mercurial infrastructure to use local disks.
We did this for several reasons: * An internal quote for remaining on NFS for hosting (even with just the 300GB used) would have cost us a low six-digit figure * Mercurial devs originally said that some of our clone corruption problems may have come from NFS faking transaction atomicity (see bug 974094) * This approach did not allow us to expand to multiple datacenters (especially cost-effectively) The 300GB limit in this case comes from repurposing the old hgweb-serving hosts to use their local disks instead of an NFS mount. These hosts came with two 300GB disks paired in RAID-1 configuration. If this is simply a matter of disk space we can agree to reconfigure these hosts as RAID-0 instead. The reliability should never matter since these are simply clones of the original canonical source. This is what I was spending a considerable amount of time doing. Additionally I've been setting up a host named hg-archive.mozilla.org with a lower SLA to shelve repositories that have not been touched in many many years. Deleting this old code from hg.m.o, even if it's available elsewhere if an unpopular thing to do, so it's unsurprising I didn't receive much buy-in when I proposed it. I think the real reason for this evaluation and push into other services is that it is perceived that the user repositories don't add much value, especially when you consider all of the features that could be happening from them such as triggering CI jobs based on these, and self-service collaboration. Yes, the user-repo deletion is a feature and it is currently broken. It's been a corner-case of the migration to local disk, and a fix has yet to be coded up. Please ping me if you're trying to remove a repository until I can fix this. As for project repositories, these should totally be self-service and automated. The human-as-an-API approach to these means it is often too much work for developers to request one for simple or short collaborative projects. Sadly for Mercurial development at Mozilla it is just me for the development work. If, as gps said, people are willing to help out with some of the development I would be happy to test and deploy whatever changes are proposed. The code for the infrastructure is available at https://github.com/bkero/puppet-module-hg. Feel free to spin up a VM and try to improve things. Ben _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
