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: 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?)
On 14.12.07 13:55:38, Torsten Rahn wrote: > 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. 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. Andreas -- Today is what happened to yesterday. ___ 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 Thursday 13 December 2007 19:25, Aaron J. Seigo wrote: > > The point is that some applications are ALREADY waiting for inclusion > > since July/07! That is why I think a release in April makes sense, it > 4 months after 4.0? that's 2.5 months of development time at best. seems > rather short. Indeed that's too short. We'll again have not enough time to implement new features and we'll need to set up again "exemptions", "exceptions", etc. Again we'll need "properly marketed" release. Why are we trying to rush? What's the reason to rush? > > After 4.1, we should probably experiment with the 6 month release > > schedule that seems to be working for other projects, > > for certain values of "working". for at least one major project, there was > an immediate and noticeable decline in both mailing list traffic and commit > rates when a 6 month cycle was adopted. > > i'd sooner see us (loosely) sync along with the Qt dev cycle (which has > become much more regular, ~9 month per release) to keep a steady flow of > feature / bug fixes going between KDE and Qt. 9 months sounds like much better than 6 months. Not only because of longer time for feature development, but because of longer beta/RC cycles to polish features and fix more bugs. In one word, I'd prefer us releasing more featureful and stable software. ___ 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 Thursday 13 December 2007 18:43:53 Mauricio Piacentini wrote: > > i'd sooner see us (loosely) sync along with the Qt dev cycle (which has > > become much more regular, ~9 month per release) to keep a steady flow > > of feature / bug fixes going between KDE and Qt. > > Ok, keeping a pace with Qt actually makes more sense than any other > (arbitrary by nature) decision. Also, with 4.0 out, we will resume the > cycle of new applications going to playground or maybe kdeapps, and then > waiting to be picked for inclusion in the main releases or extragear. Sounds sane. > This is something we should consider maybe, with feedback from TT. Not sure what you want feedback on :) But I'm positive that having a KDE release slightly after a Qt release is something that nobody will have a problem with here at TT :) -- Thomas Zander signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Discussion about 4.1 timeframe (was Re: What to do about Kompare?)
On Thursday 13 December 2007 18:25:16 Aaron J. Seigo wrote: > > After 4.1, we should probably experiment with the 6 month release > > schedule that seems to be working for other projects, > > for certain values of "working". for at least one major project, there > was an immediate and noticeable decline in both mailing list traffic and > commit rates when a 6 month cycle was adopted. I would expect that when more developers start to become comfortable with distributed srm systems (like git) this starts to be easier and we can avoid such problems. Therefor I think we should let the progress of people pushing their stuff into repos, as they want, drive the strictness of our release schedule. And vice versa. In other words; let people get comfortable with the techniques and technology to enable this much easier at a similar pace as we move to more strict time-based releases. -- Thomas Zander signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Discussion about 4.1 timeframe (was Re: What to do about Kompare?)
Aaron J. Seigo wrote: >> If something can not be >> done in 3 months, it is doubtful that it would be ready in 4 or 5, at >> least in the open source world, right? > > i haven't seen that to be the case, no. The half of my brain that almost understands English is confused by this double negative, in answer to my already less-than-clear question :) Do you agree with me, or not? :) Mauricio Piacentini ___ 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?)
Aaron J. Seigo wrote: > of course that's what we always used to do. 2.0 and 4.0 have been the only > two > exceptions i can think of since i've been around the project. Yes, this was something we talked about during last Akademy, when there was the "suggestion" to move to 6 months cycle. We already have schedule-based releases in the 3.x series, but this methodology is of course not possible on major revamps like 4.0. There is nothing new with this suggestion, I know. It is just the basic idea: for 4.0 onwards it would be better for us to return to this mode of operation. > there's also the issue of Qt 4.4 to keep in mind. it will bring a number of > significant strides forward that we will likely want to take quick advantage > of, and it comes out in Q1 (more towards the end of Q1 than the beginning). That is certainly something to be considered when deciding the schedule. Better yet if we can work in defining a pattern to follow, imo. > for certain values of "working". for at least one major project, there was an > immediate and noticeable decline in both mailing list traffic and commit > rates when a 6 month cycle was adopted. Interesting. I wonder if the problem here is the excess of management perhaps? By this I mean that windows to commit new features and work on them are relatively small compared to the window for stabilizing/translating. This is something probably difficult to fine tune, and if we can benefit from what others have learned it is a good way to avoid repeating the same mistakes! > i'd sooner see us (loosely) sync along with the Qt dev cycle (which has > become > much more regular, ~9 month per release) to keep a steady flow of feature / > bug fixes going between KDE and Qt. Ok, keeping a pace with Qt actually makes more sense than any other (arbitrary by nature) decision. Also, with 4.0 out, we will resume the cycle of new applications going to playground or maybe kdeapps, and then waiting to be picked for inclusion in the main releases or extragear. This is something we should consider maybe, with feedback from TT. And of course, everything will be magically better after 4.0 is out :) Regards, Mauricio Piacentini ___ 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 Thursday 13 December 2007 16:59:16 Mauricio Piacentini wrote: > Well, I think that *AFTER* 4.0 it is wrong to continue doing > feature-based releases, and we could experiment a bit with > schedule-driven ones. If it is 3 or 4 or 6 or 8 months it is open for > discussion. But the basic idea is: whenever 4.1 is scheduled for, if a > game, or a new Kopete feature, or KDevelop is not ready, then it sits > out, and waits for the next round. Simple, easy. People continue to use > the existing versions. No loss. Less pressure as well for the developer > imo. 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 Qt4.4 comes at the end of Q1, so we should be able (with the help of qt-copy) to base 4.1 on Qt4.4 and all its new goodness. The main reasons for a time-based release cycle are the following: - KDE is becoming too big to lean on certain features, there will always be something not ready and it will be hard to draw a line (we see this currently with kompare and newssl) - It makes things easier to plan for developers (incl. third parties) - It's easier for distros to rely on KDE schedules A release cycle could look like this: m0: release of X-1, opening of trunk/ for new features m4: Features freeze, bugfixing mode m5: String freeze m6: release X I'm not sure if two months are enough, and how long a string freeze should usually be. It's a basis for discussion nevertheless. Based on how much effort stabilising the codebase is, we might also consider having a 4 month cycle with 2 months features, 2 months bugfixes. This will probably mean that larger stuff needs to be started in a branch, but that might be the case anyway. Opinions? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Discussion about 4.1 timeframe (was Re: What to do about Kompare?)
On Thursday 13 December 2007, Mauricio Piacentini wrote: > > > I'm not. :P You get basically two months to develop and add new > > > features and that's quite crazy. If we do this, you once again leave > > > out KDevelop and kdewebdev from the release because i don't think > > > those are going to be ready in 3-4 months. You also leave out a > > > significantly better version of Kopete since all the new stuff we > > > want to do for that (which is currently planned for 4.1) won't get > > > done either. > > > >I'm with Matt here, the same applies to kompare as I doubt everything > >thats needed can be done in just two months (also looking at the fact > >that I won't have much time for hacking myself until may). > > Well, I think that *AFTER* 4.0 it is wrong to continue doing > feature-based releases, and we could experiment a bit with > schedule-driven ones. of course that's what we always used to do. 2.0 and 4.0 have been the only two exceptions i can think of since i've been around the project. > game, or a new Kopete feature, or KDevelop is not ready, then it sits > out, and waits for the next round. Simple, easy. People continue to use > the existing versions. No loss. Less pressure as well for the developer > imo. yep. > this example, to be concrete: if we release 4.1 only in August then I > doubt we will be able to keep momentum on the games and perhaps the edu > teams as well. there's also the issue of Qt 4.4 to keep in mind. it will bring a number of significant strides forward that we will likely want to take quick advantage of, and it comes out in Q1 (more towards the end of Q1 than the beginning). > The point is that some applications are ALREADY waiting for inclusion > since July/07! That is why I think a release in April makes sense, it 4 months after 4.0? that's 2.5 months of development time at best. seems rather short. personally, i'd rather see a June date for 4.1; 4 months of devel, 2 months to stabalize, be able to take advantage of Qt 4.4 stuff. oh, and note that a April release would mean delaying BC for libplasma by another release due to Qt 4.4 availability. > would have been 9 months after the last chance for inclusion. But it > could be in May as well: starting NOW, it would give us at least 3 > months for development of these new features. well, one might also suggest that right now is the time to actually be working on stabalizing / completing 4.0 =) the games have many possible improvements left as well; some of lskat's animations are still dreadfully long; you can't tell which cards are the last cards in that stack (which is pretty important for strategy in that game); icons in the status box are misshapen... etc... i'm sure this is the case with most parts of 4.0. so starting development for 4.1 now, while tempting, is perhaps not thte best idea? > If something can not be > done in 3 months, it is doubtful that it would be ready in 4 or 5, at > least in the open source world, right? i haven't seen that to be the case, no. > After 4.1, we should probably experiment with the 6 month release > schedule that seems to be working for other projects, for certain values of "working". for at least one major project, there was an immediate and noticeable decline in both mailing list traffic and commit rates when a 6 month cycle was adopted. i'd sooner see us (loosely) sync along with the Qt dev cycle (which has become much more regular, ~9 month per release) to keep a steady flow of feature / bug fixes going between KDE and Qt. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech pgpp33JHjR1qL.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
