[Kde-scm-interest] Some ideas

[Lorenzo Villani]

== Foreword
I tried to read most of the messages in the archive but maybe I have missed 
something and/or my ideas are confused, I apologize in advance for that.

I suggest some radical changes to the way KDE releases are managed and 
repositories are organized.

So... after reading the archive it seems that:
- KDE is going to move to git
- I didn't see any clear, approved, proposal for the repository layout (am I 
missing something?)
- Are we going to host the repositories on gitorious?
- Scripty seems to be difficult to port



== KDE & git:
I don't see problems with that, I find git useful, powerful and I use it already 
with the Subversion conduit.



== Repository layout:
It seems that we are going to keep the layout mostly untouched, this means that 
we'll have pretty much the same hierarchy we have now, this means something like
KDE/
    <module>/
extragear/
    <category>/
        project/
playground/
    <category>/
        project/
and so on. (Please, correct me if I'm wrong).

But I think that times are changing and both developers and users see KDE more 
like a platform and not as a collection of monolithic modules.
(I know, you may argue that distributors can make so called 'split packages' but 
that's another story).
So, here's my proposal:
- each individual application (okular, gwenview, etc) get its own repository, 
not tied to a particular module and with its own release schedule.
- the module (i.e.: kdegraphics, etc) just becomes a way to conveniently group 
applications and 'clone' them with a single shot (done via git submodules).

The whole idea behind this proposal is to show KDE more as a collection of 
projects built around the KDE pillars rather than big 'blobs' of stuff.

===== How to deal with "the push bit":
Being a collection of individual projects only the 'core' developers are given 
initial push access to a project's repository, they can then add more people as 
they see fit. I know that KDE developers are not used to this (everyone has 
commit access to each other's code) but I think that this should improve overall 
code quality as new contributors are first required to submit their code for 
review before inclusion.
However, if project's core developers want, they can open their project to all 
kde developers. (Technical details are expressed in the "Infrastructure" 
section).

===== How to deal with KDE releases:
I think that there are mainly three ways to deal with that:
- Eliminate the concept of a "KDE release" entirely
  o This way each project get its own release schedule.
  o More flexibility from a developer point of view (IMHO)
- Adopt the concept of "contemporary release" similar to Eclipse.
  o It's just a snapshot of current projects releases
  o Every project get its own release schedule.
  o This way KDE releases may become difficult to manage, but some tool can be 
written to ease the release process and tarballs creation.
- Restrict the concept of "KDE release" only to the Pillars of KDE
  o Most of the projects get their own release schedule
  o Consistent releases of the core technologies
    - This way the "KDE release" becomes the "KDE platform release" or something 
like that.



== Infrastructure
My opinion is that we can follow Qt software/Nokia decision to put the 
repositories on gitorious and I think we can:
- Get a customized section on their website just like Qt software did (something 
like kde.gitorious.org or have something like git.kde.org pointing to gitorious)
- Fund gitorious bandwidth and storage costs in some way
- Create a 'kde-developers' group which comprises all the people who have a KDE 
SVN account.
- Create the individual project repositories there
  - As said earlier: give initial push access only to core developers
  - If the core developers want, they can give access to the 'kde-developers' 
group

===== Benefits
- We leverage an existing and tested infrastructure
- Gitorious makes code review dead easy to do
- Many Qt and KDE developers already have an account on gitorious
- Lighten sysadmins' workload in some way (i.e.: I don't have to poke the 
sysadmins to change the SSH key for me)


===== How to handle the migration
My proposal is to track history inside git only from KDE 4 onward and keep 
earlier history in compressed tarballs of the subversion tree and make them 
available somewhere.



== Scripty
My proposal is to replace scripty with another translation system which supports 
git by default.
However I have no direct experiences with any of the tools around.

There's Rosetta, but that's Canonical's stuff and AFAIK it's tied to Launchpad 
and bzr.

On the other side I heard of an open source project which supports many version 
control systems called Transifex.
Transifex has a web interface, can work with remote repositories (git included) 
and is currently used by Fedora to translate their projects.
The Transifex guys have also launched the transifex.net website which is a 
Transifex instance for 3rd party projects which don't have the resources (or 
don't want) to set-up a private Transifex instance.

Transifex should (I repeat *should*, because I have never used KDE's translation 
infrastructure nor Transifex) be flexible enough to replace scripty.

Links:
http://transifex.org/wiki/About -- General information about Transifex
http://fedoraproject.org/wiki/Interviews/DimitrisGlezos -- Interview with 
Dimitris Glezos about Transifex



== Conclusion
So, here are my proposals and I'd like to hear your comments, suggestions and 
critics, this is just my $0.02.
Of course I volunteer to get the transition done.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090607/507f9d99/attachment.sig