Changes to our Git infrastructure
mitchell at kde.org
Tue Dec 30 16:18:30 GMT 2014
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
> 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.
More information about the kde-core-devel