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

[Anne-Marie Mahfouf]

On Thursday 09 December 2010 08:42:52 Torgny Nyblom wrote:
> 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-ru
> > > > les-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?
Valid reason but it needs communication. It's in 11 days...
> 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).
You do not mention kdebindings which is the closest example to kdeedu.
It would seem logical to me that if kdegames split then kdeedu also split: 
that all similar modules adopt a similar attitude. Maybe my logic fails due to 
lack of expertize in that area.
> > - 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.
Here we are, this is where this whole process is not really working in my 
opinion. This is where it annoys me. Usually within KDE we help each other and 
from the start of this migration I hear about those "rules" but nobody ever 
explains them (apart from the techbase page, right...) and offered guidance.
I learnt a lot since I started in KDE, I learnt by myself but I also relied on 
peer help. I would not have succeeded learning alone.
I am disappointed to be dismissed with a "Do it". Obviously the task is hard 
enough so that you need to have lots of 1)time 2)knowledge 

Anne-Marie