>*User Repos* >TLDR: I would like to make user repos read-only by April 30th. We should >archive them by May 31st.
As mentioned, too fast. >Time spent operating user repositories could be spent reducing our >end-to-end continuous integration cycles. If we're spending any significant time or money running these, let's solve that instead - I really don't think much time or money *should* be needed to run low-priority repos with non-mission-critical availability requirements. >These do not seem like >mission-critical repos, seems like developers would be better off hosting >these on bitbucket or github. Using a 3rd-party host has obvious benefits >for collaboration & self-service that our existing system will never meet. Some issues I raised privately before this post went public, but I don't see addressed here: * Security implications Any dev who works on security bugs (and most do at one point or another, or might) who puts a patch queue on an external host is proxying to that host all security assurances. This makes that external hosting a tempting target for people who want to find 0-days. I'd like to say this is an excessive amount of paranoia, but given both the lucrative market for 0-days and NSA's interest in 0-days (and ability to compel or buy silence from companies or employees at companies), I no longer think this is excessive. :-( I'm less worried about silent changes to the repos to slip stuff in (though it's possible) than someone silently cataloging possible 0-day targets in repos associated with devs, especially ones marked as referring to bugs that aren't visible. * cleanup Per previous comments, it wasn't aware I could get rid of a user repo in any easy way (and it may actually be busted right now). Likely 50% of what's in user repos (or more) is dusty stuff that people could simply delete. I have one large and one medium repo I need to keep and some patch queues (most of which are deletable now). Anything else can go. But there's no trivial way for me to see what I have and delete them. A simple 1/month nag mail listing your private repos and their sizes would help. * side note: my repo names are tied to the email address in my key. It's dead. I'd change my key to the new permanent email address, but I worry I might lose all my user repos. * Backup/data-integrity/availability Already mentioned was availability guarantees or lack thereof. We'd need to back up these external repos (and find them somehow). Taras commented to me that we use expensive storage solutions for user repos (similar to primary repos). IMHO that's not needed: User repos needs lower SLA gear I'd imagine - redundancy, but could probably just live in a RAID-1+1 array with consumer drives with very high reliability (two RAID-1 arrays in a RAID-1 configuration) - you'd need a 3-drive simultaneous failure to have to fall back on backups. Hell, a single RAID-1 is probably good enough, so long as it's backed up frequently. Taras mentioned that this is time not spent doing other things; my response: I imagine you can buy a RAID drive and just drop it in in place of $$$-expensive-drive. But yes this requires some thought/planning/etc time for them; while moving to random-VCS-storage requires some time by N devs - net result may be more time than if we keep it inhouse. Plus time by IT to set up remote backup and negotiate something with random-VCS to let that happen. If we're dropping backup and just relying on the service, there are some additional concerns. -- Randell Jesup, Mozilla Corp remove "news" for personal email _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
