Re: Discussion about 4.1 timeframe (was Re: What to do about Kompare?)
On Friday 14 December 2007, Andreas Pakulat wrote: Are you sure about that? I don't know how SuSE or RedHat and others do their releases but I'd expect them to need at least 2 or rather 4 weeks after a KDE 4.1 release until its patched up/fixed for inclusion in the next release. So if the next release of a distro X is planned for mid-june a release in mid-may would be needed. Meaning we'd effectively have 1.5 months non-frozen trunk/ thats really very little time. I wouldn't plan software release in function of what distributions plans to do or plans no to do or might plan to do. There are distributions being relesed all the time. Anyway, most will offer backport of KDE4.1 for their current release. So I think you should focus on picking the best solution for KDE 4.1 to be the KDE 4 that kick KDE 3's ass (not that KDE 4.0 isn't good, but it's not better than KDE 3.5 in all area). While I do agree that 4.1 should be set at a fix date, I do think the schedule should ensure that application like KMail which were left aside for 4.0, are able to deliver in 4.1. -- Cyrille Berger ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Discussion about 4.1 timeframe (was Re: What to do about Kompare?)
I agree to Mauricio's points, we should do a 'relatively quick' 4.1, then try to move into a time-based release schedule. End January: Lifting feature freeze for trunk/ End of March: (feature/string) freeze trunk/ Mid May: KDE 4.1 I fully agree with Sebas here: What we need most right now is fast consolidation so that people finally get the conceptually reliable desktop back that they were used to from KDE 3 (I'd even suggest Consolidation as a code name). For KDE 2.0 we had the very same problem as with KDE 4.0: lot's of loose ends, still a lot of tripwires for the user to fall across. Lot's of small to medium-sized conceptual problems that needed to get solved fast. Backporting all those into KDE 2.0.x bugfix releases would have meant that people would have to constantly spend much time on applying all those fixes for minor oddities to _two_ branches in parallel which would have delayed a lengthy sophisticated KDE 2.1 release cycle a lot more. So the solution was a quick 2.1 release which was mostly about polishing and making the whole UI experience more reliable: KDE 2.0 release: 23 October 2000. KDE 2.1 release: 26 February 2001 (I just stumled across this: http://dot.kde.org/979149870/ ) I'd say that this decision to do a quick 2.1 release was what saved our asses marketing wise because exposing people to KDE 2.0 for a longer time would have hurt KDE's reputation due to the true .0 quality which that release sported. The same is true for KDE 4.0. So we need to fix the most fundamental issues as fast as possible after KDE 4.0. While making use of all possible additional features that Qt 4.4 will provide is tempting I think we should avoid to create any larger construction sites this soon after a major release. So I'd rather favour a quick port to Qt 4.4 and concentrating on the low hanging fruits for a Qt 4.4 port instead of doing an extensive one. I expect that there will be a huge slew of small patches for KDE 4.1 which will will improve the UI experience greatly and will bring it mostly up to par with latest KDE 3.5.x. However if you have major changes that are well tested and ready for a release then of course it's fine to contribute them. Also keep in mind that if we target our release for May then the release will most likely still happen in June due to usual delays! Most major distributors plan to release around that time, so I'd rather plan for a release in May if we want to make sure that they ship a nice desktop that everybody feels comfortable with. -- Torsten Rahn Tel.: 0 21 61 - 46 43 - 192 credativ GmbH, HRB Mönchengladbach 12080 Hohenzollernstr. 133, 41061 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Discussion about 4.1 timeframe (was Re: What to do about Kompare?)
On 14.12.07 15:49:24, Cyrille Berger wrote: On Friday 14 December 2007, Andreas Pakulat wrote: Are you sure about that? I don't know how SuSE or RedHat and others do their releases but I'd expect them to need at least 2 or rather 4 weeks after a KDE 4.1 release until its patched up/fixed for inclusion in the next release. So if the next release of a distro X is planned for mid-june a release in mid-may would be needed. Meaning we'd effectively have 1.5 months non-frozen trunk/ thats really very little time. I wouldn't plan software release in function of what distributions plans to do or plans no to do or might plan to do. There are distributions being relesed all the time. Anyway, most will offer backport of KDE4.1 for their current release. So I think you should focus on picking the best solution for KDE 4.1 to be the KDE 4 that kick KDE 3's ass (not that KDE 4.0 isn't good, but it's not better than KDE 3.5 in all area). While I do agree that 4.1 should be set at a fix date, I do think the schedule should ensure that application like KMail which were left aside for 4.0, are able to deliver in 4.1. I completely agree with you Cyrille and that is what I wanted to express - see my last sentence of a release in may meaning too little time for active development. Andreas -- You should emulate your heros, but don't carry it too far. Especially if they are dead. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [24h] Kompare move to extragear
On Thursday 13 December 2007, Tom Albers wrote: Without objections I will move Kompare to extragear tomorrow evening and add it to the keg-tarball-on-release-project. Why, why exactly? The 24h waiting period starts now. Great, thanks a lot for giving me a lot of time to respond :-( Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
GStreamer backend on kdebase
Vir says it does not work and it's not expected to work. So i ask myself why is it sitting in the place of the code we are going to release in less than one month. Can we please move it to somewhere were it should belong like playgound now that all the marketing buzz has been done and not bring it back until it sort of works? Albert P.S: Obviously i'm inmensely grateful to TT for giving us working Phonon backends on all platforms and for making it in a more open way and all that stuff, but that does not makes them able to not follow guides, and we are on a release mode and importing non-working code to the release branch is just plain wrong on my scale of things. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [24h] Kompare move to extragear
Op Friday 14 December 2007 20:37 schreef u: On Thursday 13 December 2007, Tom Albers wrote: Without objections I will move Kompare to extragear tomorrow evening and add it to the keg-tarball-on-release-project. Why, why exactly? It was discussed on the list. But mattr objected so it will not happen, you can safely catch up with your mail ;-) The 24h waiting period starts now. Great, thanks a lot for giving me a lot of time to respond :-( Filter on [24h] ? Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [24h] Kompare move to extragear
On Friday 14 December 2007, Dirk Mueller wrote: The 24h waiting period starts now. Great, thanks a lot for giving me a lot of time to respond :-( It's still there in trunk/kdesdk, so you're not too late yet. ;-) Kevin Kofler ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [24h] Kompare move to extragear
PS: In case my opinion matters: I think it's fine in the regular kdesdk trunk, I don't see a good reason to move it to extragear. Kevin Kofler ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: GStreamer backend on kdebase
On Friday 14 December 2007, Albert Astals Cid wrote: Vir says it does not work and it's not expected to work. So i ask myself why is it sitting in the place of the code we are going to release in less than one month. Can we please move it to somewhere were it should belong like playgound now that all the marketing buzz has been done and not bring it back until it sort of works? Albert P.S: Obviously i'm inmensely grateful to TT for giving us working Phonon backends on all platforms and for making it in a more open way and all that stuff, but that does not makes them able to not follow guides, and we are on a release mode and importing non-working code to the release branch is just plain wrong on my scale of things. I Agree 100%, I just wrote the same mail. I'm just 4300 mails behind so I don't know where it was discussed if it was discussed at all. Greetings, Dirk (who is using vacation to catch up with mail :) ) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdebase/runtime/phonon
Dirk Mueller wrote: On Thursday 13 December 2007, Thiago Macieira wrote: Import the qt7, ds9 and gstreamer phonon backends. This is current as of Trolltech perforce revision 288319 Great. was this discussed with anyone on the release team? No. And, in hindsight, it shouldn't have been committed to trunk. I forgot to ask for a Qt (not qt-copy) branch on Subversion. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
