Rant: So you want help?
thomas.friedrichsmeier at ruhr-uni-bochum.de
Fri Nov 5 14:21:15 CET 2010
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
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
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
- 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20101105/0e2431c3/attachment.sig
More information about the Kde-windows