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 _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
