[ghns] Idea about integrating SVN, also general brainstorming and status request

Ian Monroe ian.monroe at gmail.com
Tue Feb 19 07:08:55 PST 2008


On Feb 19, 2008 3:05 AM, Frank Karlitschek <karlitschek at kde.org> wrote:
>
> On 18.02.2008, at 17:34, Ian Monroe wrote:
>
> Hi Ian,
>
> > I'm a developer of Amarok and we've identified a few problems with the
> > current setup that Amarok 1.4 has with kde-apps.
>
> You can always send me an email if you have a problem with kde-apps. I
> ´m happy to
> help you. :-)
>
> >
> > * On kde-apps a script is tied to its original creator. If the creator
> > stops making releases, it becomes abandonware unless someone forks it.
>
> I, or any other admin of kde-apps, can change the owner of an entry. I
> do
> this every few days. Please send me a mail if you want me something to
> change.
>
> I´m also implementing the possibility to assign an entry to several
> owners. In a few
> weeks you can have a group of maintainers for an entry.
>
> I can give you admin rights if you want. So you can edit and delete
> all entries.
> What do you think?

No thanks, but I just asked and MOTU and Amarok promoter Harald Sitter
would like access to moderate Amarok scripts. "Harald Sitter"
<sitter.harald at gmail.com>, and I'm pretty sure his kde-apps username
is apachelogger.

> > * Bitrot. Sometimes a script works perfectly fine, but just needs a
> > bit of tweaking to work with an updated Amarok or webservice. People
> > can submit patches to the maintainer, but how do you even know they're
> > still working on it (see above).
> > * There really isn't anyway to do quality control on the scripts.
> > Not-so-great-QC is part of user-generated content, but it can be
> > improved.
> >
>
> Yes, this is a knows issue. I am working on an approval and review
> system.
> This is needed for plasma too.

I think plasmoids are similar to Amarok scripts and need a SVN based
system. Amarok 2 will have its own plasmoids, part of the reason we
want to address it since user-generated content is now more important
then ever.


> > For a while now Amarok has had a SVN repo available for use by script
> > writers, partly to address these issues. But the kde-apps "one app,
> > one maintainer" policy kind of negates it. We want to bring the Amarok
> > scripts (some of which are quite complex) into the full spirit of OSS
> > and make easy collaboration the default.
> >
> > One idea is to have a SVN (or git) repo, and have GHNS generated the
> > releases out of it. This is partly inspired by Rails, where you can
> > upgrade to new version by specifying a SVN tag. So instead of users
> > uploading tarballs, they could setup a project and then commit to a
> > special SVN repo. Tarballs could be generated out of a tag. So while
> > it would be etiquette to let the creator/maintainer of a script decide
> > when to the release, there would be no technical barrier to bar any
> > SVN contributor  from doing so. Amarok developers could also follow
> > all the new commits, so this would add some security as well.
>
> svn is a great tool for developers. It is probably a good idea to use a
> svn repository for amarok scripts.
> But if you want more enduser contributions
> a web based community can attract more people to contribute because it
> is easier to use for noobies. And you also have the community factor
> as a
> source of motivaton for the users.
>
> I think a svn repository is suitable for code like amarok scripts. A web
> community is   better for stuff like amarok themes, playlists and
> other stuff.
>
> What do you think?

Yep I agree. Artwork doesn't lend itself to collaborative development
(why open source projects have trouble finding artists I think) so
just having a web-based interface makes sense. But code really belongs
in an SVN.

Note that being driven by SVN doesn't mean kde-apps can't be the web
frontend. But unlike Google Code, RubyForge, and SourceForge where
each app has its own repo with separate permissions, we could do
things in a more KDEish manner and have all Amarok Scripts share one
repo.

Ian


More information about the ghns mailing list