[Kde-scm-interest] the permissions confusion

[Eike Hein]

On 12/13/2009 11:21 AM, Lydia Pintscher wrote:
> I can only speak for Amarok from extragear here but I can't remember
> when someone outside our core team committing to our code has been a
> big problem. People usually ask even for trivial fixes. No need for
> any technical solutions here.

Ditto from Konversation's side. Sure people who are not
core Konvi developers sometimes commit something that
needs touchups or fixes afterwards - but that happens to
core Konvi developers just as well. We have no need or
interest to restrict commit access.

In the broader scheme of things, I'd rather fix a fuck-
up now and then than make contributing harder. I'd say
erring on the side of lower barrier to entry is best.

Quality assurance is what we have pre-releases and re-
leases for instead of telling users to get apps from
the SCM.


In any case, imho what we're doing here is bikeshedding
on policy details instead of making actual progress on
the migration. After converting Konversation I have now
realized that the elephant in the room that everyone is
dancing around at the moment is writing the ruleset for
svn2git; if we had that done, there'd be much more pres-
sure on all the other todo items falling into line.

Writing these rules is a major job. Considering that:
- Much stuff in the core modules was moved from extra-
  gear or playground
- Much of that did a stint in kdereview inbetween
- playground has seen a few reorganizations, iirc
- You often have to deal with special cases in the
  rules by adding ignores for certain SVN revs, like
  people making mistakes and doing additional stuff to
  undo them (like creating a tag, deleting it and crea-
  ting it again)
- You need to handle weird stuff cvs2svn did back then,
  like the insane way it created tags and how they were
  later manually renamed/moved in /tags
- kde-common/accounts is insufficient as an account map
  because of account names changing between CVS and SVN
  or accouns getting deleted, so conversions need to be
  examined and gaps filled in
- Some decisions need to be made by a human with know-
  ledge of the app. E.g. both Konversation and Yakuake
  have overlapping KDE 3 and KDE 4 commit histories by
  way of /branches/extragear/kde3. In Konvi's case the
  overlap was only backports from the KDE 4 codebase to
  the KDE 3 one, so we ignored it and produced a single,
  flat history in the conversion. In Yakuake's case how-
  ever the KDE 4 version was a from-scratch rewrite and
  the work going on in the KDE 3 version in parallel
  was unrelated, so there the KDE 3 version needs to be
  imported on a "kde3" branch and the KDE 4 version on
  master.

... the rules for a single core module will likely be
pages upon pages, and the extragear apps are by no
means trivial either. It will take many weeks to sort
this all out.

Ossi will of course say again now that he thinks the
tool ought to be smarter and do more of the work for
us. If that's possible, it would be cool. But that
nonetheless means that work needs to happen on a bet-
ter tool.

This has been stalled for two years now or so. Since
I'm now one of the few people who actually have expe-
rience with the rules format I've become part of the
problem now, of course.

We need to decide how to go forward - put effort into
a better tool, or into the ruleset - and then somehow
divvy up the work (everyone adopts a module? we try
to get maintainers in on the job of writing rules for
their stuff?) and get started.


> Cheers
> Lydia 

-- 
Best regards,
Eike Hein