== 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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest
