Changes to our Git infrastructure

[Jeff Mitchell]

On 30 Dec 2014, at 10:56, Thomas Lübking wrote:

> On Dienstag, 30. Dezember 2014 16:31:20 CEST, Martin Klapetek wrote:
>
>> Not necessarily, some projects may just be finished and don't need 
>> more
>> commits.
>
> Yes, of course - but I'd assume they'd be transferred from "scratch" 
> to playground/extragear/whatever then?
>
> Also I did not mean to imply "you didn't commit yesterday, gone is 
> your stuff", but starting to ping the user after half a year of 
> inactivity, opting in for prolongation "click here" - the idea should 
> be to get bit rot out, not to destroy anyones work.

This is all a sidebar anyways, as the current problems with scratch 
repos are not really relevant. The solutions we're looking at to replace 
our current infrastructure do not have the necessary bits to support 
this kind of workflow *right now*. This does not mean that they could 
not in the future, even the near future. But in the *short term* they 
would require a manual step by sysadmins or by those that want to help 
out the sysadmins with this and are given privs to do so.

There's a useful metric, which is that if you take the number of current 
scratch repos and divide them by the number of days we've had the 
current infrastructure, you end up with something close enough to 0.5. 
As in, on average, someone creates a new scratch repo once every two 
days. If you then look at the length of time since last commit for the 
vast majority of the repositories, you'll see that within the last 
couple of years, that number is way, way lower.

The point being that having a manual step in some near term doesn't mean 
that dozens of scratch repos a day are going to be sitting waiting on 
someone to create them. Yes, it's useful to be able to have a repo 
*right now*, but up until such a thing could be automated again, I'd 
like to try to take advantage of our international nature and get some 
interested parties to simply help try to ensure that there is 24/7 
coverage so turnaround time is short. In addition, once a solution is 
finalized, someone could take on the task of working with sysadmins and 
upstream to get such a solution implemented.

Most people are using scratch to have a place to store a new experiment, 
where pushing code from their local repo to the new scratch repo in a 
few hours instead of right now isn't that big a deal. I've seen the mail 
about how someone needed a repo that they could get distributed to 
multiple boxes *this very second* and complained about the anongits 
taking a while to get that new repo distributed, so they ended up using 
GitHub (presumably, in the short term). I'd prefer to avoid that needing 
to be necessary, but this is really not a widespread problem. The 
numbers just don't back it up.

--Jeff