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
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 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
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: obsolete templates
On Tuesday 06 March 2007, Stephan Kulow wrote: messages/kdewebdev/kommander.pot messages/kdewebdev/quanta.pot In KDE4 there is no kommander yet (its disabled from compilation). But I don't understand if this list is the obsolete list, or just listing everything? Because Quanta exists and it is in kdewebdev. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org pgpGxQmIS9pmQ.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 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
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 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
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: obsolete templates
A Dimarts 06 Març 2007, Stephan Kulow va escriure: Hi! Hi, thanks for attacking the i18n issue :-) I have a question and a comment. Question: Are playground modules beign parsed? okular has a Messages.sh but no template, are we doing something wrong? Commnent: messages/kdegraphics/kpdf.pot should be moved to messages/playground/graphics/okular.pot as most of the messages are the same or very similar. Albert I need your help. There are just too many obsolete templates for KDE4. Removed applications need to have their templates removed, renamed apps need to have their template renamed moved apps need to have their templates moved. Please help me out and tell me about things you know. Greetings, Stephan messages/kdeaccessibility/libKTTSD.pot messages/kdeaddons/kcmkuick.pot messages/kdeaddons/konqsidebar_delicious.pot messages/kdeaddons/konqsidebar_news.pot messages/kdeaddons/kuick_plugin.pot messages/kdeaddons/libkaddrbk_geo_xxport.pot messages/kdeaddons/libkaddrbk_gmx_xxport.pot messages/kdeaddons/rellinks.pot messages/kdebase/clockapplet.pot messages/kdebase/kdcop.pot messages/kdebase/kde-system-monitor.pot messages/kdebase/kio_mac.pot messages/kdebase/libdmctl.pot messages/kdebase/libkickermenu_tom.pot messages/kdebase/privacy.pot messages/kdeedu/keduca.pot messages/kdeedu/kturtle.pot messages/kdeedu/kverbos.pot messages/kdegames/ksmiletris.pot messages/kdegraphics/kcm_kviewcanvasconfig.pot messages/kdegraphics/kcm_kviewgeneralconfig.pot messages/kdegraphics/kcm_kviewpluginsconfig.pot messages/kdegraphics/kcm_kviewviewerpluginsconfig.pot messages/kdegraphics/kpdf.pot messages/kdegraphics/ksvgplugin.pot messages/kdegraphics/kviewbrowserplugin.pot messages/kdegraphics/kviewcanvas.pot messages/kdegraphics/kvieweffectsplugin.pot messages/kdegraphics/kview.pot messages/kdegraphics/kviewpresenterplugin.pot messages/kdegraphics/kview_scale.pot messages/kdegraphics/kviewscannerplugin.pot messages/kdegraphics/kviewshell.pot messages/kdegraphics/kviewviewer.pot messages/kdegraphics/libkfaximgage.pot messages/kdelibs/kioexec.pot messages/kdelibs/kmcop.pot messages/kdelibs/knotifytest.pot messages/kdelibs/ktexteditor_isearch.pot messages/kdemultimedia/artsbuilder.pot messages/kdemultimedia/artscontrol.pot messages/kdemultimedia/artsmodules.pot messages/kdemultimedia/krec.pot messages/kdemultimedia/noatun.pot messages/kdemultimedia/simpleplaylist.pot messages/kdenetwork/dcoprss.pot messages/kdenetwork/kcmktalkd.pot messages/kdenetwork/kcmwifi.pot messages/kdenetwork/kget.pot messages/kdenetwork/ksirc.pot messages/kdepim/kabcclient.pot messages/kdepim/kandy.pot messages/kdepim/kfile_palm.pot messages/kdepim/kgantt.pot messages/kdepim/kio_mobile.pot messages/kdepim/kmobile.pot messages/kdepim/kpilot.pot messages/kdepim/kres_exchange.pot messages/kdepim/ksync.pot messages/kdepim/libkpimexchange.pot messages/kdetoys/kodo.pot messages/kdeutils/kcmlaptop.pot messages/kdeutils/kedit.pot messages/kdevelop/kdevdesigner.pot messages/kdevelop/kdevelop.pot messages/kdevelop/kdevtipofday.pot messages/kdevelop/qeditor.pot messages/kdewebdev/kommander.pot messages/kdewebdev/quanta.pot messages/koffice/kscreenshot_plugin.pot messages/koffice/kspreadcalc_calc.pot messages/koffice/kthesaurus.pot messages/qt/kdeqt.pot ___ 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
