Re: kdesupport Policy
On Thursday 11 September 2008, Dirk Mueller wrote: Well what I was thinking is we could make a kdesupport 4.1 branch for instance to do the same thing. (unless you mean kdesupport-stable which simply tracks the latest stable release of KDE). It doesn't make sense to me - the software in kdesupport is not released on the same schedule like KDE, Yes, this is why the best solution is a kdesupport-for-4.1 directory with _tags_ of released kdesupport things, as others mentionned before. and often enough newer versions work just fine with older versions of KDE. But everyone was told to use branches/phonon/4.2 instead of phonon trunk, for kdelibs-4.1, and this created a lot of confusion, and scripted-builds breakage, etc. (OK the fact that one had to compile Qt with --no-phonon would have broken those scripts anyway, my main point is that having to switch to a different branch for each kdesupport software is too much hassle). Here's what I have in mind: tags/kdesupport-for-4.1/ 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) etc. Yes, just for convenience. Because nobody can remember 10 version numbers that keep changing, for things he's not working on :-) Whenever the developers of one of the above products fix bugs and want other kde developers/users to benefit from these fixes, they just have to make a new release (well, at least a new tag), and to update the copy in tags/kdesupport-for-4.1/ (svn rm + svn cp). I'd rather not use svn:externals for this, at least until svn.kde.org uses svn-1.5, it's currently too much trouble in many cases (slowness, firewalls, anonsvn being down, or auth issues if not using anonsvn). And this is where it gets better: if some kdesupport developers think everyone should just use their trunk, they could just regularly rm+cp the tag from their trunk (yes, -that- is where a nice relative external would be much better :) On the other hand, I believe we don't need this at all. tags/kdesupport-for-4.1 should be stable software, while kdelibs-trunk developers should be able to just use kdesupport trunk. But that's just my opinion, I'm fine with a tags/kdesupport-for-trunk solution pointing to last releases as well. -- 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 Policy
On Thursday 11 September 2008, Dirk Mueller wrote: that could have been solved in the source code with less work than this thread already took Done (at least 4.1-branch and trunk compile with both versions of strigi now) -- 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 Policy
On Tuesday 26 August 2008, Michael Pyne wrote: Well what I was thinking is we could make a kdesupport 4.1 branch for instance to do the same thing. (unless you mean kdesupport-stable which simply tracks the latest stable release of KDE). It doesn't make sense to me - the software in kdesupport is not released on the same schedule like KDE, and often enough newer versions work just fine with older versions of KDE. There are rare exceptions, like the horrific strigi backward incompatibility (that could have been solved in the source code with less work than this thread already took). And then a kdesupport/kde-trunk or something for /trunk development. Lets put it the other way around: not having the connection between kdesupport and KDE helps in a way that: a) cmake checks are excerized and updated to match the actual version requirements of the 3rd party packages we rely on, which in return helps users and packagers. b) distros can provide packages for KDE developers so that they do not have to build all of their system from scratch. c) software is in kdesupport because we want it to be easy to pick up for non- KDE projects (otherwise if is a KDE only dependency it should be in KDE). This also means that we should provide tarballs, documented release schedules, feature plans, compatibility matrixes for it etc. I think what is missing here is regular snapshots of things that should be used for /trunk development, and a timeline on when they're required (e.g. only on mondays). Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
Op dinsdag 26 augustus 2008 01:30 schreef u: That's correct. And if someone complains we can say that you are using a development version of Foo which is not supported in KDE yet. please remove that version and use the one from your distro instead... +1 for me. Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
On Tuesday 26 August 2008 01:30:06 Allen Winter wrote: That's correct. And if someone complains we can say that you are using a development version of Foo which is not supported in KDE yet. please remove that version and use the one from your distro instead... I'm not sure I will like this idea. First off, it will break many (all?) scripts, including the widely used kdesvn-build. Then, compiling kdesupport has always been great for me so that I didn't have to wonder around look for each individual subpackage (especially on distros that I do not know, or that are quite strict as far as backporting policy goes), but I simply had one more module to checkout/install like any other kde module. I'm ok by treating kdesupport as external dependency, less ok if I can't compile it anymore to build KDE. Bye, -Riccardo -- GPG key: 3D0F6376 When encrypting, please encrypt also for this subkey: 9EBD7FE1 - Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平 Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch שלום Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
On 2008-08-26, Riccardo Iaconelli wrote: That's correct. And if someone complains we can say that you are using a development version of Foo which is not supported in KDE yet. please remove that version and use the one from your distro instead... Different distro's have different versions of various packages according to how nimble and strict they are towards updates. It would only work if everyone used, say, Kbuntu 8.04.1 as a reference system... but that would upset eveyone else that did not. I'm not sure I will like this idea. First off, it will break many (all?) scripts, including the widely used kdesvn-build. It would most likely ruin my scripts ability to automatically build daily Archlinux packages. As a suggestion, all of trunk/kdesupport could probably be replaced with a single file, say trunk/KDE/kdesupport, that had an easily parsable and RELIABLY updated list of required dependencies plus the current expected version number... admin 1.1.1 akode 1.1.1 akonadi 1.1.1 automoc 1.1.1 cpptoxml 1.1.1 decibel 1.1.1 eigen 1.1.1 eigen2 1.1.1 emerge 1.1.1 kdewin-installer 1.1.1 kdewin32 1.1.1 phonon 1.1.1 qca 1.1.1 qimageblitz 1.1.1 soprano 1.1.1 strigi 1.1.1 taglib 1.1.1 tapioca-qt 1.1.1 telepathy-qt 1.1.1 twine 1.1.1 a 3rd field with the URL of the upstream source would be nice but at least something like the above would suffice. If this proved to be a workable solution then perhaps trunk/kdesupport/ could be removed altogether. --markc ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
On Tuesday 26 August 2008 06:01:34 Mark Constable wrote: On 2008-08-26, Riccardo Iaconelli wrote: That's correct. And if someone complains we can say that you are using a development version of Foo which is not supported in KDE yet. please remove that version and use the one from your distro instead... Different distro's have different versions of various packages according to how nimble and strict they are towards updates. It would only work if everyone used, say, Kbuntu 8.04.1 as a reference system... but that would upset eveyone else that did not. Sure, so the kdesupport devs need to give the distros and the developers fair warning time. They also need to tell us where to pick up stable source code so we can build ourselves. So maybe they need put up a website with tarballs. Or maybe they need to tells to use the version in branch. Or maybe their API matures over the years and it doesn't become such a big deal. etc. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
On Tuesday 26 August 2008, Allen Winter wrote: So maybe they need put up a website with tarballs. Or maybe they need to tells to use the version in branch. Or maybe their API matures over the years and it doesn't become such a big deal. etc. For people taking stuff from svn, for instance kdesvn users, couldn't there be a kdesupport tag of what is good to use with kde ? -- Cyrille Berger ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
On Tuesday 26 August 2008 11:54:34 Cyrille Berger wrote: On Tuesday 26 August 2008, Allen Winter wrote: So maybe they need put up a website with tarballs. Or maybe they need to tells to use the version in branch. Or maybe their API matures over the years and it doesn't become such a big deal. etc. For people taking stuff from svn, for instance kdesvn users, couldn't there be a kdesupport tag of what is good to use with kde ? yes, and the tags already exists for akonadi, decibel, kdewin-installer, phonon, qca, soprano, strigi, taglib ... We just need to start using the tags consistently and enforce them. For example, shouldn't Strigi 0.6.0 be tagged? and shouldn't that be the version compiled by the kdesvn-build scripts? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
On Tuesday 26 August 2008, Riccardo Iaconelli wrote: On Tuesday 26 August 2008 01:30:06 Allen Winter wrote: That's correct. And if someone complains we can say that you are using a development version of Foo which is not supported in KDE yet. please remove that version and use the one from your distro instead... I'm not sure I will like this idea. First off, it will break many (all?) scripts, including the widely used kdesvn-build. You can use the branch option to control what version of kdesupport you build. You also do not *need* to build kdesupport unless you need to install packages from it (which if only distro packages are required may not be necessary). If it really becomes a problem then we can copy the latest batch of release changes to a special kdesupport tag and just bump that as needed for use with the kdesvn-build tag option. i.e. phonon 4.2, strigi 0.5.10, etc. go into /tags/kdesupport/4.1.0 or something like that, a tag doesn't *have* to be a simple copy of some other branch, we can cherry pick into a tag as necessary. I'm ok by treating kdesupport as external dependency, less ok if I can't compile it anymore to build KDE. Yes, I think it should be possible to build kdesupport and have it work but it's not fair to those who just need one module to have to build more stuff out of SVN IMO. Regards, - Michael Pyne 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 Policy
On Tuesday 26 August 2008, Allen Winter wrote: On Tuesday 26 August 2008 11:54:34 Cyrille Berger wrote: On Tuesday 26 August 2008, Allen Winter wrote: So maybe they need put up a website with tarballs. Or maybe they need to tells to use the version in branch. Or maybe their API matures over the years and it doesn't become such a big deal. etc. For people taking stuff from svn, for instance kdesvn users, couldn't there be a kdesupport tag of what is good to use with kde ? yes, and the tags already exists for akonadi, decibel, kdewin-installer, phonon, qca, soprano, strigi, taglib ... We just need to start using the tags consistently and enforce them. If we intend to make it easy to say this is the kdesupport for kdesvn-build users then we need to copy those tags into a super-tag or something. i.e. /tags/kdesupport/latest-release would have cherry-picked subdirs of the latest phonon, strigi, qca, etc. releases from their appropriate tag or branch. As new releases occur the tag could be updated as well. For example, shouldn't Strigi 0.6.0 be tagged? and shouldn't that be the version compiled by the kdesvn-build scripts? Any release should be tagged. kdesvn-build right now defaults to trunk on everything, changing that wouldn't be too difficult but would require a new version of kdesvn-build. But if you want to go that route let me know so I can make a HOWTO bump kdesvn-build default modules type thing in case this occurs while I'm away. I guess another alternative is a file in SVN that kdesvn-build could parse for the revision/branch to build by default if there's no conf file. But I don't think I'll have time to write that code until 2009... Regards, - Michael Pyne 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 Policy
Op dinsdag 26 augustus 2008 22:12 schreef u: i.e. /tags/kdesupport/latest-release would have cherry-picked subdirs of the latest phonon, strigi, qca, etc. releases from their appropriate tag or branch. As new releases occur the tag could be updated as well. I like and support the idea of a certain tag that contains the kdesupport libs needed to build kde-stable branch. I think another tag would be needed for kde trunk though.___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
On Tuesday 26 August 2008, Tom Albers wrote: Op dinsdag 26 augustus 2008 22:12 schreef u: i.e. /tags/kdesupport/latest-release would have cherry-picked subdirs of the latest phonon, strigi, qca, etc. releases from their appropriate tag or branch. As new releases occur the tag could be updated as well. I like and support the idea of a certain tag that contains the kdesupport libs needed to build kde-stable branch. I think another tag would be needed for kde trunk though. Well what I was thinking is we could make a kdesupport 4.1 branch for instance to do the same thing. (unless you mean kdesupport-stable which simply tracks the latest stable release of KDE). And then a kdesupport/kde-trunk or something for /trunk development. If we think this is a good idea then we should probably get a list of required dependencies for each so that we can begin to track this. Regards, - Michael Pyne 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 Policy
On Saturday 23 August 2008, Allen Winter wrote: I think we need to treat kdesupport libs just like any other external dependency. The suggestion you describe is already our policy. If you refer to the strigi mess, then I think this should have been fixed with a cmake inducted #define to restore compatibility. I'd like to make a patch for that as I find time (thats a hard thing). Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
On Monday 25 August 2008 06:57:18 Dirk Mueller wrote: On Saturday 23 August 2008, Allen Winter wrote: I think we need to treat kdesupport libs just like any other external dependency. The suggestion you describe is already our policy. Ok, good to know. Let's please start being stricter about enforcement then. Examples: I don't recall seeing a in 30 days you will need Strigi 0.6.0 message There isn't an Akonadi package (at least in Fedora 9) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
Op zaterdag 23 augustus 2008 01:18 schreef u: Howdy, The recent build problems in our kdesupport package dependencies needs to be addressed. I think we need to treat kdesupport libs just like any other external dependency. Something like the following guidelines: No KDE code (in trunk) changes should be necessary until: - a real release of the kdesupport package has been made AN - that release has been packaged by the major distros AND - an announcement about the needed upgrade is made in advance AND - people have had time (30 days?) to upgrade to the new packages For example: libfoo v1.0 is released. kde-packagers are notified to please provide packages for their distros. kde-devel and kde-code-devel are notified that within 30 days their builds will fail unless they have libfoo v1.0 installed -- that the distros have been notified and we hope packages will start appearing soon. People wanting to develop against libfoo v1.0 will need to do so in a work branch. I need to get out of the habit of building kdesupport all the time -- we should be relying on distro packages where possible. Comments? Sure. That also means that kdesupport can be used as development tree for those applications. In other words, if you use kdesupport instead of distro packages, kdelibs might fail to build. Just wanting to make sure we agree. Toma ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
On Monday 25 August 2008 12:52:57 Tom Albers wrote: Op zaterdag 23 augustus 2008 01:18 schreef u: Howdy, The recent build problems in our kdesupport package dependencies needs to be addressed. I think we need to treat kdesupport libs just like any other external dependency. Something like the following guidelines: No KDE code (in trunk) changes should be necessary until: - a real release of the kdesupport package has been made AN - that release has been packaged by the major distros AND - an announcement about the needed upgrade is made in advance AND - people have had time (30 days?) to upgrade to the new packages For example: libfoo v1.0 is released. kde-packagers are notified to please provide packages for their distros. kde-devel and kde-code-devel are notified that within 30 days their builds will fail unless they have libfoo v1.0 installed -- that the distros have been notified and we hope packages will start appearing soon. People wanting to develop against libfoo v1.0 will need to do so in a work branch. I need to get out of the habit of building kdesupport all the time -- we should be relying on distro packages where possible. Comments? Sure. That also means that kdesupport can be used as development tree for those applications. In other words, if you use kdesupport instead of distro packages, kdelibs might fail to build. That's correct. And if someone complains we can say that you are using a development version of Foo which is not supported in KDE yet. please remove that version and use the one from your distro instead... ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
A Dissabte 23 Agost 2008, Allen Winter va escriure: Howdy, The recent build problems in our kdesupport package dependencies needs to be addressed. I think we need to treat kdesupport libs just like any other external dependency. Something like the following guidelines: No KDE code (in trunk) changes should be necessary until: - a real release of the kdesupport package has been made AN - that release has been packaged by the major distros AND - an announcement about the needed upgrade is made in advance AND - people have had time (30 days?) to upgrade to the new packages For example: libfoo v1.0 is released. kde-packagers are notified to please provide packages for their distros. kde-devel and kde-code-devel are notified that within 30 days their builds will fail unless they have libfoo v1.0 installed -- that the distros have been notified and we hope packages will start appearing soon. People wanting to develop against libfoo v1.0 will need to do so in a work branch. Or using nice #ifdefs like we do in okular with poppler. Albert I need to get out of the habit of building kdesupport all the time -- we should be relying on distro packages where possible. Comments? ___ 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 Policy
On Sunday 24 August 2008 10:16:22 Albert Astals Cid wrote: A Dissabte 23 Agost 2008, Allen Winter va escriure: Howdy, The recent build problems in our kdesupport package dependencies needs to be addressed. I think we need to treat kdesupport libs just like any other external dependency. Something like the following guidelines: No KDE code (in trunk) changes should be necessary until: - a real release of the kdesupport package has been made AN - that release has been packaged by the major distros AND - an announcement about the needed upgrade is made in advance AND - people have had time (30 days?) to upgrade to the new packages For example: libfoo v1.0 is released. kde-packagers are notified to please provide packages for their distros. kde-devel and kde-code-devel are notified that within 30 days their builds will fail unless they have libfoo v1.0 installed -- that the distros have been notified and we hope packages will start appearing soon. People wanting to develop against libfoo v1.0 will need to do so in a work branch. Or using nice #ifdefs like we do in okular with poppler. Sure. As long as we don't *require* people to upgrade to a new external package without a fair and timely notice. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
kdesupport Policy
Howdy, The recent build problems in our kdesupport package dependencies needs to be addressed. I think we need to treat kdesupport libs just like any other external dependency. Something like the following guidelines: No KDE code (in trunk) changes should be necessary until: - a real release of the kdesupport package has been made AN - that release has been packaged by the major distros AND - an announcement about the needed upgrade is made in advance AND - people have had time (30 days?) to upgrade to the new packages For example: libfoo v1.0 is released. kde-packagers are notified to please provide packages for their distros. kde-devel and kde-code-devel are notified that within 30 days their builds will fail unless they have libfoo v1.0 installed -- that the distros have been notified and we hope packages will start appearing soon. People wanting to develop against libfoo v1.0 will need to do so in a work branch. I need to get out of the habit of building kdesupport all the time -- we should be relying on distro packages where possible. Comments? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdesupport Policy
On Aug 22, 2008, at 6:18 PM, Allen Winter wrote: Howdy, The recent build problems in our kdesupport package dependencies needs to be addressed. I think we need to treat kdesupport libs just like any other external dependency. Something like the following guidelines: No KDE code (in trunk) changes should be necessary until: - a real release of the kdesupport package has been made AN - that release has been packaged by the major distros AND - an announcement about the needed upgrade is made in advance AND - people have had time (30 days?) to upgrade to the new packages For example: libfoo v1.0 is released. kde-packagers are notified to please provide packages for their distros. kde-devel and kde-code-devel are notified that within 30 days their builds will fail unless they have libfoo v1.0 installed -- that the distros have been notified and we hope packages will start appearing soon. People wanting to develop against libfoo v1.0 will need to do so in a work branch. I need to get out of the habit of building kdesupport all the time -- we should be relying on distro packages where possible. Comments? I was under the impression that was the policy already, so perhaps we just need to do a better job of educating people about the policy and enforcing it when necessary... -- Matt ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
