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

[Josef Spillner (KDE)]

Hi there.

Em 18/2/2008, "Ian Monroe" <ian.monroe at gmail.com> escreveu:
>* On kde-apps a script is tied to its original creator. If the creator
>stops making releases, it becomes abandonware unless someone forks it.

This is an issue with many sites. I recently came across it on freshmeat
again, which only allows one project owner. Should interest cease, then
project entry transferral must be requested manually. It'd be nice to
have a co-maintainer field. From Debian I know that the addition of such
a field has helped a lot and eases transitions, as long as at least one
of them is still active.
For smaller uploads, if no team maintenance is foreseeable, I propose to
have "site admins" which might decide a transferral on their own, and
only redirect to the site's "master admin" (e.g. the site's owner in
kde-look's case) if they cannot fully decide.

Is that more or less what you'd want?
The upload scripts would have to be adapted but that's a
straight-forward addition.

>* 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).

Yet you don't want random Joes to overwrite uploaded entries. As an
addition to the above, what is already available in the GHNS scripts is
an upload queue that must be checked if not configured to accept each
upload automatically.
We could tweak this to accept for the author, but put into the queue for
other uploaders.

>* 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.

Indeed.

>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.

Heh, you could upload automatically with a hook script under the name of
a generic bot user :-)
Or you use what I'm going to mention below:

>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.

The current set of GHNS scripts support SVN-backed repositories. However,
a new version is already generated for each commit. I see that it would
make sense to watch only tags for more complex entries such as scripts.
The current server-side hook script needs changes anyway. For example,
it checks for XML Schema compatibility, but the schema is way too strict
as it requires the exact ordering of lines. We need a more relaxed
schema language, and the obvious choice here (RelaxNG) isn't much
better, despite the name :)
I've added your wishlist items to the TODO file in the hotstuff scripts
SVN. You can also hack on it if you feel like it, otherwise you should
give me some days, e.g. next weekend during FOSDEM in the KDE dev room
there might be enough people to pressure me.

Josef