Re: KDE 3.5.final?
On Thursday 21 August 2008, Mark Constable wrote: Once 3.5.10 is released I intend to pull a copy into a Git repo and offer public accounts to anyone who wants to keep tinkering with it Whats the underlying reason for pulling it into a git repository instead of leaving it where it was the last few years? commits are still open to 3.5 branch, thats really unrelated to if the 3.5 branch will ever be *released* again. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE 4.1.1 tagging
Hi, KDE 4.1.1 tagging planned for Thursday morning (this week). I'd like to announce the usual wednesday 23:59 UTC rule and in light of the new bugzilla, I would like to use the kde-4.1.1-blocker keyword for tagging bugs that have to be fixed before 4.1.1 can be released. Any comments on that? Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Putting Playground in some order
On Tuesday 19 August 2008, Friedrich W. H. Kossebau wrote:
a) Projects which have been without a commit for more than five month are
moved to
tags/unmaintained/playground/$submodule/{3,4}
not really. playground is not maintained so moving stuff from playground to
unmaintained does not mean anything to me.
b) KDE3 based projects are moved to branches/playground/kde3/$submodule/
(cmp. branches/extragear/kde3/$submodule)
I think that makes sense.
So people are aware what is happening and do not continue to do things like
implementing three power manager applets independently, like currently
happening.
playground stuff is supposed to appear and disappear at any time, so attempts
at documenting them at utils.kde.org is either very time consuming or always
out of date. I'm not opposed to document playground stuff (quite the contrary),
but keeping the documentation at a completely different place (other than a
README within the subdirectory) is likely to run out of sync fairly soon
again.
How about enforcing (by policy) that each app/dir whatever must contain at
least a INFO or a README file that describes wht the purpose is, who is
working on it and who should be contacted regarding the code?
Greetings,
Dirk
___
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: KDE 3.5.final?
On Mon, 25 Aug 2008 08:43:11 pm Dirk Mueller wrote: Whats the underlying reason for pulling it into a git repository instead of leaving it where it was the last few years? Because I believe HEAD should be a persistent stable rolling release URL (always summer in trunk principle) with experiments in branches. Managing branches with git is much easier than svn. commits are still open to 3.5 branch, thats really unrelated to if the 3.5 branch will ever be *released* again. There seems to be quite some reluctance to allow anything much other than bugfixes and some, apparently, would like to see the 3.5 branch officially EOL'd sooner than later. We're prepared to put some effort and resources into making sure it retains some viability and vitality for at least another 12 months. --markc ___ 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: KDE 4.1.1 tagging
On Monday 25 August 2008 06:45:39 Dirk Mueller wrote: Hi, KDE 4.1.1 tagging planned for Thursday morning (this week). I'd like to announce the usual wednesday 23:59 UTC rule and in light of the new bugzilla, I would like to use the kde-4.1.1-blocker keyword for tagging bugs that have to be fixed before 4.1.1 can be released. Any comments on that? Nice. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Putting Playground in some order
On Monday 25 August 2008, Dirk Mueller wrote: How about enforcing (by policy) that each app/dir whatever must contain at least a INFO or a README file that describes wht the purpose is, who is working on it and who should be contacted regarding the code? Well, it's allready the case, each subdir contains an INDEX file which is supposed to contains the name of the apps, a description, authors and even a link to a webpage. But a lot of applications are missing in those INDEX files. -- Cyrille Berger ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 3.5.final?
On Monday 25 August 2008, Mark Constable wrote: On Mon, 25 Aug 2008 08:43:11 pm Dirk Mueller wrote: Whats the underlying reason for pulling it into a git repository instead of leaving it where it was the last few years? Because I believe HEAD should be a persistent stable rolling release URL (always summer in trunk principle) with experiments in branches. Managing branches with git is much easier than svn. another possibility might be to create another mainline in svn for 3.5 and just fold that back periodically. commits are still open to 3.5 branch, thats really unrelated to if the 3.5 branch will ever be *released* again. There seems to be quite some reluctance to allow anything much other than bugfixes and some, apparently, would like to see the 3.5 branch officially EOL'd sooner than later. We're prepared to put some effort and resources into making sure it retains some viability and vitality for at least another 12 months. personally i think that's cool .. it probably means finding someone to do release management, as the way i'm reading it Kulow is ready to be done with that =) but it seems that is nearly sorted out already, according to other emails in this thread. while it might be best to have everyone's hands on KDE4, it's also realistic that there will be those who remain interested in KDE3 for various reasons and there's no reason to try and control that beyond encouraging KDE4 to be the primary focus. as it already is for virtually the entire core project and KDE3 is certainly seen as a legacy maintenance project given all the development activity i currently see, i don't think this endangers KDE4 progress in any way. p.s. is we a company or an already-organized group of people, or the we that is working on 3.5 right now? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech 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: KDE 3.5.final?
Am Montag 25 August 2008 schrieb Aaron J. Seigo: while it might be best to have everyone's hands on KDE4, it's also realistic that there will be those who remain interested in KDE3 for various reasons and there's no reason to try and control that beyond encouraging KDE4 to be the primary focus. as it already is for virtually Actually I think the best way to let people focus on KDE4 is making sure KDE3 becomes unusable as stable platform in allowing untested experiments. Greetings, Stephan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 3.5.final?
On Monday 25 August 2008 08:35:02 Stephan Kulow wrote: Am Montag 25 August 2008 schrieb Aaron J. Seigo: while it might be best to have everyone's hands on KDE4, it's also realistic that there will be those who remain interested in KDE3 for various reasons and there's no reason to try and control that beyond encouraging KDE4 to be the primary focus. as it already is for virtually Actually I think the best way to let people focus on KDE4 is making sure KDE3 becomes unusable as stable platform in allowing untested experiments. At least I'm sure that KDAB tests kdepim changes and is around to help fix and port stuff. So people who need kdepim 3.5 could conceivably switch to the kdepim/enterprise branch. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 3.5.final?
Am Montag 25 August 2008 schrieb Allen Winter: On Monday 25 August 2008 08:35:02 Stephan Kulow wrote: Am Montag 25 August 2008 schrieb Aaron J. Seigo: while it might be best to have everyone's hands on KDE4, it's also realistic that there will be those who remain interested in KDE3 for various reasons and there's no reason to try and control that beyond encouraging KDE4 to be the primary focus. as it already is for virtually Actually I think the best way to let people focus on KDE4 is making sure KDE3 becomes unusable as stable platform in allowing untested experiments. At least I'm sure that KDAB tests kdepim changes and is around to help fix and port stuff. So people who need kdepim 3.5 could conceivably switch to the kdepim/enterprise branch. I don't have an issue with kdepim 3.5.17 being released. But I do have one with kdelibs or kdebase changes based on experiments. And actually kdepim was one of the modules I had to fix up before it would compile. Greetings, Stephan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1.1 tagging
Op maandag 25 augustus 2008 12:45 schreef u: Hi, KDE 4.1.1 tagging planned for Thursday morning (this week). I'd like to announce the usual wednesday 23:59 UTC rule and in light of the new bugzilla, I would like to use the kde-4.1.1-blocker keyword for tagging bugs that have to be fixed before 4.1.1 can be released. Any comments on that? Good idea. Toma___ 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: KDE 3.5.final?
A Dilluns 25 Agost 2008, Stephan Kulow va escriure: Am Montag 25 August 2008 schrieb Allen Winter: On Monday 25 August 2008 08:35:02 Stephan Kulow wrote: Am Montag 25 August 2008 schrieb Aaron J. Seigo: while it might be best to have everyone's hands on KDE4, it's also realistic that there will be those who remain interested in KDE3 for various reasons and there's no reason to try and control that beyond encouraging KDE4 to be the primary focus. as it already is for virtually Actually I think the best way to let people focus on KDE4 is making sure KDE3 becomes unusable as stable platform in allowing untested experiments. At least I'm sure that KDAB tests kdepim changes and is around to help fix and port stuff. So people who need kdepim 3.5 could conceivably switch to the kdepim/enterprise branch. I don't have an issue with kdepim 3.5.17 being released. But I do have one with kdelibs or kdebase changes based on experiments. And actually kdepim was one of the modules I had to fix up before it would compile. BTW Coolo went to the facts way and disable message extraction for all KDE modules of 3.5 except kdepim, so if we decide we let people still work on them, message extraction for translators should be reenabled. Albert Greetings, Stephan ___ 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: 4.2 and 4.3 release date reminder
On Aug 17, 2008, at 1:15 PM, Sebastian Kügler wrote: On Sunday 17 August 2008 17:19:06 Matt Rogers wrote I'm afraid I don't follow anything in the first paragraph after the first 20 words or so. Perhaps you could clarify a bit more? Next year's Akademy is one month earlier than this year's. This year, it worked rather nicely, being able to present 4.1 as done deal during Akademy and hacking away on the future. Next year, we'll clash. Potential problems: - release (or release preps) during Akademy (while Akademy is very busy for lots involved with the release team) - trunk in freeze (well, depending on our plans ;-)) during Akademy (while such meetings usually destabilize the codebase) - The wider community is closer to what developers run, making many PR things much easier So gradually shifting the release backward would allow us for the same nice timing as we had this year. On another note, it's rather cool we see this kind of issues nearly a year in advance already. Yay for plannability. I think you'd have to push back both the 4.2 and 4.3 release by like 2 or 3 weeks each in order to get this. I don't know what the 4.2 release schedule looks like, but I suppose we could push back 4.3 by 6 weeks or so, but i'm not sure that's a really good idea either. -- Matt ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Release schedule 4.2 and 4.3
Hi All, There was already a small thread about the 'problem' of next Akademy. To have the release done on 3rd of july 2009 and keep our 6 month cycle, we can push back 4.2 and 4.3 both with two weeks. So, I would propose the following change to the schedules of 4.2. Unfortunatly due to the holidays, i've made some more room between rc and final else it would get no testing at all... October 19th, 2008: Soft Feature Freeze - sep 29 October 21st, 2008: Tag KDE 4.2 Alpha 1 - sep 30 October 28th, 2008: Release KDE 4.2 Alpha 1 - okt 7 November 17th, 2008: Hard Feature Freeze - okt 27 November 18th, 2008: Message Freeze. - okt 28 November 18th, 2008: Tag KDE 4.2 Beta 1 - okt 28 November 25th, 2008: Release KDE 4.2 Beta 1 - nov 4 November 25th, 2008: Documentation/Handbook Freeze - nov 4 December 9th, 2008: Tag KDE 4.2 Beta 2 - nov 18 December 16th, 2008: Release KDE 4.2 Beta 2 - nov 25 January 6th, 2009: Artwork and Bindings Freeze - dec 9 January 6th, 2009: Tag KDE 4.2 RC 1 - dec 9 January 13th, 2009: Release KDE 4.2 RC 1 - dec 16 January 20th, 2009: Tag KDE 4.2 - jan 4 January 27th, 2009: Release KDE 4.2 - jan 13 I would like to propose the following schedule for 4.3. Basically the same as 4.1+1 year-1 month. March 17th, 2009: Soft Feature Freeze March 24nd, 2009: Tag KDE 4.3 Alpha 1 April 29th, 2009: Release KDE 4.3 Alpha 1 April 18th, 2009: Hard Feature Freeze April 21th, 2009: Message Freeze. April 21th, 2009: Tag KDE 4.3 Beta 1 April 28th, 2009: Release KDE 4.3 Beta 1 May 5th, 2009: Documentation/Handbook Freeze May 19th, 2009: Tag KDE 4.3 Beta 2 May 26th, 2009: Release KDE 4.3 Beta 2 June 9th, 2009: Artwork and Bindings Freeze June 9th, 2009: Tag KDE 4.3 RC 1 June 16th, 2009: Release KDE 4.3 RC 1 June 23nd, 2009: Tag KDE 4.3 June 30th, 2008: Release KDE 4.3 Let me know if there are objections I'll put it on techbase next week if no objections... Best, 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
