kdesupport rearrangement

[Benoit Jacob]

I support this plan too. Thanks for getting this rolling.

The only nitpick is that there is a risk of confusion between
/tags/kdesupport-for-trunk and /trunk/kdesupport, which is why I also
suggested to move /trunk/kdesupport to /branches/kdesupport (or
whatever you feel is appropriate).

Cheers,
Benoit

2008/9/28, Allen Winter <winter at kde.org>:
> On Sunday 28 September 2008 06:48:51 Tom Albers wrote:
>> Hi,
>>
>> I think we have come to a conclusion, but not to a descision. Let's try to
>> change that. Below you find the proposal based on the various mails to
>> this list. I will wait untill there are a few supporters for this
>> proposal, before posting it to k-c-d and k-d. Improvements are welcome
>> too.
>>
>
> I support this plan.
> I also volunteer to help create the necessary CMakeLists.txt files.
>
>> ------------------------------------------------------------------------------------------------------------------------
>>
>> The release-team has decided to change the organisation of the kdesupport
>> system we use. Please read the details below.
>>
>> Problem
>> ------------
>> KDE development is devided in several branches, especially the current
>> stable KDE branch and the unstable development branch in trunk. kdesupport
>> libraries are independant of KDE, but KDE depends on them. At this moment
>> there is no indication at all which kdesupport library should be used for
>> a certain KDE branch.
>>
>> We want a simple system for developers to just know for sure that you got
>> the right kdesupport libraries when you want to compile a KDE tree
>> completely from subversion.
>>
>> Solution
>> ------------
>> For each main kde tree we will create a tag. For example for the current
>> stable KDE release we create a tags/kdesupport-for-4.1/. Within that
>> folder there are (cheap)copies of the kdesupport libraries which should be
>> used for compiling the KDE 4.1 tree. For example:
>>    tags/kdesupport-for-4.1/phonon/    (svn cp'ed from tags/phonon/4.2.0)
>>    tags/kdesupport-for-4.1/strigi/    (svn cp'ed from
>> tags/strigi/strigi/0.5.11)
>>    tags/kdesupport-for-4.1/qca/    (svn cp'ed from tags/qca/2.0.1)
>> Also, it will contain a CMake file, so all subdirectories can be build in
>> one go. So if you want KDE4.1, just simply checkout this tag and you are
>> done.
>>
>> The same will go for trunk, so we will create a kdesupport-for-trunk. This
>> also contains copies to the right version of the kdesupport libraries
>> needed to build trunk. That means developers have a choise: either use
>> trunk/kdesupport where development takes place, so that could lead to
>> breakage in for example kdelibs but you can probably fix them, or you
>> choose to compile KDE trunk with kdesupport from
>> /tags/kdesupport-for-trunk and you are sure kdelibs trunk compiles from
>> it.
>>
>> Who
>> ------------
>> The kdesupport maintainers should make sure that the right version if
>> available in each tag. If they release a new version they update the copy
>> with a simple svnn rm + svn cp. If some kdesupport developers think
>> everyone should just use their trunk, they could just regularly rm+cp the
>> "tag" from their trunk. An svn external would have been more appropiate in
>> that case, but that's unfortunatly not an option.
>>
>> When
>> ------------
>> We would like to have this infrastructure in place at november 1st.
>>
>> Tom Albers
>> w/RT-hat
>
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>