hosting 3rd party scripts all on one SVN server

[Mark Kretschmann]

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.


Thanks,
Mark.

-- 
Mark Kretschmann
Amarok Developer
Fellow of the Free Software Foundation Europe
www.kde.org - amarok.kde.org - www.fsfe.org