Rant: So you want help?

[Thomas Friedrichsmeier]

Hi,

On Thursday 04 November 2010, Patrick Spendrin wrote:
> KDE on Windows building/packaging works this way:

ok, let's focus on creating a 4.5.x release. So far, it seems to me the 
greatest obstacles are:

1) Only few people really know what precisely needs to be done to create a 
release. Your sketch certainly helps understanding some of the major steps. 
But still, I for one simply wouldn't know where to start. So I'm hoping for 
very specifc instructions. Naturally, there will be problems of all sorts on 
the way, and you can hardly anticipate and document all of that. But in an 
ideal world, what would be the sequence of commands needed to create a 
release?

2) Creating a release is a daunting task, and it's hard to split up into more 
managable portions. Let's break this one up some more, into mostly independent 
problems:

2a) Packaging dependencies: Alright, I can see the pain involved. But are 
missing dependencies really still an issue for a 4.5.x release? If so, do you 
have a list (complete or not) of which ones in particular? I guess it should 
be possible to split up at least this point among several people, easily.

2b) I keep stumbling across the "multitude of compilers" issue. If ressources 
are this limited, then trying to package for several compilers at once looks 
totally counter-productive to me at this point of time. I've stated before 
that I'm all for dropping everything except MinGW4-32bit from the installer, 
but I guess this idea won't be accepted (I'd still appreciate any direct 
feedback, though). Well, here's a more moderate variant of the same theme:
- Instead of one installer supporting all compilers, create (number of 
compilers) installers each supporting only a single compiler.
- Split the repository by compiler type as a top-level folder (not essential, 
but would seem like a good idea to me).
- Give up the idea that releases for all compilers should be made available at 
once. Instead, let each compiler type be handled by one person / team on their 
own schedule.
Advantages:
- Only need to deal with the compilation fixes for, compilation time, software 
and hardware requirements of one compiler per team.
- Breaks up the task into smaller portions that can be split across persons / 
teams in a straight-forward manner.
- Maybe I'm missing something important, here, but breaking up the installer 
this way looks like a rather managable exercise to me.
- Third parties that only work with one compiler can simply link to the 
appropriate installer, and thereby remove one more point of failure.

2c) Collaborating on compilation fixes. Frankly, I don't understand exactly how 
you are dealing with any required diffs to the release tarballs. So I can't 
comment much on this. But wouldn't it be possible to keep diffs in SVN / git 
somewhere? Then splitting up work across modules should become possible 
(assuming the key problem is not kdelibs itself)? Or am I too naive, again?

2d) Lack of automation. Obviously more automation would be a good thing. I 
can't really comment on this, and I certainly can't help with this, without a 
clear understanding of 1), though.

Well, either way, 1) appears to be the most fundamental point to me. Several 
people have stated their willingness to help in this very thread. I'll re-
state mine, as well. So let's try to use that momentum and get the ball 
rolling.

Regards
Thomas
-------------- 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-windows/attachments/20101105/0e2431c3/attachment.sig