Re: kdesupport rearrangement
Op maandag 22 december 2008 16:28 schreef u: So nobody did it? Yes he did: http://markmail.org/message/6ys7shf5dmw2e24p?q=kde-core-devel+kdesupport+faure In Eigen, we plan to branch 2.0 and use trunk for wildly broken development in january. Which means that in the worst case I'll have to do the 'kdesupport rearrangement' myself. But as a punition for everyone's lack of interest in kdesupport, i'd then also port a few random projects to C# and add some hard dependencies on Microsoft MyFramework (tm). Please communicate to kde-core-devel to remind everyone to switch to the tag please. Toma ps. please don't top-post, it makes replying awkward. Cheers, Benoit 2008/10/3 Tom Albers tomalb...@kde.nl: Op vrijdag 03 oktober 2008 15:29 schreef u: On Sunday 28 September 2008, 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. So, are you posting the proposal, or should I just go ahead and do it, and then we would just announce it? I don't think we need more bikeshedding on the naming of the tags ;-) You have my blessing to go ahead and do it and announce it Toma ___ 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 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport rearrangement
2008/12/22 Tom Albers tomalb...@kde.nl: Op maandag 22 december 2008 16:28 schreef u: So nobody did it? Yes he did: http://markmail.org/message/6ys7shf5dmw2e24p?q=kde-core-devel+kdesupport+faure Uh.. ok! I wasn't subscribed to kde-core-devel and I don't know what proportion of the kdesupport developers read kde-core-devel! /me subscribes... Anyway, thanks to David. Please communicate to kde-core-devel to remind everyone to switch to the tag please. Will do. Cheers, Benoit ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport rearrangement
On Monday 29 September 2008, Mark Constable wrote: 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 But if it's called branches, then people will be tempted to fix bugs directly in it etc. I agree that a tag that gets updated is a bit unusual (although, well, we do that for releases before the release is done), however a use but don't modify branch is unusual too... tags/kdesupport-devel tags/kdesupport-stable might be an idea (no trunk in there so less confusion with trunk/kdesupport indeed) but then we would lose the kdesupport for 4.1 once kde-4.2 comes out. This is why I liked kdesupport-for-4.1, because we can have kdesupport-for-4.2 in parallel. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport rearrangement
If we remove /trunk/kdesupport, then we can use the name kdesupport-for-trunk without any risk of confusion. Also, why couldn't we have /trunk/kdesupport-for-4.1etc. in parallel with these tags ? I propose: tags/kdesupport-devel tags/kdesupport-for-trunk (what we called kdesupport-stable) tags/kdesupport-for-4.1 tags/kdesupport-for-4.2 etc... what do you think? Maybe we also want to put all these in a single tags/kdesupport/ directory, I don't know. Cheers, Benoit 2008/9/29, David Faure [EMAIL PROTECTED]: tags/kdesupport-devel tags/kdesupport-stable might be an idea (no trunk in there so less confusion with trunk/kdesupport indeed) but then we would lose the kdesupport for 4.1 once kde-4.2 comes out. This is why I liked kdesupport-for-4.1, because we can have kdesupport-for-4.2 in parallel. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport rearrangement
On Monday 29 September 2008, Benoit Jacob wrote: If we remove /trunk/kdesupport, then we can use the name kdesupport-for-trunk without any risk of confusion. I don't think we want to do that. People working on kdesupport (or fixing the occasional bug) expect it to be in trunk/kdesupport, it's the logical place for it. Also, why couldn't we have /trunk/kdesupport-for-4.1etc. in parallel with these tags ? Well not in parallel with stable ;-) I propose: tags/kdesupport-devel tags/kdesupport-for-trunk (what we called kdesupport-stable) tags/kdesupport-for-4.1 tags/kdesupport-for-4.2 etc... what do you think? The first two don't make sense to me. If you mean that people should work in the code in one of them, then tags/ is really wrong. Maybe we also want to put all these in a single tags/kdesupport/ directory, I don't know. Most people (or kdesvn-build) will only check out one of them, two at most, so it doesn't really matter IMHO. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport rearrangement
2008/9/29, David Faure [EMAIL PROTECTED]: On Monday 29 September 2008, Benoit Jacob wrote: If we remove /trunk/kdesupport, then we can use the name kdesupport-for-trunk without any risk of confusion. I don't think we want to do that. People working on kdesupport (or fixing the occasional bug) expect it to be in trunk/kdesupport, it's the logical place for it. OK, I understand... now. I had misunderstood your proposal, I believed that by /tags/kdesupport-devel you meant the active development branch. OK now everything suddenly makes more sense :) Also, why couldn't we have /trunk/kdesupport-for-4.1etc. in parallel with these tags ? Well not in parallel with stable ;-) Then let's find another name :) what about /trunk/kdesupport-stable-for-trunk? Long but explicit. Feel free to suggest something more elegant. I propose: tags/kdesupport-devel tags/kdesupport-for-trunk (what we called kdesupport-stable) tags/kdesupport-for-4.1 tags/kdesupport-for-4.2 etc... what do you think? The first two don't make sense to me. If you mean that people should work in the code in one of them, then tags/ is really wrong. OK sure, I misunderstood what you proposed, see above. Summing up, we arrive at this proposal. From your proposal, it amounts to renaming kdesupport-devel to kdesupport-stable-for-trunk (the word stable here makes it clearer how it is different from /trunk/kdesupport, hopefully resolves the confusion) and renaming kdesupport-stable to kdesupport-for-x.y so multiple versions can coexist: /trunk/kdesupport for kdesupport development /tags/kdesupport-stable-for-trunk /tags/kdesupport-for-4.1 /tags/kdesupport-for-4.2 etc... Cheers, Benoit ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport rearrangement
On Monday 29 September 2008, Benoit Jacob wrote: /trunk/kdesupport for kdesupport development /tags/kdesupport-stable-for-trunk /tags/kdesupport-for-4.1 /tags/kdesupport-for-4.2 Looks fine to me. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport rearrangement
Great. By the way, looking back at Tom's original proposal, the only difference is renaming kdesupport-for-trunk to kdesupport-stable-for-trunk to reduce confusion with /trunk/kdesupport. 2008/9/29, David Faure [EMAIL PROTECTED]: On Monday 29 September 2008, Benoit Jacob wrote: /trunk/kdesupport for kdesupport development /tags/kdesupport-stable-for-trunk /tags/kdesupport-for-4.1 /tags/kdesupport-for-4.2 Looks fine to me. -- David Faure, [EMAIL PROTECTED], sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). ___ 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
Hi, 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) Why not svn:externals to either the last stable release (tag), or /branches with externals to the stable branches? -- Pino Toscano signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport rearrangement
There are a couple of issues with svn external... AFAIK relative svn externals (like ../../path) are only handled by SVN client = 1.5 absolute svn externals are a pain, they have to point to anonsvn which causes several issues, e.g. svn:// blocked by firewalls. I'm not an expert though! Cheers, Benoit 2008/9/29, Pino Toscano [EMAIL PROTECTED]: Hi, 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) Why not svn:externals to either the last stable release (tag), or /branches with externals to the stable branches? -- Pino Toscano ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport rearrangement
On Monday 29 September 2008 15:59:01 Benoit Jacob wrote: There are a couple of issues with svn external... AFAIK relative svn externals (like ../../path) are only handled by SVN client = 1.5 Since these tags are only for convenience anyway, what is the problem with requiring svn client = 1.5 for them to work correctly? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport rearrangement
Using these tags is going to be the recommended way of building KDE, with /trunk/kdesupport becoming only for kdesupport development and proactive testing by adventurous KDE developers. So we don't want to require svn = 1.5 until most people have it. Here on Kubuntu Hardy I have svn 1.4. Cheers, Benoit 2008/9/29, Marijn Kruisselbrink [EMAIL PROTECTED]: On Monday 29 September 2008 15:59:01 Benoit Jacob wrote: There are a couple of issues with svn external... AFAIK relative svn externals (like ../../path) are only handled by SVN client = 1.5 Since these tags are only for convenience anyway, what is the problem with requiring svn client = 1.5 for them to work correctly? ___ 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 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
