[Kde-scm-interest] Project release tags on Gitorious

[Eike Hein]

Hi,

for the least days Konversation has been actively interested
in following Amarok's lead and moving to Gitorious ahead of
time, with most of us already using git in some capacity and
preferring it over SVN.

However, in the course of the preparations we believe we've
hit upon a problem with tagging on Gitorious.

It appears that pushing of release tags to projects owned by
the kde-developers team currently has to be regulated by ad-
mins of kde-developers, which we think doesn't scale and
also has some cultural considerations that are not desirable:

- In this model, every time a project team decides it wants
   to tag a new release (or create another kind of tag), it
   has to go through a kde-developers admin. Even if there
   are enough admins around, this adds just another process
   hurdle, and if there aren't enough admins around, it can
   really hold up things.

   And while you currently have to ask a sysadmin to initia-
   lly create an app dir in /tags for you in SVN, you don't
   have to ask permission for every individual tag, so we
   feel this would also be a regression vis-a-vis KDE's open
   access culture when it comes to managing the repos.

- An alternative that has been suggested (by Lydia on IRC)
   is to make every app's release dudette/dude a kde-develo-
   pers admin (as Lydia is one atm) to get around the above
   problems. We don't think that makes sense: It's a bit
   brute-force, permission-wise, and is also pretty bad from
   a cultural POV. Right now, in KDE, a gig like being the
   "release dude" is very meritocratic and organic - the one
   doing the work is it. Having to actually appoint someone
   in this way - handing out the fancy title, writing it
   down officially in an ACL file somewhere - feels awkward.
   KDE's always had a project culture that doesn't dwell a
   lot on handing out fancy titles and the politics associa-
   ted with that sort of thing; we think the switch to git
   shouldn't make us more rigid in this regard.

Basically, we think there's a need for a finer-grained per-
mission model that allows app teams to continue as before,
and would like to see this put on the agenda for improve-
ment for the git transition. Comments?


-- 
Best regards,
Eike Hein