Re: kdesupport rearrangement
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@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport rearrangement
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 [EMAIL PROTECTED]: 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@kde.org https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport rearrangement
On 2008-09-29, Benoit Jacob wrote: 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). The versioned kdesupport tags are great but /tags/kdesupport-for-trunk will be updated over time and tags shouldn't really be changed. Just a suggestion... /branches/kdesupport-devel /branches/kdesupport-stable --markc ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport rearrangement
+1 (although i only recently learned the difference between a tag and a branch so i'm not an expert) 2008/9/29, Mark Constable [EMAIL PROTECTED]: On 2008-09-29, Benoit Jacob wrote: 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). The versioned kdesupport tags are great but /tags/kdesupport-for-trunk will be updated over time and tags shouldn't really be changed. Just a suggestion... /branches/kdesupport-devel /branches/kdesupport-stable --markc ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
