[Kde-scm-interest] Re: playground/edu and kdeedu migration?

Torgny Nyblom kde at nyblom.org
Thu Dec 9 08:42:52 CET 2010


On Wed, 8 Dec 2010 16:01:18 +0100
"Anne-Marie Mahfouf" <annma at kde.org> wrote:

> On Wednesday 08 December 2010 15:19:06 Ian Monroe wrote:
> > On Wed, Dec 8, 2010 at 8:08 AM, Niko Sams <niko.sams at gmail.com> wrote:
> > > On Tue, Dec 7, 2010 at 21:37, Anne-Marie Mahfouf
> > > 
> > > <annemarie.mahfouf at free.fr> wrote:
> > >> Hi,
> > >> 
> > >> I am starting to feel quite anxious about the git migration as kdeedu
> > >> has no rules except for Marble. Which already makes me ask:
> > >> when main modules will move, will they move as a whole and we'll clone
> > >> them as we svn co them now?
> > >> 
> > >> Second question: I asked on the kdeedu mailing list about writing the
> > >> rules and nobody came forward. I am not qualified to do this, really, I
> > >> have no clue whatsoever on even using the servers through ssh, let
> > >> alone getting history for all this. Knowing that somesone is sponsored
> > >> to do it makes me think it's really not something fun which can be done
> > >> quickly.
> > >> As I gathered kdelibs and kdebase will move on the 20th December. What
> > >> about the other modules? It feels like first class modules and second
> > >> class ones. It's a bit weird that as a community it's "do your stuff
> > >> and if you can't, too bad".
> > >> 
> > >> Maybe a clear email to all devels on what really is the plan would help.
> > >> Maybe also talking with the eV to get more sponsoring?
> > > 
> > > I've been working on split rules for kde modules including kdeedu.
> > > You can find the rules in the split branch of the kde-ruleset repository
> > > (http://gitweb.kde.org/kde-ruleset.git/blob/refs/heads/split:/kde-rules-m
> > > ain) Search for "create repository KDE/kdeedu/" to get a list of
> > > resulting kdeedu repositories.
> > > 
> > > Afaik no decision regarding splitting has been made, nevertheless I'm
> > > in favor of
> > > splitting and so started working on the rules.
> > > It is still WIP - currently i'm stuck at a svn2git bug (not sure yet
> > > if it is really a bug)
> > 
> > I wonder if instead of a branch, you could just stick all your work
> > into a subdirectory of the master branch. Would just make things
> > easier, its easy to forget about the work you are doing.
> > 
> > Personally I think the question of splitting is best answered by each
> > module. For instance kdebindings is planning on taking the switch to
> > Git as an opportunity to split up their module in ways that not even
> > the distros have done before, to make the dependency tree more clear.
> 
> Thanks Niko for working on our split rules. 
> 
> What I think we need: an IRC meeting with all modules coordinators or people 
> representing the module (for example I am not really qualified to speak about 
> this matter for kdeedu and I would leave some other people do it if there are 
> some). A large invitation should be sent to all mailing lists. At this meeting 
> it should be made clear:
> - what the plan is for the modules ready (kdelibs, base, ...) (isn't the 20th 
> December a bad date considering the release and the Xmas holidays?)

Or is this the perfect time since most devs probably are busy with family, leaving the tree relatively quiet for us to work on?

kdelibs - monolithic
kdebase - split
kdepim - monolithic
kdepimlibs - monolithic
kdepim-runtime - monolithic (the /runtime/ dir in kdepim)

The decision is up to the module maintainer(s).

> - splitting or not a module: what does it mean exactly? what are the + and - 
> for it?

This has been discussed to death on this list before as has the whole conversion.
Boiled down version:
Split:
+ Easier for new devs to get into.
+ Better track of dependencies.
+ Closer to the way distros ship the packages.
- Not easy/or at all feasible for interdependent apps/libs.

Monolithic:
+ Easier (less rules needed) to convert.
+ More like we have it now.


> - what is expected for the other modules which have no rules finished right now

Write them.

> - what doc should devels rely on in order to build trunk and commit? 

To quote the topic of #kde-git

"Discussing KDE's switch to git | http://community.kde.org/Sysadmin/GitKdeOrgManual | http://techbase.kde.org/Projects/MovetoGit | http://community.kde.org/Sysadmin/DeveloperAccessForRuleWriting | http://projects.kde.org/projects/playground/sdk/kde-ruleset | The color is discussed on kde-scm-interest at kde.org | Do not forget about docs when migrating!"

/Regards
Torgny


More information about the Kde-scm-interest mailing list