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: What to do about Kompare?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 13, 2007, at 5:49 AM, Sebastian Kuegler wrote: On Thursday 13 December 2007 12:35:29 Mauricio Piacentini wrote: I think we might want to bump pretty quickly to a 4.1 release and that's when we can enable it again (and move some games and kaider and maybe the ssl tree). Yes, I also think we should not wait more than 3-4 months, and plan 4.1 to the end of April, or May. We all know 4.0 is a release that will not have everything we need, but at this time we need to have it out : a) with only the components that are working and have been minimally tested b) soon so that the tree can open again, for new strings, new ports, new apps I support this. What I have in mind is roughly the following: 4th Jan: tagging 4.0, then release End of January: 4.0.1 (and possible more bugfix releases as necessary) End of January: Opening up trunk/ for features again End of March: Feature freeze in trunk End of April: 4.1 I'm especially curious how easily we'll be able to stabilise 4.1 then. Based on that we should decide on some general release schedule strategy, and possibly consider a time-based schedule. How do people feel about this as rough planning? -- How about starting a new thread for it instead? - -- Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHYS7QA6Vv5rghv0cRAlcLAJ9p48XmCZ98AYmoIxj6kCDOi3Ts7ACfde8x E3dUxlhSMcK07iATQJPZdnk= =AqVK -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to do about Kompare?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 13, 2007, at 5:53 AM, John Tapsell wrote: +1 vote for not including and having a 4.1 release within 3-4 months of 4.0. I think everyone can be satisfied with that. 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. - -- Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHYS89A6Vv5rghv0cRAvZOAKCuoylh/oPU6iVIzNhcTZsZ3T1/jQCgghlx q8p/t9aw5uMjcx4s6UiMDgg= =yQ4B -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to do about Kompare?
On 13.12.07 07:10:20, Matt Rogers wrote: On Dec 13, 2007, at 5:53 AM, John Tapsell wrote: +1 vote for not including and having a 4.1 release within 3-4 months of 4.0. I think everyone can be satisfied with that. 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). I think a 6 month timeframe is better for the 4.1 release. Andreas -- You will meet an important person who will help you advance professionally. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to do about Kompare?
On Thursday 13 December 2007 14:08:32 Matt Rogers wrote: How do people feel about this as rough planning? How about starting a new thread for it instead? Good call. I'll post a more thought-through proposal shortly. -- 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
Discussion about 4.1 timeframe (was Re: What to do about Kompare?)
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. 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. But if we delay everything because one developer or group will not be able to complete a given feature, then we start penalizing everyone. In 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. We have lots of new stuff waiting on the sidelines: Step for example is wonderful. In games there are several waiting, some for years, like Ksirk. Plasma will probably mature very quickly in 2-3 months following 4.0, I guess, and lots of plasmoids would be ready. KDE 4.0 is a platform release, we need to follow up with incremental upgrades relatively soon imo. If something is not ready, ok! No penalty, nothing is lost. Wait for the next release. But do not hold the gates for things that are ready to be in. 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 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. 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? After 4.1, we should probably experiment with the 6 month release schedule that seems to be working for other projects, if we decide that it fits our needs. A disclaimer: if this is going to waste energy, we can delay this discussion to January. The same applies to the Kompare issue: let us follow the path that generates less stress for now, and move on to this 4.0 release. 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?)
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
Re: What to do about Kompare?
Excellent. Great News! Then I suggest you: 1) commit your patches into kdesdk/kompare 2) uncomment the add_subdirectory(kompare) line in kdesdk/CMakeLists.txt I need SVN commit access for that first. Oh,... but before doing that... any idea how many new i18n() strings are in your patches? I don't think they are any, I hope I haven't missed some, but I'm not aware of having added any strings which weren't already there before (assuming the directory still got translated even when not built - did it?). Kevin Kofler ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to do about Kompare?
Op Tuesday 11 December 2007 03:14 schreef u: If Kevin wants to take over maintenance, that's fine, but making Kompare ready for KDE 4.0 seems like a goal not reachable considering when the release is going to be. Hi Matt, Seeing the recent mail about the current state of Kompare from Kevin, which basically tells us it is working and he seems to want to actively maintain the app, do you still have the same opinion? I agree it's pretty late, but if there is an active maintainer and the current stat is ok, I feel we should give Kevin the chance (and motivation) to work on it and include it in four point oh. Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to do about Kompare?
On Tuesday 11 December 2007 05:08:09 Tom Albers wrote: Op Tuesday 11 December 2007 03:14 schreef u: If Kevin wants to take over maintenance, that's fine, but making Kompare ready for KDE 4.0 seems like a goal not reachable considering when the release is going to be. Hi Matt, Seeing the recent mail about the current state of Kompare from Kevin, which basically tells us it is working and he seems to want to actively maintain the app, do you still have the same opinion? I agree it's pretty late, but if there is an active maintainer and the current stat is ok, I feel we should give Kevin the chance (and motivation) to work on it and include it in four point oh. Toma Yes, I still have the same opinion. It's too late. We've already tagged RC2 and the full release is in less than a month. We need to quit making last minute changes like this. What happened to being in release mode? We quit adding new applications to KDE 4.0 months ago. I don't see how resurrecting old ones that were previously disabled is any different. However, seeing as the change has already been made, it doesn't really matter anyways and I have no legs to stand on for an argument anymore. It would have been nice if there had been a 24 hour wait period for feedback after the initial mail that Allen sent. -- Matt ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to do about Kompare?
On Tuesday 11 December 2007 14:10:36 Matt Rogers wrote: On Tuesday 11 December 2007 05:08:09 Tom Albers wrote: Op Tuesday 11 December 2007 03:14 schreef u: If Kevin wants to take over maintenance, that's fine, but making Kompare ready for KDE 4.0 seems like a goal not reachable considering when the release is going to be. Seeing the recent mail about the current state of Kompare from Kevin, which basically tells us it is working and he seems to want to actively maintain the app, do you still have the same opinion? I agree it's pretty late, but if there is an active maintainer and the current stat is ok, I feel we should give Kevin the chance (and motivation) to work on it and include it in four point oh. Yes, I still have the same opinion. It's too late. We've already tagged RC2 and the full release is in less than a month. We need to quit making last minute changes like this. What happened to being in release mode? We quit adding new applications to KDE 4.0 months ago. I don't see how resurrecting old ones that were previously disabled is any different. I prefer fixing above removing, if that can be done easily, it should be done. As to the freeze, kompare has been shipped for the last releases, so it was part of the release (IMO). Having kompare in is a low-risk decision as it doesn't touch other components and is a pretty end-of-the-food-chain application, and since the code to fix it has already been written, no damage is done. Another option would've been to move kompare into extragear, that means that it would be released at the same time (most probably) and packagers won't find it immediately. However, seeing as the change has already been made, it doesn't really matter anyways and I have no legs to stand on for an argument anymore. It would have been nice if there had been a 24 hour wait period for feedback after the initial mail that Allen sent. -- That would be good practise. We ended up doing the same 24 hours grace period for decisions in the Marketing Team as well, it adds a bit of safety to those taking decisions, which I think is a good thing. -- 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: What to do about Kompare?
On Tuesday 11 December 2007 20:40:38 Allen Winter wrote: On Tuesday 11 December 2007 10:07:09 Sebastian Kügler wrote: On Tuesday 11 December 2007 14:10:36 Matt Rogers wrote: On Tuesday 11 December 2007 05:08:09 Tom Albers wrote: However, seeing as the change has already been made, it doesn't really matter anyways and I have no legs to stand on for an argument anymore. It would have been nice if there had been a 24 hour wait period for feedback after the initial mail that Allen sent. -- That would be good practise. We ended up doing the same 24 hours grace period for decisions in the Marketing Team as well, it adds a bit of safety to those taking decisions, which I think is a good thing. Agree. And I apologize. I wanted to strike while the iron was hot. Kevin was very eager and I wanted to take advantage of his enthusiasm. I was notified about the Kompare vs. 3_way_kompare controversy only a few days ago and felt that quick action was called for in this case. But I should have waited for responses from the team before proceeding. -Allen, wearing the dunce cap again today Please note that I appreciate it very much that you're often taking the role of the final decision. There are only very few people who are both capable of doing so and not afraid of taking this responsibility. Thanks for that. -- 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: What to do about Kompare?
[EMAIL PROTECTED] wrote: I'm with Matt here, as much as i'd love a kompare on KDE 4.0 we began removing unmaintained games and not allowing new ones in kdegames quite a time ago, actually when the schedule said so, so if we had applied the the same rule to kdesdk, kompare would have been out of KDE 4.0 already months ago. Just to give some context to this, we actually had a deadline for removing unmaintained and unported games in July 2007, according to the initial schedule. And we stick with it, naively :) After that date, nothing as well moved from playground to the module, including games that are mostly done, and we ended up removing more apps in the last couple of months as their state was not great. The effect was that the games module lost some of its momentum, due to our willingness to play by the release schedules. Looking back it was maybe a stupid idea, and we should have continued working on the playground ones, moved them to the module after the deadline, and we would had a tetris and a breakout game for 4.0. Suggestion: for 4.1, I think we should really try to follow the schedules we propose to ourselves. Or break the rules when needed, in a global way for all modules. I understand that not adding Kompare for 4.0 can have an effect on the motivation of the new maintainer, but I can also guarantee you that allowing it to go in (a done deal) also has an impact on some of the members of the games module that will not have their apps in 4.0 because they missed the July cut, and stick by the schedule. To finish, I also think we really need to get this 4.0 thing out, as we are stressing about smaller things almost daily :) Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to do about Kompare?
A Dimarts 11 Desembre 2007, Allen Winter va escriure: On Monday 10 December 2007 18:04:16 Kevin Kofler wrote: In Bug 153463 [1], Kevin Kofler provides some patches to make the current Kompare code in kdesk compile (and work, I guess). It definitely works here, at the very least. :-) Kevin, would you want to take over kdesdk/kompare and make it work for KDE4.0.0? Else, I guess we won't have kompare in KDE4.0. Yes, I'm willing to pick it up. Excellent. Great News! Then I suggest you: 1) commit your patches into kdesdk/kompare 2) uncomment the add_subdirectory(kompare) line in kdesdk/CMakeLists.txt Oh,... but before doing that... any idea how many new i18n() strings are in your patches? Give him a powerful bugzilla account and set him as default bug owner too. Albert -Allen ___ 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: What to do about Kompare?
On Monday 10 December 2007 18:18:04 Kevin Kofler wrote: Excellent. Great News! Then I suggest you: 1) commit your patches into kdesdk/kompare 2) uncomment the add_subdirectory(kompare) line in kdesdk/CMakeLists.txt I need SVN commit access for that first. Ok, I committed your patch in the meantime. kompare now exists in KDE4.0! Please send an account request to [EMAIL PROTECTED] according to the instructions at http://techbase.kde.org/Contribute/Get_a_SVN_Account Tell them you just became the kompare maintainer and you have a lot to do. Also ask them to make you the new owner of the kompare product on bugs.kde.org so you can manage kompare bugs. Oh,... but before doing that... any idea how many new i18n() strings are in your patches? I don't think they are any, I hope I haven't missed some, but I'm not aware of having added any strings which weren't already there before (assuming the directory still got translated even when not built - did it?). Let's not worry then. Not until the translators scream that a new app just arrived. Yikes! Welcome Aboard Kevin! ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to do about Kompare?
On 10.12.07 18:13:20, Allen Winter wrote: On Monday 10 December 2007 18:04:16 Kevin Kofler wrote: In Bug 153463 [1], Kevin Kofler provides some patches to make the current Kompare code in kdesk compile (and work, I guess). It definitely works here, at the very least. :-) Kevin, would you want to take over kdesdk/kompare and make it work for KDE4.0.0? Else, I guess we won't have kompare in KDE4.0. Yes, I'm willing to pick it up. Excellent. Great News! Is there already a dedicated list for kdesdk or even kompare? lists.kde.org didn't show anything and neither does mailman on mail.kde.org show anything. Reason I'm asking: I'm willing to help out with kompare and especially the 3-way branch. KDevelop4 will need a good diff-viewer and 3-way-merge tool and while I'm not up for maintainership due to time constraints I'm certainly willing to help out as time allows. Andreas -- A few hours grace before the madness begins again. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to do about Kompare?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 10, 2007, at 4:50 PM, Allen Winter wrote: Howdy, Kompare currently isn't being built in kdesdk. In fact, the kdesdk/CMakeLists.txt file has this line: MESSAGE(STATUS Kompare from the branches/work/kompare/3-way- kompare will replace \ this version, so do not spend too much time on getting this version to work as it will be replaced.) In Bug 153463 [1], Kevin Kofler provides some patches to make the current Kompare code in kdesk compile (and work, I guess). I haven't tested the patches myself. In the past few days he even provides patches to forward port stuff from the 3-way-kompare branch to kdesdk/kompare. Separately, Maksim told me that the 3-way-kompare branch hasn't been touched in almost 2 years. In [1], I ask Kevin if he wants to take over maintenance. But he never responded. So.. how to proceed? Kevin, would you want to take over kdesdk/kompare and make it work for KDE4.0.0? Else, I guess we won't have kompare in KDE4.0. Comments? -Allen I'd prefer to not have a Kompare in KDE 4.0. It's too late. We should have been looking for maintainers or people willing to port apps a few months ago rather than right before the release. If Kevin wants to take over maintenance, that's fine, but making Kompare ready for KDE 4.0 seems like a goal not reachable considering when the release is going to be. - -- Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHXfJ7A6Vv5rghv0cRAsegAKCRDgyMmRCv/FVq/xWiaaFsP1tmwgCaA79D adc0fhq/UYtM5p2RRaDcQI8= =/p6c -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to do about Kompare?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 10, 2007, at 5:16 PM, Albert Astals Cid wrote: A Dimarts 11 Desembre 2007, Allen Winter va escriure: On Monday 10 December 2007 18:04:16 Kevin Kofler wrote: In Bug 153463 [1], Kevin Kofler provides some patches to make the current Kompare code in kdesk compile (and work, I guess). It definitely works here, at the very least. :-) Kevin, would you want to take over kdesdk/kompare and make it work for KDE4.0.0? Else, I guess we won't have kompare in KDE4.0. Yes, I'm willing to pick it up. Excellent. Great News! Then I suggest you: 1) commit your patches into kdesdk/kompare 2) uncomment the add_subdirectory(kompare) line in kdesdk/ CMakeLists.txt Oh,... but before doing that... any idea how many new i18n() strings are in your patches? Give him a powerful bugzilla account and set him as default bug owner too. Albert -Allen He needs to sign up for his own bugzilla account and then email sysadmin. - -- Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHXfPcA6Vv5rghv0cRArIlAKCq6hLXFzFSySw5VLBYZhG7TfoKpACePdcZ gwDVGmXIZtM77QAVHeksl8Q= =Yi6a -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to do about Kompare?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Dec 10, 2007, at 6:04 PM, Allen Winter wrote: On Monday 10 December 2007 18:18:04 Kevin Kofler wrote: Excellent. Great News! Then I suggest you: 1) commit your patches into kdesdk/kompare 2) uncomment the add_subdirectory(kompare) line in kdesdk/ CMakeLists.txt I need SVN commit access for that first. Ok, I committed your patch in the meantime. kompare now exists in KDE4.0! This is such a huge mistake. Why are we continuing to add things at the last minute? Please send an account request to [EMAIL PROTECTED] according to the instructions at http://techbase.kde.org/Contribute/Get_a_SVN_Account Tell them you just became the kompare maintainer and you have a lot to do. Also ask them to make you the new owner of the kompare product on bugs.kde.org so you can manage kompare bugs. Oh,... but before doing that... any idea how many new i18n() strings are in your patches? I don't think they are any, I hope I haven't missed some, but I'm not aware of having added any strings which weren't already there before (assuming the directory still got translated even when not built - did it?). Let's not worry then. Not until the translators scream that a new app just arrived. Yikes! Welcome Aboard Kevin! Let's not do it all and avoid translators screaming altogether! - -- Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHXfQxA6Vv5rghv0cRAp4jAJoDHu7EPrJaoB5mh6r+X9jCYHj5QwCfZYoa KyflxgHNzn+WCnuCg9eM8zQ= =S/mj -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
