hosting 3rd party scripts all on one SVN server

[Frank Karlitschek]

On 27.11.2009, at 08:21, Mark Kretschmann <kretschmann at kde.org> wrote:

> On Mon, Nov 9, 2009 at 7:27 PM, Ian Monroe <ian.monroe at gmail.com>  
> wrote:
>> On Mon, Nov 9, 2009 at 2:02 AM, Mark Kretschmann  
>> <kretschmann at kde.org> wrote:
>>> Sorry, but I don't think a trust system alone would cut it. For a
>>> minute, just assume that you would "trust" me somehow on a certain
>>> technical level. Then I'd use this trust, but I would make one bad
>>> call (maybe because I'm not as good as you expected, or because I  
>>> had
>>> a bad day), and then a serious malware component slips through our  
>>> net
>>> of trust.
>>>
>>> What would that make me then? It would make me a person who screwed
>>> something up very badly. So I wouldn't want to have any trust or
>>> responsibility in the first place. Who would?
>>>
>>> What I'd rather see is something we had talked about a long time  
>>> ago:
>>> All scripts on kde-apps.org (reachable via GHNS) must be hosted in a
>>> public version control system. This system could e.g. be SVN (it's
>>> easy for newbies). The server could be hosted by KDE, by Frank, or  
>>> by
>>> another party. Let me explain what advantages I expect from this
>>> approach:
>>>
>>> *
>>> An end to "abandonware": This problem has plagued us from day one:
>>> Author A releases script A1. Author A gets lost in static. Author B
>>> comes, copies the source of A1, releases a separate script called  
>>> B1.
>>> Rinse, repeat. With a version control system, author B could take up
>>> maintainership of A1, without forking the actual code. Much better.
>>>
>>> *
>>> Increased security by more eyes and better accountability: If code  
>>> is
>>> publicly hosted in a VCS, then someone boldly goes and adds a commit
>>> to it that contains malware, two things would happen: 1) Someone  
>>> might
>>> actually notice the bad change, before it's too late. 2) We could
>>> exactly tell who added this change, and when the person did it. This
>>> should provide quite a barrier for such attempts.
>>>
>>> *
>>> We programmers could all review the bulk of code more easily,  
>>> without
>>> downloading each script and each specific version of it. Right now I
>>> download approximately two scripts per month and take a quick look  
>>> at
>>> the code. With a public repository, I could see myself browsing it
>>> more often, if only to kill some time. Easy access would  
>>> automatically
>>> provide us with some level of code review.
>>>
>>>
>>> Thanks for listening.
>>> I would love to hear further comments about this proposal :)
>>
>> This is a good proposal (though I'm pretty biased, it was partly my  
>> idea :P).
>>
>> Basically the kde-apps.org model completely fails for scripts. It
>> works for art because there's no such thing as abandonware for  
>> art. :)
>> It works for applications because stuff isn't abandoned so often, and
>> being a causal contributor to a full application is non-trivial
>> anyways so I'm not sure infrastructure could solve the issue of
>> abandoned apps.
>>
>> But scripts are typically 200-1000 LOC and they do *often* get
>> abandoned. Writing an Amarok script isn't a commitment, its something
>> you do on a lazy sunday. So kde-apps becomes a minefield of scripts
>> that maybe need a simple change to work again, but the author has
>> abandoned it and no one is able to contribute a fix. Or there's a
>> bunch of forks.
>>
>> Having an open SVN server where we get the scripts out of SVN tags
>> would solve this. Jeff's idea of ACL for the tags is a good one, only
>> the script author or maybe a few Amarok developers could tag a  
>> script.
>
> Bump. Frank, I know that you are very busy and all, but could you
> please comment on this? I think this idea is too important to let it
> get lost in static.

Hi Mark,

sorry for the late reply. I'm busy at the moment with stuff for KDE  
4.4 and the Open-PC.
I like your proposal. This is definitely the way to go. I am already  
working on an git integration so that we can do ghns downloads  
directly from a repository in the future.
But I can't promiss that this will be ready before 4.4

I think this will be areally great and powerful system together with a  
trust system and the huge GHNS improvements we have for KDE 4.4

Cheers
Frank