Re: [RFC] Draft Roadmap for KDE 4.0
Hello, On Wednesday 07 March 2007 21:54, Dirk Mueller wrote: > On Wednesday, 7. March 2007, Gunnar Schmi Dt wrote: > > I know that from an accessibility point of view it is necessary that > > KDE 4.0 depends on Qt 4.3 because the support for assistive > > technologies will only be available for that version. > > No, it means that KDE 4.0 + kde accessibility has to work with Qt 4.3. > it doesn't mean that it has to depend on it. Well, actually some parts of KDE have to depend on Qt 4.3. We speak about some code in the KDE libraries that provides accessibility information for those standard KDE widgets that are not based on similar Qt widgets (and also about code in each KDE application that provides the same accessibility information for their custom widgets). Qt 4.3 uses these accessibility information in order to inform assistive technologies (such as screen readers or screen magnifiers) what the user interface looks like. > But thanks for your concern. do you consider it an option that the kde > support for those assistive technologies is ready by the proposed > schedule deadlines? Implementing the accessibility information can only start after Qt 4.3 is released (because only then we know what the interfaces that are used in order to inform Qt about the accessibility information look like). Unfortunately, we currently have only very few developers in the KDE accessibility project, so we will need the help of other developers. Originally I wanted to use aKademy for implementing the accessibility information, but I guess that according to the proposed schedule this needs to be done earlier. In any case the the implementation of the accessibility information might not be the only field where the HCI working group wants to give feedback. I will write a mail to them, so that they are informed about our plans. Gunnar Schmi Dt -- Co-maintainer of the KDE Accessibility Project Maintainer of the kdeaccessibility package http://accessibility.kde.org/ pgpX8nmR7k9oo.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Wednesday 07 March 2007 18:46:35 Cornelius Schumacher wrote: > What's the problem with waiting with the announcement until we know what > the reaction from the community is and we were able to incorporate > feedback. The thing is that we want to avoid third parties to do their own interpretations of the release schedule, this often ends up in misinformation which is hard to get right again. We need to set correct expectation as early as possible, otherwise people will react disappointed, and that something I'd rather avoid. We can wait a bit, but preferably not too long. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Next the statesmen will invent cheap lies, putting the blame upon the nation that is attacked, and every man will be glad of those conscience-soothing falsities, and will diligently study them, and refuse to examine any refutations of them; and thus he will by and by convince himself that the war is just, and will thank God for the better sleep he enjoys after this process of grotesque self-deception. - Mark Twain pgpMTNcM5CZxM.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Wednesday 07 March 2007 23:11, Albert Astals Cid wrote: > KDE 4.0 has to depend on Qt 4.3, otherwise all our file dialogs that use > KHistoryCombo are broken because a bug in QComboBox that only got fixed in > Qt 4.3 Another reason would be QtScript IMHO. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On March 7, 2007, Dirk Mueller wrote: > On Saturday, 3. March 2007, Tom Albers wrote: > Thanks for your schedule proposal, and sorry for me following up on it > late, I was quite sick the last week and only now manage to catch up. sorry to hear =/ glad you're feeling better =) > A good milestone would be: > - no major subsystem / class set will be merged anymore for KDE 4.0 into > kdelibs. This especially means that all the plasma stuff, at least the > part that is ending up in 4.0, has to be in by that time. there is no plasma in kdelibs, nor is there intended to be. > schedule ;) BTW, we should split kdebase into base and workspace. split at what level? into separate packages on ftp.kde.org or schedule-wise or...? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 Full time KDE developer sponsored by Trolltech (http://www.trolltech.com) pgpyV220OEMa3.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
A Dimecres 07 Març 2007, Dirk Mueller va escriure: > On Wednesday, 7. March 2007, Gunnar Schmi Dt wrote: > > I know that from an accessibility point of view it is necessary that KDE > > 4.0 depends on Qt 4.3 because the support for assistive technologies will > > only be available for that version. > > No, it means that KDE 4.0 + kde accessibility has to work with Qt 4.3. it > doesn't mean that it has to depend on it. KDE 4.0 has to depend on Qt 4.3, otherwise all our file dialogs that use KHistoryCombo are broken because a bug in QComboBox that only got fixed in Qt 4.3 Albert > > > But thanks for your concern. do you consider it an option that the kde > support for those assistive technologies is ready by the proposed schedule > deadlines? > > > Dirk > ___ > 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: [RFC] Draft Roadmap for KDE 4.0
Hi Dirk, Many thanks for those points, I will make a new schedule in the weekend with all comments in there. I wanted to avoid 1st april as it's a special date, but that's not a real good reason ;-) Toma Op wo 7 mar 2007 21:52 schreef u: > On Saturday, 3. March 2007, Tom Albers wrote: > > Hi Tom, > > Thanks for your schedule proposal, and sorry for me following up on it late, > I > was quite sick the last week and only now manage to catch up. > > > kdelibs soft api freeze + alpha1 release- 2 April > > This is the the point where kdelibs api is frozen. That means that the > > classes and interfaces are not allowed to change anymore. That means the > > end of the famous bic Mondays. > > I'm fine with the date, but I wouldn't restrict binary compatibility as the > first thing. binary compatibility is not of a big concern during development. > > A good milestone would be: > - no major subsystem / class set will be merged anymore for KDE 4.0 into > kdelibs. This especially means that all the plasma stuff, at least the part > that is ending up in 4.0, has to be in by that time. > > BTW, since its again this year: I would like to release alpha1 on April 1st. > that means tagging a week before that. > > > kdelibs is also i18n frozen, exceptions can be asked on kde-i18n > > mailinglist. The release will not include translations. > > freezing i18n on kdelibs doesn't make sense. there isn't much i18n there. it > would be better to define a freeze date for the "desktop", that is workspace > and everything it depends on. > > > feature freeze - 2 may > > After this date the kde main modules are frozen for new features. No new > > features are allowed, the focus is from now on on stabilizing the > > applications and fix all bugs. This is also the date that all the > > maintainers of the main kde modules need to indicate if they will follow > > this schedule or will divert and will not be released together with kde > > 4.0. > > what are the main modules and what is part of KDE 4.0 ? for example it would > be a bad idea if kdebase or kdepimlibs is going to divert from the > schedule ;) BTW, we should split kdebase into base and workspace. > > > message freeze - 2 June > > After this date the main modules are frozen for new messages. Exceptions > > can be asked on kde-i18n mailinglist. > > message freeze before beta1 doesn't make sense. message changes have to > incorporate testing feedback. therefore message freeze should be around > beta2, not before beta1. > > > >From this date on every month a beta version will be published, this will > > > be repeated until most grave bugs are resolved. Translations are included > > > from the second beta. kdelibs api is now frozen. > > release candidate cycle starts, total release freeze. - 2 September > > > A RC will be released. If there is no grave bug in that release, kde 4.0 > > will be released, else new release candidates will be released every month. > > A month is too much for a release candidate. if we're confident that it is > good enough for a .0 release, then two weeks is usually enough. > > > When the first release candidate there is a total release freeze active. > > This means that you can fix serious bug reports but nothing else. > > "serious" isn't a very clear term. I would prefer to call it "regression > fixes > only". if it was broken with 3.5.x, then so be it. > > > KDE 4.0 - 2 October > > This is a bit ambitious, but I'm totally fine with it as a target. We'll > eventually have to slip it anyway a little. > > Greetings, > Dirk > ___ > 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: [RFC] Draft Roadmap for KDE 4.0
On Wednesday, 7. March 2007, Gunnar Schmi Dt wrote: > I know that from an accessibility point of view it is necessary that KDE > 4.0 depends on Qt 4.3 because the support for assistive technologies will > only be available for that version. No, it means that KDE 4.0 + kde accessibility has to work with Qt 4.3. it doesn't mean that it has to depend on it. But thanks for your concern. do you consider it an option that the kde support for those assistive technologies is ready by the proposed schedule deadlines? Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Saturday, 3. March 2007, Tom Albers wrote: Hi Tom, Thanks for your schedule proposal, and sorry for me following up on it late, I was quite sick the last week and only now manage to catch up. > kdelibs soft api freeze + alpha1 release - 2 April > This is the the point where kdelibs api is frozen. That means that the > classes and interfaces are not allowed to change anymore. That means the > end of the famous bic Mondays. I'm fine with the date, but I wouldn't restrict binary compatibility as the first thing. binary compatibility is not of a big concern during development. A good milestone would be: - no major subsystem / class set will be merged anymore for KDE 4.0 into kdelibs. This especially means that all the plasma stuff, at least the part that is ending up in 4.0, has to be in by that time. BTW, since its again this year: I would like to release alpha1 on April 1st. that means tagging a week before that. > kdelibs is also i18n frozen, exceptions can be asked on kde-i18n > mailinglist. The release will not include translations. freezing i18n on kdelibs doesn't make sense. there isn't much i18n there. it would be better to define a freeze date for the "desktop", that is workspace and everything it depends on. > feature freeze- 2 may > After this date the kde main modules are frozen for new features. No new > features are allowed, the focus is from now on on stabilizing the > applications and fix all bugs. This is also the date that all the > maintainers of the main kde modules need to indicate if they will follow > this schedule or will divert and will not be released together with kde > 4.0. what are the main modules and what is part of KDE 4.0 ? for example it would be a bad idea if kdebase or kdepimlibs is going to divert from the schedule ;) BTW, we should split kdebase into base and workspace. > message freeze- 2 June > After this date the main modules are frozen for new messages. Exceptions > can be asked on kde-i18n mailinglist. message freeze before beta1 doesn't make sense. message changes have to incorporate testing feedback. therefore message freeze should be around beta2, not before beta1. > >From this date on every month a beta version will be published, this will > > be repeated until most grave bugs are resolved. Translations are included > > from the second beta. kdelibs api is now frozen. > release candidate cycle starts, total release freeze. - 2 September > A RC will be released. If there is no grave bug in that release, kde 4.0 > will be released, else new release candidates will be released every month. A month is too much for a release candidate. if we're confident that it is good enough for a .0 release, then two weeks is usually enough. > When the first release candidate there is a total release freeze active. > This means that you can fix serious bug reports but nothing else. "serious" isn't a very clear term. I would prefer to call it "regression fixes only". if it was broken with 3.5.x, then so be it. > KDE 4.0 - 2 October This is a bit ambitious, but I'm totally fine with it as a target. We'll eventually have to slip it anyway a little. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
Hello, On Wednesday 07 March 2007 14:59, Tom Albers wrote: > [...] I shall compose a 'definite' schedule based on my > first mail with some small changes requested in this thread. I will > probably do that this evening, so we can iron out any remaining issues > and prepare the mail to kde-core-devel. I want to suggest that we also write a mail to the HCI workgroup ([EMAIL PROTECTED]) in order to adjust the schedule to the needs of the usability and accessibility people. I know that from an accessibility point of view it is necessary that KDE 4.0 depends on Qt 4.3 because the support for assistive technologies will only be available for that version. (Does anyone know when Trolltech plans to release Qt 4.3?) There might be other things that need to be implemented in the libs for the human-interface-guidelines. Gunnar Schmi Dt -- Co-maintainer of the KDE Accessibility Project Maintainer of the kdeaccessibility package http://accessibility.kde.org/ pgpxlgZXOiyVC.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Wednesday, 7. March 2007, Stephan Kulow wrote: > Kind of. KDE 2.0 was late, KDE 3.0 crap. Pick your poison :) Well, if you call KDE 3.0 crap, then 2.0 was a desaster. I think 3.0 was better scheduled than 2.0, and 2.0 was more than over a year late. Well, needless to say that 4.0 is already a year late. Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On March 7, 2007, Cornelius Schumacher wrote: > > Does that address your concerns? > > No. Announcing the schedule on the dot without giving the community an > opportunity to comment before would be pretty bad style for my taste. agreed. as for the beta cycle, july 2nd is a bad date imho as that is right in the middle of akademy. i could see us doing a beta release right prior to akademy[1] and then another mid july. this would allow us to use akademy to tighten things up nicely. mid-june could be an alpha (as opposed to the developer snapshots) which would allow us to identify sore spots which would then be the focus for akademy; beta 1 would end up july 15th or somewhere in there reflecting that progress. sorry i didn't notice that conflict of dates (july 2nd being middle-of-akademy) sooner =/ [1] june 18 is my birthday ;) "we're gonna party, like it's your birthday.. we're gonna party, shorty, like it's your birthday!" -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 Full time KDE developer sponsored by Trolltech (http://www.trolltech.com) pgp0KhwzHTBQ1.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Wednesday 07 March 2007 18:32, Sebastian Kügler wrote: > On Wednesday 07 March 2007 18:24:27 Cornelius Schumacher wrote: > > On Wednesday 07 March 2007 18:11, Tom Albers wrote: > > > Ok. I don't think I'm any good in writing a dot article anticipating on > > > that. How should we proceed with that? > > > > Shouldn't we wait with the dot article until the plan was presented on > > core-devel and fedback from the community was incorporated? Announcing > > something and then having to change it and announce it again sounds like > > a bad idea to me. > > We won't know when the actual release is until it's released. Every roadmap > we make is a preliminary one, and it'll be announced as that. > > Does that address your concerns? No. Announcing the schedule on the dot without giving the community an opportunity to comment before would be pretty bad style for my taste. Of course the schedule might change later, because we realize over time that some things need more time than expected etc., but it really shouldn't change because you forgot to ask the people whose software you will release before announcing the schedule. What's the problem with waiting with the announcement until we know what the reaction from the community is and we were able to incorporate feedback. -- Cornelius Schumacher <[EMAIL PROTECTED]> ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Wednesday 07 March 2007 18:24:27 Cornelius Schumacher wrote: > On Wednesday 07 March 2007 18:11, Tom Albers wrote: > > Ok. I don't think I'm any good in writing a dot article anticipating on > > that. How should we proceed with that? > > Shouldn't we wait with the dot article until the plan was presented on > core-devel and fedback from the community was incorporated? Announcing > something and then having to change it and announce it again sounds like a > bad idea to me. We won't know when the actual release is until it's released. Every roadmap we make is a preliminary one, and it'll be announced as that. Does that address your concerns? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Patriotism is the virtue of the vicious. - Oscar Wilde pgpeei9uqyCV5.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Wednesday 07 March 2007 18:11:41 Tom Albers wrote: > At Wednesday 07 March 2007 15:05, you wrote: > > On Wednesday 07 March 2007 14:59:59 Tom Albers wrote: > > > At Wednesday 07 March 2007 12:59, you wrote: > > > > > Coolo, can you tell us if the impact on the translations is big? > > > > > > > > kdelibs has hardly enough messages to justify an extra kdelibs > > > > message freeze if you as me. > > > > > > thanks for the info. > > > > > > I'll remove that bit. I shall compose a 'definite' schedule based on my > > > first mail with some small changes requested in this thread. I will > > > probably do that this evening, so we can iron out any remaining issues > > > and prepare the mail to kde-core-devel. > > > > We should also announce this on the Dot. People *will* start discussing > > this in public, and before all kinds of random guesses are being made, we > > should think about what those may be and address them in some kind of > > official announcement of the release schedule. > > Ok. I don't think I'm any good in writing a dot article anticipating on > that. How should we proceed with that? Let me know when you want to send the email out, I'll try to whip something up for the dot then. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - You can't go around building a better world for people. Only people can build a better world for people. Otherwise it's just a cage. - Terry Pratchett pgpWamXN8nAfw.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Wednesday 07 March 2007 18:16:30 Boudewijn Rempt wrote: > On Wednesday 07 March 2007, Tom Albers wrote: > > At Tuesday 06 March 2007 10:41, you wrote: > > > On Tuesday 06 March 2007, Stephan Kulow wrote: > > > > I like Tom's approach: Define a roadmap with milestones and set dates > > > > to it. If a milestone slips, define if you don't care about the > > > > milestone or the date. > > > > > > AOL. People work towards a date: right now we're way too much in > > > tinker-tinker mode. It's fun to hack, it's fun to get publicity and > > > we're avoiding all the nastiness of actually having people have our > > > software on their computers. But for me, as an application hacker, > > > kdelibs is good enough. Isn't most of the cleanup work done? At least > > > that's my impression. Let it stabilize, define a mechanism to add more > > > functionality later -- so the platform can grow after the release > > > without breaking old applications. And Tom's milestones look good to > > > me, although I think the day for the first beta (or alpha, I'm not > > > particular) should be June 30. > > > > What's with that day? > > That's akademy -- but this mail fo mine was written long before the > discussion started and was somehow held up, so feel free to ignore. Releasing something on that day doesn't make much sense to me. The people who are supposed to do the actual release will be travelling anyway. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mknod. war. pgpMHxXtzlXhI.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Wednesday 07 March 2007 18:11, Tom Albers wrote: > > Ok. I don't think I'm any good in writing a dot article anticipating on > that. How should we proceed with that? Shouldn't we wait with the dot article until the plan was presented on core-devel and fedback from the community was incorporated? Announcing something and then having to change it and announce it again sounds like a bad idea to me. -- Cornelius Schumacher <[EMAIL PROTECTED]> ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Wednesday 07 March 2007, Tom Albers wrote: > At Tuesday 06 March 2007 10:41, you wrote: > > On Tuesday 06 March 2007, Stephan Kulow wrote: > > > I like Tom's approach: Define a roadmap with milestones and set dates > > > to it. If a milestone slips, define if you don't care about the > > > milestone or the date. > > > > AOL. People work towards a date: right now we're way too much in > > tinker-tinker mode. It's fun to hack, it's fun to get publicity and we're > > avoiding all the nastiness of actually having people have our software on > > their computers. But for me, as an application hacker, kdelibs is good > > enough. Isn't most of the cleanup work done? At least that's my > > impression. Let it stabilize, define a mechanism to add more > > functionality later -- so the platform can grow after the release without > > breaking old applications. And Tom's milestones look good to me, although > > I think the day for the first beta (or alpha, I'm not particular) should > > be June 30. > > What's with that day? That's akademy -- but this mail fo mine was written long before the discussion started and was somehow held up, so feel free to ignore. -- Boudewijn Rempt http://www.valdyas.org/fading/index.cgi pgpEufdiOqC5L.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
At Wednesday 07 March 2007 15:05, you wrote: > On Wednesday 07 March 2007 14:59:59 Tom Albers wrote: > > At Wednesday 07 March 2007 12:59, you wrote: > > > > Coolo, can you tell us if the impact on the translations is big? > > > > > > kdelibs has hardly enough messages to justify an extra kdelibs message > > > freeze if you as me. > > > > thanks for the info. > > > > I'll remove that bit. I shall compose a 'definite' schedule based on my > > first mail with some small changes requested in this thread. I will > > probably do that this evening, so we can iron out any remaining issues and > > prepare the mail to kde-core-devel. > > We should also announce this on the Dot. People *will* start discussing this > in public, and before all kinds of random guesses are being made, we should > think about what those may be and address them in some kind of official > announcement of the release schedule. Ok. I don't think I'm any good in writing a dot article anticipating on that. How should we proceed with that? Toma -- http://www.mailody.net___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Wednesday 07 March 2007 9:05:39 am Sebastian Kügler wrote: > On Wednesday 07 March 2007 14:59:59 Tom Albers wrote: > > At Wednesday 07 March 2007 12:59, you wrote: > > > > Coolo, can you tell us if the impact on the translations is big? > > > > > > kdelibs has hardly enough messages to justify an extra kdelibs message > > > freeze if you as me. > > > > thanks for the info. > > > > I'll remove that bit. I shall compose a 'definite' schedule based on my > > first mail with some small changes requested in this thread. I will > > probably do that this evening, so we can iron out any remaining issues and > > prepare the mail to kde-core-devel. > > We should also announce this on the Dot. People *will* start discussing this > in public, and before all kinds of random guesses are being made, we should > think about what those may be and address them in some kind of official > announcement of the release schedule. Agreed. I've been babbling about it in #kontact a lot today. Also, toma, may I suggest that you give some love to http://techbase.kde.org/Schedules/KDE_4.0_Release_Schedule and the old 4.0 release plan at http://developer.kde.org/development-versions/kde-4.0-release-plan.html should be removed (or replaced by "see techbase") -- KDEPIM Developer I accept PayPal payments to [EMAIL PROTECTED] ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
At Tuesday 06 March 2007 10:41, you wrote: > On Tuesday 06 March 2007, Stephan Kulow wrote: > > > I like Tom's approach: Define a roadmap with milestones and set dates to > > it. If a milestone slips, define if you don't care about the milestone or > > the date. > > AOL. People work towards a date: right now we're way too much in > tinker-tinker > mode. It's fun to hack, it's fun to get publicity and we're avoiding all the > nastiness of actually having people have our software on their computers. But > for me, as an application hacker, kdelibs is good enough. Isn't most of the > cleanup work done? At least that's my impression. Let it stabilize, define a > mechanism to add more functionality later -- so the platform can grow after > the release without breaking old applications. And Tom's milestones look good > to me, although I think the day for the first beta (or alpha, I'm not > particular) should be June 30. What's with that day? Toma -- http://www.mailody.net___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007, Stephan Kulow wrote: > I like Tom's approach: Define a roadmap with milestones and set dates to > it. If a milestone slips, define if you don't care about the milestone or > the date. AOL. People work towards a date: right now we're way too much in tinker-tinker mode. It's fun to hack, it's fun to get publicity and we're avoiding all the nastiness of actually having people have our software on their computers. But for me, as an application hacker, kdelibs is good enough. Isn't most of the cleanup work done? At least that's my impression. Let it stabilize, define a mechanism to add more functionality later -- so the platform can grow after the release without breaking old applications. And Tom's milestones look good to me, although I think the day for the first beta (or alpha, I'm not particular) should be June 30. Sometimes I'm thinking that koffice2 will be ready before kde4... My own deadline for a presentable Krita 2.0, by the way, is May 5th, because then Cyrille and me are going to present it at the Libre Graphics Meeting. -- Boudewijn Rempt http://www.valdyas.org/fading/index.cgi pgpWbxqw1drX8.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Wednesday 07 March 2007 14:59:59 Tom Albers wrote: > At Wednesday 07 March 2007 12:59, you wrote: > > > Coolo, can you tell us if the impact on the translations is big? > > > > kdelibs has hardly enough messages to justify an extra kdelibs message > > freeze if you as me. > > thanks for the info. > > I'll remove that bit. I shall compose a 'definite' schedule based on my > first mail with some small changes requested in this thread. I will > probably do that this evening, so we can iron out any remaining issues and > prepare the mail to kde-core-devel. We should also announce this on the Dot. People *will* start discussing this in public, and before all kinds of random guesses are being made, we should think about what those may be and address them in some kind of official announcement of the release schedule. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I don't know what weapons World War Three will be fought with, but World War four will be fought with sticks and stones. - Albert Einstein pgpGK9qaElRHY.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
At Wednesday 07 March 2007 12:59, you wrote: > Am Dienstag 06 März 2007 schrieb Tom Albers: > > Op di 6 mar 2007 23:07 schreef u: > > > the message freeze also seems a bit soon. would it be possible to match > > > the string freeze with the beta freeze? there is so much potential for UI > > > change with 4.0 (and a lot has already changed) that committing earlier > > > rather than later might be a bit more difficult than usual. > > > > I'm not sure, but since the i18n system has changed a bit, we need to give > > the translators some time. But I'm not sure how much impact the changes > > have on the amount of fuzzies. One of the reasons I've proposed a kdelibs > > messagefreeze a bit earlier, so translators can start with that. > > > > Coolo, can you tell us if the impact on the translations is big? > kdelibs has hardly enough messages to justify an extra kdelibs message freeze > if you as me. thanks for the info. I'll remove that bit. I shall compose a 'definite' schedule based on my first mail with some small changes requested in this thread. I will probably do that this evening, so we can iron out any remaining issues and prepare the mail to kde-core-devel. Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
Am Dienstag 06 März 2007 schrieb Tom Albers: > Op di 6 mar 2007 23:07 schreef u: > > the message freeze also seems a bit soon. would it be possible to match > > the string freeze with the beta freeze? there is so much potential for UI > > change with 4.0 (and a lot has already changed) that committing earlier > > rather than later might be a bit more difficult than usual. > > I'm not sure, but since the i18n system has changed a bit, we need to give > the translators some time. But I'm not sure how much impact the changes > have on the amount of fuzzies. One of the reasons I've proposed a kdelibs > messagefreeze a bit earlier, so translators can start with that. > > Coolo, can you tell us if the impact on the translations is big? kdelibs has hardly enough messages to justify an extra kdelibs message freeze if you as me. But during the months KDE4 wasn't tracked by developers, kdelibs collected (for German) 4.6% fuzzy and 4.5% untranslated stings - less than 900 strings all together. Greteings, Stephan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
Am Dienstag 06 März 2007 schrieb Alexander Dymo: > On Tuesday 06 March 2007 22:58, Alexander Dymo wrote: > > So my question is who is going to use KDE 4.0 we're going to > > release in October? > > I must admit here my understanding of KDE .0 release goal is limited. > Did we have similar problems during 2.0 or 3.0 development? > Were similar decisions already made? Kind of. KDE 2.0 was late, KDE 3.0 crap. Pick your poison :) Greetings, Stephan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
Op di 6 mar 2007 23:07 schreef u: > the message freeze also seems a bit soon. would it be possible to match the > string freeze with the beta freeze? there is so much potential for UI change > with 4.0 (and a lot has already changed) that committing earlier rather than > later might be a bit more difficult than usual. I'm not sure, but since the i18n system has changed a bit, we need to give the translators some time. But I'm not sure how much impact the changes have on the amount of fuzzies. One of the reasons I've proposed a kdelibs messagefreeze a bit earlier, so translators can start with that. Coolo, can you tell us if the impact on the translations is big? Toma ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On March 6, 2007, Tom Albers wrote: > asap - kdelibs want to freeze after akademy, app developers before akademy as someone who touches libs now and again, i'm happy with a freeze before akademy. coolo too, it seems, and i -think- he occassionally has patches for kdelibs ;) > tell me concrete what to change to make everyone happy the only change i'd suggest is the freeze date 1 month after the announcement. it's a nice round number; less than a month will (for even purely psych reasons) receive more pushback imho. so if the announcement went out today, make the freeze on the 4th of march. perhaps announcing on monday would be best, which would put the freeze on the 9th. i won't cry either way, but the above would make me feel the happiest inside. =) the message freeze also seems a bit soon. would it be possible to match the string freeze with the beta freeze? there is so much potential for UI change with 4.0 (and a lot has already changed) that committing earlier rather than later might be a bit more difficult than usual. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 Full time KDE developer sponsored by Trolltech (http://www.trolltech.com) pgpj9AgkiiP4N.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007 4:34:47 pm Aaron J. Seigo wrote: > On March 6, 2007, Andras Mantia wrote: > > On Tuesday 06 March 2007, Cornelius Schumacher wrote: > > > On Tuesday 06 March 2007 19:26, Andras Mantia wrote: > > > > But actually I find the "one month from now freeze of KDE api" a > > > > little bit unrealistic. I'd say 3 months might be better to start > > > > the freeze cycle. > > > > > > Could you elaborate what's unrealistic about that? What exactly would > > > be done in the extra two months? > > > > I have this feeling just by looking at the threads on core-devel: > > knetwork, KStringDataListModel, strigi, kuiserver or knewstuff2. I may > > be wrong and the issues discussed there could be solved in a month, > > unfortunately I couldn't read everything in detail. > > some of these things can be added in 4.1; for example: we can even ship > knewstuff as deprecated, with the replacement slated for 4.1. > > on the other other hand, without such a date people will just continue to > tinker and twiddle. and yes, it gives me the heebie jeebies to commit to a > date that near, too, but that will never change. ;) > > and that's the important thing to remember: we could write software for the > next 5 years without a release for one reason or another. it's time to > release: early and often. > > someone said that kde isn't a corporate project, and they are right. it is > completely ok for us to release a 4.0 that has libs and most apps with lots > of improvements to come in 4.1. > > 3.5.x is perfect for stable deployments for now; we need to get 4.0 out there > so it can be as well, sooner rather than later. keeping it unreleased will > only delay that. > I'm OK with toma's original roadmap. There won't be a fully functional akonadi. There may not be a working kmail4.0 or a korganizer4.0, but even an extra 6-12months won't help the manpower issues in kdepim. I will announce on the kde-pim ML that have less than 4 weeks to get kdepimlibs and akonadi in much better shape. -Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On March 6, 2007, Andras Mantia wrote: > On Tuesday 06 March 2007, Cornelius Schumacher wrote: > > On Tuesday 06 March 2007 19:26, Andras Mantia wrote: > > > But actually I find the "one month from now freeze of KDE api" a > > > little bit unrealistic. I'd say 3 months might be better to start > > > the freeze cycle. > > > > Could you elaborate what's unrealistic about that? What exactly would > > be done in the extra two months? > > I have this feeling just by looking at the threads on core-devel: > knetwork, KStringDataListModel, strigi, kuiserver or knewstuff2. I may > be wrong and the issues discussed there could be solved in a month, > unfortunately I couldn't read everything in detail. some of these things can be added in 4.1; for example: we can even ship knewstuff as deprecated, with the replacement slated for 4.1. on the other other hand, without such a date people will just continue to tinker and twiddle. and yes, it gives me the heebie jeebies to commit to a date that near, too, but that will never change. ;) and that's the important thing to remember: we could write software for the next 5 years without a release for one reason or another. it's time to release: early and often. someone said that kde isn't a corporate project, and they are right. it is completely ok for us to release a 4.0 that has libs and most apps with lots of improvements to come in 4.1. 3.5.x is perfect for stable deployments for now; we need to get 4.0 out there so it can be as well, sooner rather than later. keeping it unreleased will only delay that. other projects to look at: samba with the 3 vs 4 split; ruby with their new engine; linux at the 2.4.0 release. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 Full time KDE developer sponsored by Trolltech (http://www.trolltech.com) pgptxzxycdtgA.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
At Tuesday 06 March 2007 21:58, you wrote: > On Tuesday 06 March 2007 21:45, Boudewijn Rempt wrote: > > I think that's splitting straws -- it's not important compared to getting a > > schedule and getting people out of tinker mode and into release mode. > C'mon, that sounds like KDE is now a commercial company that promised > the customers to deliver and now is trying to release whatever crap they have. > KDE4 with such schedule reminds me classical death march project. > > Sorry, Coolo ;) I can't stop too. Seriously, who wants KDE 4.0 with unfinished > BIC kdelibs with no applications? Users? They won't care about the desktop > without applications. Application developers? They don't need a release to > be productive, just more or less stable environment. > > So my question is who is going to use KDE 4.0 we're going to > release in October? Let's work towards something that is a workable compromise between all interests. We all understand that: - kdelibs developers want a freeze as far away as possible, app developers asap - kdelibs want to freeze after akademy, app developers before akademy Now lets get back to my original post and tell me concrete what to change to make everyone happy ;-) Toma -- http://www.mailody.net___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007, Alexander Dymo wrote: > On Tuesday 06 March 2007 21:45, Boudewijn Rempt wrote: > > I think that's splitting straws -- it's not important compared to getting > > a schedule and getting people out of tinker mode and into release mode. > > C'mon, that sounds like KDE is now a commercial company that promised > the customers to deliver and now is trying to release whatever crap they > have. KDE4 with such schedule reminds me classical death march project. No, it's the way any software project works. You can be in tinker mode or in release mode, but you'll never release if you don't get out of tinker mode. It has nothing to do with customers, it has nothing to do with commercial companies. If your goal is a release, you'll have to work towards a release. Get into release mode. Start finishing stuff. Three months always sounds long enough to finish your stuff, long away enough that you don't need to think of actually wrapping up, but can continue doing fun stuff like starting all over and Doing It Right This Time. Slipping time and again is just as bad for a real software project as it is for a commercial software project. It's impossible to get a project the size of kde (even if you take just kdelibs + kdebase) really perfect so that no api needs to break, all documentation is in place, everything tinkerty-tonk. For me, as an app developer, kdelibs is Good Enough. Sure, liveui or whatever it is called would have been nice, but if it cannot be ready in a month, it won't be ready. If the various api owners can't get their api's sorted out in a month, they won't get it sorted out in three months. > Sorry, Coolo ;) I can't stop too. Seriously, who wants KDE 4.0 with > unfinished BIC kdelibs with no applications? Users? They won't care about > the desktop without applications. Application developers? They don't need a > release to be productive, just more or less stable environment. They need a release to code against. And they need a release to be able to release their applications. It's going to be awfully funny if Krita 2.0, which _is_ going to be released this year, needs its own private copy of kdelibs. > So my question is who is going to use KDE 4.0 we're going to > release in October? KDE developers, application developers, bleeding edge fanatics and Mandriva users. -- Boudewijn Rempt http://www.valdyas.org/fading/index.cgi pgpreDsCkwGG4.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007 21:58, Alexander Dymo wrote: > > Sorry, Coolo ;) I can't stop too. Seriously, who wants KDE 4.0 with > unfinished BIC kdelibs with no applications? Users? They won't care about > the desktop without applications. Application developers? They don't need a > release to be productive, just more or less stable environment. 3rd party application developers need a stable release. Otherwise they won't be able to release their applications, because the libraries they depend on aren't available at least not as stable versions. There are application developers which go for pure Qt versions of their applications and stop using KDE for that reason. That's really nothing we want to see. -- Cornelius Schumacher <[EMAIL PROTECTED]> ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007 22:58, Alexander Dymo wrote: > So my question is who is going to use KDE 4.0 we're going to > release in October? I must admit here my understanding of KDE .0 release goal is limited. Did we have similar problems during 2.0 or 3.0 development? Were similar decisions already made? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007, Cornelius Schumacher wrote: > On Tuesday 06 March 2007 19:26, Andras Mantia wrote: > > But actually I find the "one month from now freeze of KDE api" a > > little bit unrealistic. I'd say 3 months might be better to start > > the freeze cycle. > > Could you elaborate what's unrealistic about that? What exactly would > be done in the extra two months? I have this feeling just by looking at the threads on core-devel: knetwork, KStringDataListModel, strigi, kuiserver or knewstuff2. I may be wrong and the issues discussed there could be solved in a month, unfortunately I couldn't read everything in detail. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org pgp0IYsbyF5E8.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007 21:45, Boudewijn Rempt wrote: > I think that's splitting straws -- it's not important compared to getting a > schedule and getting people out of tinker mode and into release mode. C'mon, that sounds like KDE is now a commercial company that promised the customers to deliver and now is trying to release whatever crap they have. KDE4 with such schedule reminds me classical death march project. Sorry, Coolo ;) I can't stop too. Seriously, who wants KDE 4.0 with unfinished BIC kdelibs with no applications? Users? They won't care about the desktop without applications. Application developers? They don't need a release to be productive, just more or less stable environment. So my question is who is going to use KDE 4.0 we're going to release in October? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007 19:26, Andras Mantia wrote: > > But actually I find the "one month from now freeze of KDE api" a little > bit unrealistic. I'd say 3 months might be better to start the freeze > cycle. Could you elaborate what's unrealistic about that? What exactly would be done in the extra two months? -- Cornelius Schumacher <[EMAIL PROTECTED]> ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007, Benjamin Reed wrote: > Andras Mantia wrote: > > On Tuesday 06 March 2007, Cyrille Berger wrote: > >> If you tell them that it will be possible to break ABI/API between > >> the release of 4.0 and 4.1 I am sure they will find it reasonnable > >> ;) (I am sure everyone is eager to see something to be released). > > > > Yeah, but in that case we can can the release 3.9 or pre-4.0 if the BC > > rule comes in only after 4.1. ;-) > > Yeah, I really dislike calling it 4.0 then; 4.0 implies a contract with > application developers that the ABI is stable and will continue to be > supported throughout that major version number series. > > "We want applications to start using our libraries! Although... We'll > break them between now and 6 months from now when the *real* KDE4 comes > out." I think that's splitting straws -- it's not important compared to getting a schedule and getting people out of tinker mode and into release mode. A month should be fine to define the remaining api replacements. Later api changes should, if possible, be in the form of additions instead of replacements. If we don't get into release mode _soon_, it'll be Qt5 times before we can release. That's, in my book, a failure. -- Boudewijn Rempt http://www.valdyas.org/fading/index.cgi pgpSbs6exX1k1.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andras Mantia wrote: > On Tuesday 06 March 2007, Cyrille Berger wrote: >> If you tell them that it will be possible to break ABI/API between >> the release of 4.0 and 4.1 I am sure they will find it reasonnable >> ;) (I am sure everyone is eager to see something to be released). > > Yeah, but in that case we can can the release 3.9 or pre-4.0 if the BC > rule comes in only after 4.1. ;-) Yeah, I really dislike calling it 4.0 then; 4.0 implies a contract with application developers that the ABI is stable and will continue to be supported throughout that major version number series. "We want applications to start using our libraries! Although... We'll break them between now and 6 months from now when the *real* KDE4 comes out." - -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development http://www.racoonfink.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF7cH3Uu+jZtP2Zf4RAhU/AJ0RZnLVj5WthEuwd5o/0GOm4JWQlACeNvow InwUQlsvJ8+hsZn/8lURg7s= =V5i/ -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007, Cyrille Berger wrote: > If you tell them that it will be possible to break ABI/API between > the release of 4.0 and 4.1 I am sure they will find it reasonnable > ;) (I am sure everyone is eager to see something to be released). Yeah, but in that case we can can the release 3.9 or pre-4.0 if the BC rule comes in only after 4.1. ;-) Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org pgpdsf593Zc7m.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007, Andras Mantia wrote: > I think freezing the lib API in 1 month is unrealistic, > and should be delayed by 1 or 2 months to not force developers to rush > now with new code. Providing a mail on core-devel that feature freeze > happens in 24 days might not get too much positive feedback If you tell them that it will be possible to break ABI/API between the release of 4.0 and 4.1 I am sure they will find it reasonnable ;) (I am sure everyone is eager to see something to be released). -- Cyrille Berger ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007, Stephan Kulow wrote: > People hear my message: STOP IT! NOW! May I continue? ;-) Yes, I agree with the idea of setting up milestones, and I don't care that much if we cannot make KDevelop and Quanta4 ready for KDE 4.0, after all there is time and life after that it is only up to us, developers to do the job, but from following the mailing lists and commits, I think freezing the lib API in 1 month is unrealistic, and should be delayed by 1 or 2 months to not force developers to rush now with new code. Providing a mail on core-devel that feature freeze happens in 24 days might not get too much positive feedback. ;-) Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org pgpm8vapB9QfA.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Monday 05 March 2007, Alexander Dymo wrote: > The feature freeze date is totally unrealistic for KDevelop. I can't > speak for other applications, but I guess they'll have troubles too. > > That's actually fine. We can delay KDevelop release till KDE 4.1. As normal, same here for KDEWebDev. But actually I find the "one month from now freeze of KDE api" a little bit unrealistic. I'd say 3 months might be better to start the freeze cycle. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org pgpKLSmWyszOp.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
At Tuesday 06 March 2007 16:28, you wrote: > Cornelius Schumacher wrote: > > > This would delay the release. I don't think aKademy is that important to > > the > > release. If a group feels that they need a personal meeting to facilitate > > getting ready for the release we can organize smaller focused developer > > meetings. The e.V. is able to help with that, if needed. > > I don't know that that would be the issue so much as, it seems like a > lot of innovative (dare I say, synergistic? hehe) group hacking goes on > during akademy, it would be a shame for the 4.0 API to be frozen before > giving those things a chance to happen... Are there more lib developers than app developers? The way I see it, always one group will suffer from a freeze before or after aKademy. Toma -- http://www.mailody.net___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On March 6, 2007, Benjamin Reed wrote: > Cornelius Schumacher wrote: > > This would delay the release. I don't think aKademy is that important to > > the release. If a group feels that they need a personal meeting to > > facilitate getting ready for the release we can organize smaller focused > > developer meetings. The e.V. is able to help with that, if needed. > > I don't know that that would be the issue so much as, it seems like a > lot of innovative (dare I say, synergistic? hehe) group hacking goes on > during akademy, it would be a shame for the 4.0 API to be frozen before > giving those things a chance to happen... as Stephan notes, we probably don't need to get BIC perfect for 4.0. i do think we need to settle back into BC for releases in KDE4, e.g. 4.1 on, but we don't absolutely need to freeze ourselves into 4.0's libs. april 2, if announced this week, gives people ~3 weeks to get things together. we may want to give a full month from the announcement on kde-core-devel just to give people ample time, but otherwise, i think the schedule looks good. what we should be using akademy for is stabilizing and polishing 4.0, not more framework diddling. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 Full time KDE developer sponsored by Trolltech (http://www.trolltech.com) pgpkpQ814ZwRL.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
Am Dienstag 06 März 2007 schrieb Benjamin Reed: > Cornelius Schumacher wrote: > > This would delay the release. I don't think aKademy is that important to > > the release. If a group feels that they need a personal meeting to > > facilitate getting ready for the release we can organize smaller focused > > developer meetings. The e.V. is able to help with that, if needed. > > I don't know that that would be the issue so much as, it seems like a > lot of innovative (dare I say, synergistic? hehe) group hacking goes on > during akademy, it would be a shame for the 4.0 API to be frozen before > giving those things a chance to happen... Akademy 2005 and akademy 2006 happened during unfrozen 4.0 API. I sure hope this year everyone has a KDE4 desktop running and not a dozen developers raise their hand when asked if they ever tried to start KDE4. Greetings, Stephan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cornelius Schumacher wrote: > This would delay the release. I don't think aKademy is that important to the > release. If a group feels that they need a personal meeting to facilitate > getting ready for the release we can organize smaller focused developer > meetings. The e.V. is able to help with that, if needed. I don't know that that would be the issue so much as, it seems like a lot of innovative (dare I say, synergistic? hehe) group hacking goes on during akademy, it would be a shame for the 4.0 API to be frozen before giving those things a chance to happen... - -- Benjamin Reed a.k.a. Ranger Rick Fink, KDE, and Mac OS X development http://www.racoonfink.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF7YieUu+jZtP2Zf4RAmjzAJ9hLMa+DGvDKehHBa5tHDrSXZtZQACeJzn8 6CBM9T+4WjxzhG6X4CySpNs= =DP8+ -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Monday 05 March 2007 20:46, Alexander Dymo wrote: > > First, why don't we delay any freezes until Akademy ends? This would delay the release. I don't think aKademy is that important to the release. If a group feels that they need a personal meeting to facilitate getting ready for the release we can organize smaller focused developer meetings. The e.V. is able to help with that, if needed. > And second, I think this plan will make us rush into 4.0 release. > Is that really necessary? If it helps getting things going again is it necessary. -- Cornelius Schumacher <[EMAIL PROTECTED]> ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007 10:02, Stephan Kulow wrote: > > So dear KDE release team: drop your perfection plans, drop all modules that > do not comply to the roadmap and let them ship later. > kdevelop won't make it? Fine, supply a KDE4 template for kdevelop 3.4. > kdepim won't make it? Too bad, make sure kdepim 3.5 runs fine on a KDE4 > desktop. > plasma won't make it in its full beauty? Define the bare minimum what is > required and get as many hands to help as possible and deliver even better > results for 4.1. I see good progress there, so I have a good feeling. I wholeheartedly agree with Stephan here. As much as I would like Akonadi or KDE PIM 4 to see released together with KDE 4.0 I don't want the release of kdelibs be delayed by that. It really hurts us, that we don't have a stable library release (3rd party) application developers can use to port their applications and actually release stable versions of them. So I think Tom's proposal is great. -- Cornelius Schumacher <[EMAIL PROTECTED]> ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007 11:35, Sebastian Kügler wrote: > - KDevelop 3.5 needs to be usable to develop KDE4 applications well KDevelop 3.4 already is. We use it to develop KDevelop4. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Tuesday 06 March 2007 10:02:24 Stephan Kulow wrote: > Am Dienstag 06 März 2007 schrieb Sebastian Kügler: > > What do you think? > > What I think? Good you asked. Because if you continue discussing on this > level we won't have another KDE release before 2012. > > I like Tom's approach: Define a roadmap with milestones and set dates to > it. If a milestone slips, define if you don't care about the milestone or > the date. I like it, too. The point is that for a roadmap, we need a match between a minimal set of features/requirements and dates. The relationship being: More features -> later releasedate, less features earlier releasedate, very basically. Tom proposed a set of dates (which makes sense to me, personally), so we have to find the matching set of features. I am however not trying to push any requirements through. > Don't take me wrong, nice kdelibs features will surely popup like mad every > couple of days. But as a matter of fact: we managed to produce a pretty > useful desktop with the crappy API just as well. While targeting for the > perfect API dox and the perfectly designed APIs might sound like a super > idea, it won't help me as a KDE user. > > So dear KDE release team: drop your perfection plans, drop all modules that > do not comply to the roadmap and let them ship later. > kdevelop won't make it? Fine, supply a KDE4 template for kdevelop 3.4. > kdepim won't make it? Too bad, make sure kdepim 3.5 runs fine on a KDE4 > desktop. > plasma won't make it in its full beauty? Define the bare minimum what is > required and get as many hands to help as possible and deliver even better > results for 4.1. I see good progress there, so I have a good feeling. So what is this bare minimum? From your email, I understand: - incomplete APIDOX is not a showstopper - APIs may change in the future - plasma not being completely finished is not a showstopper, focus needed on making it usable - either PIM 3.5 needs to run on KDE4 well or PIM4 needs to be usable - KDevelop 3.5 needs to be usable to develop KDE4 applications well > Every discussion around KDE4 pisses me at the moment actually as it's > against the real aim a KDE4 roadmap should have: making sure a KDE4 > snapshot runs on as many desktops as possible. I can start any KDE4 > application at the moment and find easily tons of bugs and _that_ has to > stop. If we break binary incompatibility 19 or 190 times in the timeline of > KDE4 is _not_ the problem. - binary incompatibility is not a showstopper - stabilising applications should become focus now > Sure every such case has to be evaluated as it hurts everyone not having a > compile cluster, but I repeat: it's NOT our problem. > > A feature freeze in august 2007 is _way_ too late - may I remember everyone > that we started porting for KDE4 in may 2005? > > People hear my message: STOP IT! NOW! Personal note: I'm not out for a perfect KDE4 release, I'm trying to help making a decision on a roadmap, because I regard it important, and because I'd like to see more progress there. The problem is complex enough that we either need a benevolent dictator or a way to make this decision collaboratively. I'm trying to facilitate the latter. Important question: Are there objections against the bullet points from coolo's list so far? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I have no right, by anything I do or say, to demean a human being in his own eyes. What matters is not what I think of him; it is what he thinks of himself. To undermine a man's self-respect is a sin. - Antoine de Saint-Exupery pgp3fs61RAPbM.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
Am Dienstag 06 März 2007 schrieb Sebastian Kügler: > What do you think? What I think? Good you asked. Because if you continue discussing on this level we won't have another KDE release before 2012. I like Tom's approach: Define a roadmap with milestones and set dates to it. If a milestone slips, define if you don't care about the milestone or the date. Don't take me wrong, nice kdelibs features will surely popup like mad every couple of days. But as a matter of fact: we managed to produce a pretty useful desktop with the crappy API just as well. While targeting for the perfect API dox and the perfectly designed APIs might sound like a super idea, it won't help me as a KDE user. So dear KDE release team: drop your perfection plans, drop all modules that do not comply to the roadmap and let them ship later. kdevelop won't make it? Fine, supply a KDE4 template for kdevelop 3.4. kdepim won't make it? Too bad, make sure kdepim 3.5 runs fine on a KDE4 desktop. plasma won't make it in its full beauty? Define the bare minimum what is required and get as many hands to help as possible and deliver even better results for 4.1. I see good progress there, so I have a good feeling. Every discussion around KDE4 pisses me at the moment actually as it's against the real aim a KDE4 roadmap should have: making sure a KDE4 snapshot runs on as many desktops as possible. I can start any KDE4 application at the moment and find easily tons of bugs and _that_ has to stop. If we break binary incompatibility 19 or 190 times in the timeline of KDE4 is _not_ the problem. Sure every such case has to be evaluated as it hurts everyone not having a compile cluster, but I repeat: it's NOT our problem. A feature freeze in august 2007 is _way_ too late - may I remember everyone that we started porting for KDE4 in may 2005? People hear my message: STOP IT! NOW! Greetings, Stephan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Monday 05 March 2007 22:23, Alexander Dymo wrote: > October 2006. > March 2007. I wanted to say 2007 and 2008 :) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
[Thanks Tom, for bringing this up.] On Monday 05 March 2007 21:01:59 Cyrille Berger wrote: > > That's actually fine. We can delay KDevelop release till KDE 4.1. > > can't kdevelop 4.0 be released after 4.0 and before 4.1 ? I mean that what > will happen for koffice, and maybe other modules (ie kdepim) ? On the other > hand the dates feel like a rush to me. I think, given Alex' comment which probably reflects that of other developers, that we first would need to define what the release will be. In the past, KDE has been frozen as a snapshot and then stabilised. That worked because it's been somewhat 'complete' and was never substantially broken. For KDE 4.0, this is a bit different. So very generally, to release KDE 4.0, we need: - libs stable enough - a basic set of applications, those need to be stable enough The questions that arise from this: - What needs to go in kdelibs before KDE 4.0? - When is the quality of kdelibs good enough for 4.0? (APIDOX, higher level docs, bug'free'ness?, ...?) - Do we want to guarantee binary compatibility for the whole 4.x cycle - How far are the frameworks that need to go in (Phonon is pretty far, I think, Solid does well, Plasma is at the beginning but might go very fast, what about pim?, ...). Can we get a rough estimation when those frameworks are ready to be feature frozen? - Which applications do we want in? - Under which conditions can an app be considered for the kdebase? (usability, code quality checking, coding style, documentation, artwork adhering to Oxygen, stable IPC interfaces?, ...) I think if we have answers to those questions, or at least rough ideas, creating a roadmap is much easier. What do you think? What did I forget in those enums? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - It is your concern when your neighbor's wall is on fire. - Quintus Horatius Flaccus (Horace) pgpRCgS79K2IK.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Monday 05 March 2007 22:23, Alexander Dymo wrote: > October 2006. > March 2007. I wanted to say 2007 and 2008 :) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Monday 05 March 2007 21:43, Tom Albers wrote: > can you provide realistic dates? I can't speak for KDE4 base + libs actually, but I'd suggest 10th July as the feature freeze date (right after aKademy). All other dates can be shifted respectively: message freeze: 10 August beta cycle: 10 September RC cycle: 10 November KDE4: 10 December But if you ask me what would be my preferred feature freeze date for KDevelop, I'd answer October 2006. But that would suggest release date in March 2007. I'm not sure that's acceptable for KDE4 therefore I'm fine with any KDE4 release plan even if that means not releasing KDevelop4 among with KDE4. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
> That's actually fine. We can delay KDevelop release till KDE 4.1. can't kdevelop 4.0 be released after 4.0 and before 4.1 ? I mean that what will happen for koffice, and maybe other modules (ie kdepim) ? On the other hand the dates feel like a rush to me. -- Cyrille Berger ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
Op ma 5 mar 2007 20:46 schreef u: > On Saturday 03 March 2007 23:54, Tom Albers wrote: > > feature freeze - 2 may > > After this date the kde main modules are frozen for new features. No new > > features are allowed, the focus is from now on on stabilizing the > > applications and fix all bugs. This is also the date that all the > > maintainers of the main kde modules need to indicate if they will follow > > this schedule or will divert and will not be released together with kde > > 4.0. > The feature freeze date is totally unrealistic for KDevelop. I can't speak > for other applications, but I guess they'll have troubles too. > > That's actually fine. We can delay KDevelop release till KDE 4.1. > > Still, I have two suggestions. > First, why don't we delay any freezes until Akademy ends? > And second, I think this plan will make us rush into 4.0 release. > Is that really necessary? can you provide realistic dates? Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
On Saturday 03 March 2007 23:54, Tom Albers wrote: > feature freeze- 2 may > After this date the kde main modules are frozen for new features. No new > features are allowed, the focus is from now on on stabilizing the > applications and fix all bugs. This is also the date that all the > maintainers of the main kde modules need to indicate if they will follow > this schedule or will divert and will not be released together with kde > 4.0. The feature freeze date is totally unrealistic for KDevelop. I can't speak for other applications, but I guess they'll have troubles too. That's actually fine. We can delay KDevelop release till KDE 4.1. Still, I have two suggestions. First, why don't we delay any freezes until Akademy ends? And second, I think this plan will make us rush into 4.0 release. Is that really necessary? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [RFC] Draft Roadmap for KDE 4.0
A Dissabte 03 Març 2007, Tom Albers va escriure: > Hi all, I'm astonished, no comments for now, that can only mean that everyone agrees with you or that noone as a clue. > Sebas pointed out that we need to setup a roadmap to the KDE4 release. As I > think setting deadlines will actual help to reach goals, I've taken the > time to setup a draft roadmap to KDE4. > > I've no experience in release schedules nor do I know the state of kdelibs > or any other kde4 module, but I feel a draft document makes discussing > things much easier. So here comes a draft schedule, lets work on the points > and dates and publish it after that on the current Techbase page. > > > kdelibs soft api freeze + alpha1 release - 2 April > This is the the point where kdelibs api is frozen. That means that the > classes and interfaces are not allowed to change anymore. That means the > end of the famous bic Mondays. That's one month from now only, i'm not a libs developer, but it seems to few for me, true is that you leave the door open for changes, so maybe it's just me :-) > > If for one reason you feel the api should change, you need to post a > kdelibs api exception request to kde-core-devel with the reason and the > code. If there are no objections after a week, you can commit the changes, > but all the kde main modules must compile and work as expected. > > kdelibs is also i18n frozen, exceptions can be asked on kde-i18n > mailinglist. The release will not include translations. > > > feature freeze- 2 may > After this date the kde main modules are frozen for new features. No new > features are allowed, the focus is from now on on stabilizing the > applications and fix all bugs. This is also the date that all the > maintainers of the main kde modules need to indicate if they will follow > this schedule or will divert and will not be released together with kde > 4.0. So have we really decided we want to go on with KDE 4.0 not beign a FULL release, that is, maybe not shipping kdepim? For me that'd be a loss, but maybe it's the best we can do, get 4.0 as fast as possible to start regaining steam. Albert > > > message freeze- 2 June > After this date the main modules are frozen for new messages. Exceptions > can be asked on kde-i18n mailinglist. > > > beta cycle starts - 2 Juli > From this date on every month a beta version will be published, this will > be repeated until most grave bugs are resolved. Translations are included > from the second beta. kdelibs api is now frozen. > > > release candidate cycle starts, total release freeze. - 2 September > A RC will be released. If there is no grave bug in that release, kde 4.0 > will be released, else new release candidates will be released every month. > When the first release candidate there is a total release freeze active. > This means that you can fix serious bug reports but nothing else. > > Before the first release candidate there will be a made of lists of > languages which will be included in the KDE 4.0 release. This is based on > the rules as usual. > > > KDE 4.0 - 2 October > > > Toma ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
[RFC] Draft Roadmap for KDE 4.0
Hi all, Sebas pointed out that we need to setup a roadmap to the KDE4 release. As I think setting deadlines will actual help to reach goals, I've taken the time to setup a draft roadmap to KDE4. I've no experience in release schedules nor do I know the state of kdelibs or any other kde4 module, but I feel a draft document makes discussing things much easier. So here comes a draft schedule, lets work on the points and dates and publish it after that on the current Techbase page. kdelibs soft api freeze + alpha1 release- 2 April This is the the point where kdelibs api is frozen. That means that the classes and interfaces are not allowed to change anymore. That means the end of the famous bic Mondays. If for one reason you feel the api should change, you need to post a kdelibs api exception request to kde-core-devel with the reason and the code. If there are no objections after a week, you can commit the changes, but all the kde main modules must compile and work as expected. kdelibs is also i18n frozen, exceptions can be asked on kde-i18n mailinglist. The release will not include translations. feature freeze - 2 may After this date the kde main modules are frozen for new features. No new features are allowed, the focus is from now on on stabilizing the applications and fix all bugs. This is also the date that all the maintainers of the main kde modules need to indicate if they will follow this schedule or will divert and will not be released together with kde 4.0. message freeze - 2 June After this date the main modules are frozen for new messages. Exceptions can be asked on kde-i18n mailinglist. beta cycle starts - 2 Juli >From this date on every month a beta version will be published, this will be >repeated until most grave bugs are resolved. Translations are included from >the second beta. kdelibs api is now frozen. release candidate cycle starts, total release freeze. - 2 September A RC will be released. If there is no grave bug in that release, kde 4.0 will be released, else new release candidates will be released every month. When the first release candidate there is a total release freeze active. This means that you can fix serious bug reports but nothing else. Before the first release candidate there will be a made of lists of languages which will be included in the KDE 4.0 release. This is based on the rules as usual. KDE 4.0 - 2 October Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
