hosting 3rd party scripts all on one SVN server

Ian Monroe ian.monroe at gmail.com
Mon Nov 9 19:27:28 CET 2009


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.

Ian


More information about the Amarok-devel mailing list