RFC: Release Management Going Forward

[Nicolas Alvarez]

Alexander Neundorf wrote:
> On Thursday 23 June 2011, Nicolas Alvarez wrote:
>> Rex Dieter wrote:
>> > On 06/21/2011 06:41 AM, Will Stephenson wrote:
>> >>>> So you want the fine grained tarballs, if I understand correctly ?
>> >>> 
>> >>> Just looking at how the openSUSE buildservice is set up, they seem to
>> >>> use fine-grained tarballs as well, although I don't know how closely
>> >>> those match to the breakdown you are using.
>> >> 
>> >> We're using them, and the consensus among the team so far is that they
>> >> allow faster builds (broader dependency tree instead of deeper) and
>> >> isolate failures better. These are the kde.org tarballs; is anyone
>> >> using their own??
>> > 
>> > Fwiw, in fedora, we hacked the 4.6.80 kde.org tarballs and
>> > build-process to be as-close-to-monolithic as possible.
>> 
>> I had to do many changes to the buildsystem of every kdeedu app in 4.6 to
>> let them build both monolithic and split. If you need to continue with a
>> monolithic build, (and preferably if fedora is not the *only* distro that
>> needs it), I'm willing to forward-port the changes to the master branch.
>> 
>> However, IMHO, KDE shouldn't officially release both sets of tarballs.
>> That would be a mess.
> 
> Please have a look at the Superbuild CMakeLists.txt I did for kdegraphics.
> It can build all-in-one, but then internally each repository is included
> as a cmake "ExternalProject", i.e. it still builds as if it was
> independent (but controlled by the super-CMakeLists.txt):
> https://projects.kde.org/projects/kde/superbuild
> 
> And you can not only do that, you could also write such a
> super-CMakeLists.txt for the whole KDE SC, enable only e.g. potato guy,
> and it will iteratively tell you which additional subprojects you need to
> enable to have all dependencies satisfied.
> Then you can build exactly that.
> Or you could create a source package consisting of exactly those
> subprojects needed for potato guy.
> 
> I haven't done this for whole KDE SC yet, but I tested it on kdegraphics
> and kdesupport so far and it works.

I tried an ExternalProject-based approach before for kdeedu. The main 
inherent and unavoidable disadvantage is that 'make' alone will *install* 
the subprojects.

-- 
Nicolas