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: 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?)
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?)
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?)
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?)
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
