[Kde-scm-interest] Proposal: Migrating KDE to Git...orious.org

[Jeff Mitchell]

Chani wrote:
>> S1) Commitfilter
>>
>> Although running arbitrary shellscripts on Gitorious.org as git hooks is
>> not allowed for security reasons, Johan is planning to add support to
>> POST the data of commits to URLs (it's in a branch that will be
>> integrated soon). This will allow you to supply one or more callback
>> URLs for a repository, so whenever someone pushes the details of the
>> commit are POSTed via HTTP to the callback URL(s) as JSON. It includes
>> items like the actual commit, who pushed it, and the before/after SHAs.
>>
>> This could be used (with IP-based access control for security) to still
>> be able to provide commitfilter-like functionality (although
>> commitfilter as it exists would likely need to be updated as a result of
>> the SCM difference in the first place).
> 
> what about BUG:, CCMAIL:, etc?could it provide hooks for that too?
> I guess whatever server the callback goes to could do anything with the data, 
> right? but someone would have to set up such a server and (re)write all the 
> scripts...
> 
> so... do we have someone willing and able to do that? I don't know a thing 
> about this web stuff.
> 
> is there any chance gitorious would be willing to make an exception to this 
> no-scripts rule for KDE? if so, how much work would it be to write *those* 
> scripts? (ie, would it be less work than doing this http hook thing?)

No.  But it shouldn't be that much work.  Subversion hooks (IIRC) are
basically get (from the server) the revision number and the contents of
the commit.  Adapting them to being POSTed from the web should
essentially just be changing *where* the data comes from...I don't think
it would actually entail an enormous amount of rewriting of the scripts
themselves (any changes that would have to be done as a result of Git
would have to happen anyways).

>> S2) Capacity
>>
>> Capacity is a concern, as KDE would become the largest project both in
>> terms of source code and activity. When these issues was posed to Johan,
>> here was his answer:
>>
>> 'We should look into some kind of general mirroring facility in the long
>> run (not really because of bandwidth used, but also more to speed up
>> transfers on other continents). We do pay for SAN storage and bandwidth,
>> but there's "plenty available" as long as we pay for it.'
> 
> so... who's going to pay for it in the end? do we need to rely on nokia for 
> this? if not, would the amount be small enough for the e.V to easily pay it? 
> I've no idea how much bandwidth we eat with svn. 
> if something goes wrong and somehow we don't have the money for it any more 
> (quite unlikely I hope) I guess it's just a matter of putting a copy of the 
> repo back on one of our own servers?

Johan is working on getting a SLA estimate for us.  However, if we
spread repos for reading across our infrastructure, it reduces most of
the load we would put on Gitorious.org.

> one more question: is this worth the money when we can do it ourselves for 
> free? it does sound like we get a lot for that money (including dirk not 
> having to do as much work).

Well, there's no such thing as "free".  It would essentially come down
to money vs. time (which is money).

>> Johan is working on getting an estimate for the cost of a SLA for KDE.
> 
> SLA = ...server license agreement? :)
> estimates are good.

Service Level Agreement.  Guarantees that for X money, they will ensure
Y level of service (downtime, available bandwidth, etc.)

>> C2) What happens if Gitorious.org goes down, how long would it take to
>> get it up and running again?
>>
>> Johan's answer:
>>
>> '"if there's a bug, how long does it take to fix?" :)
>>
>> In the case of hardware failures, we do have redundant hardware. We
>> currently run Gitorious.org on two sun x4150's with 32GB of ram,
>> connected to a SAN (over FiberChannel) where the actual Xen images and
>> repository data etc is stored. The machines only utilitize 50% of the
>> resources that can't be grown or shrunk, so we can move the images
>> between them in case of hardware failure.'
> 
> gitorious.org was down inconveniently when scripty was updating last week. 
> this won't matter so much after I make scripty's git stuff a bit more robust, 
> but... how often does gitorious go down for upgrades or whatever it was?

Dunno.  Ask Johan on Wed.  :-)

--Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090703/ce4e7234/attachment.sig