Rant: So you want help?

[Patrick Spendrin]

Am 04.11.2010 14:50, schrieb Alf Gaida:
> Am Donnerstag 04 November 2010, 14:39:16 schrieb Christian Ehrlicher:
>> I'm not answering your questions - just one note from my side:
>>
>> There is nobody who is actively working on KDE/windows because nobody has
>> time for it / was frustrated about the direction and gave up...
>>
>> I'm just using the emerge buildsystem for my own projects and sometimes
>> commit something because kdegames does not compile.
>>
>> Christian
> 
> Just a (maybe) stupid question? Where is the problem - the sources exist and 
> compile under linux. So i dont understand why compiling the same source under 
> windows is that great problem. I dont understand the fact that there is no 
> official list of todos and common problems. If there are concrete lists of 
> problems to solve, eventually somebody like me can help. But i have no time to 
> search Informations piece by piece for hours or days. IMHO the problem is 
> generally the lack of information about the project.

Well, even though I didn't want to comment on that yet, I will sketch it
here:
KDE on Windows building/packaging works this way:
- You have the sources that are developed under Linux mostly. Before a
release, they require a new 3rdparty dependency - so you have to get
around adding a new 3rdparty library, make it build, fix it or update it.
- Then there will be a release. It is checked that this compiles under
Linux, but not under Windows. This means, that depending on the time you
invested before the release, the tarballs will build out of the box, or
not. You must fix them then, add the patches to emerge packages and make
binary packages from them (These would currently be 20-30 packages, some
are smaller like automoc, some are bigger like kdelibs). Then you must
upload them, currently also fixing the dependency list that is needed
for the installer, which will hopefully be generated in the future from
emerge directly.
Multiply the time for such a release (normally ~half a weekend) by the
number of compilers.

Restart this with the next release 4 weeks later.

This was more or less the way Christian and I made releases, this is
very ineffective and *must* be automated quite a lot. Also it is hard to
split this into tasks for many people (*ideas are really really welcome
for this).

One thing is, if we could distribute the job to fix issues with a
specific package, e.g. if Gilles fixes digikam & kipi, this already
takes apart some of our work load, we might need to coordinate that
better with the releases. Some more splittings would be welcome though.

regards,
Patrick