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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-windows mailing list Kde-windows@kde.org https://mail.kde.org/mailman/listinfo/kde-windows