Re: Release Candidate 2 and regressions
On Monday 02 January 2012 12.19.45 Martin Koller wrote: > > That's honestly too much for the release team. This has to be taken up > > within the teams. The release team doesn't take responsibility for > > code quality, the maintainers do. If they don't, their software will > > look bad. Nothing the release team can really do about it. > > I understand. So probably what is missing then is a group of decision takers > who simply can say "yes, we are ready to release" or "no release, there are > too many glitches, we should not simply release because we scheduled a > release" That group of decision makers exists already. Each component has its own maintainer simply because that person can be the only one that can judge the quality best. So, in this case, the owner of a component can decide to not include it in the main release. kmail did that in the past. Naturally, for something like khtml, which is part of the kdelibs, this is slighly harder. And one of the things that should go better in kde- frameworks. Either way; I think you are over-estimating the power of the release team. The release team can not do all the bugfixing and it can not make volunteers go and fix stuff. So its a cooperation with those component maintainers. In true open community spirits :) My point is that its best to take the quality issue in, for example, khtml, up with the component maintainers since the actual work rests on their shoulders. The release team can not, and should not, force them to fix their bugs. > I know how open source works as I'm contributing since a lot of years, but > seriously - until KDE manages to release good quality code it will not take > enough momentum for really widespread use. This is a common misunderstanding, and I think Sebas also wrote a really good reply elsewhere in this thread. Bottom line is that while regressions are indeed cause for concern, the amount of fixes, new features, and general cleanups that KDE manages to put in each release is so much that your statement just doesn't get real-world support. I certainly don't want to belittle your list of bugs, but we have to be reasonable and always check our premises. One thing you missed in your conclusion is that in open source the biggest QA department is its userbase. This is why we release often. This is why we have a pretty amazing closing rate of user-reported bugs in each release. And to keep that cycle going, we have to keep releasing often. Don't worry; the bugfix release after this one is only 1 month away. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: Requesting freeze exception for JtG
On Saturday 26 November 2011 14.09.21 Boudewijn Rempt wrote: > A little flexibility, a little actual testing of the patch > would be much more useful than stubbornly maintaining that > rules are rules. For those that missed it; the actual testing has been done and reported on kde-core-devel. (it has the same topic as this thread) The flexibility has been shown by various people; to quote sebas as one example; «I personally don't mind a non-intrusive patch (one that just changes the text in there, for example), if the translation and docs team is OK with that. This does not constitute a new feature to me.» -- Thomas Zander ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: Requesting freeze exception for JtG
On Wednesday 23 November 2011 18.25.23 Pau Garcia i Quiles wrote: > On Wed, Nov 23, 2011 at 4:21 PM, Thomas Zander wrote: > > I too think that a much less invasive patch has to be the first step to > > getting something accepted. > > As I said in k-c-d, the patch is deliberately invasive. It's no accident. The invasive nature makes the patch a high risk to integrate into a stable branch. It would be more appropriate for the frameworks, not so much for the frozen kdelibs. I think everyone understands your goal, and why you made it deliberately invasive. But the first priority has to go to the stability of kde apps. And when I last hacked the menu-merging code, I was surprised of its complexity and how easy it is to break one of the millions of apps using this code. So, your intention to be extra invasive means the patch is too high risk for kdelibs. As 2 other people also have suggested, I think you should try to get your patch into frameworks, not kdelibs. And try a much simpler approach (just some text added and maybe a new tab) for kdelibs. Hope that clarifies my previous mail :) -- Thomas Zander ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: Requesting freeze exception for JtG
On Wednesday 23 November 2011 00.09.41 Pau Garcia i Quiles wrote: > > And stop attacking me everyone. I'm just the messenger. > > Sorry I responded at all > > Allen, > > I think nobody is attacking you. I'm sorry if you felt attacked. It's > just at the eV sprint we realized the numbers we really really need to > boost Join the Game because we need money. That's why we have been so > pushy. Notice that the e.V. has as one of its main objectives that it does not interfere with the technical direction of KDE. My interpretation of this fact is that your point of "we need money" is null and void as an argument to add or alter code in kdelibs and break the freeze. The kde release team has to take this request like it would take any other exception on the common rules which Allen already pointed out. I too think that a much less invasive patch has to be the first step to getting something accepted. -- Thomas Zander ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
Like Aaron, I also have the greatest respect for the people doing the migration, I migrated koffice and that took a lot of time and effort (not to mention the many nights that test conversions were run on my only laptop with enough space) The emails were also not read by me to be an objection, more as a signaling that we have an open issue that needs solving. :) (to recap) The issue is that people following kde development previously had to know only a couple of module-names and a repeated update and compile was enough to stay up-to-date. Now people have to manually identify each sub-project and manually browse the projects.kde.org website and manually go a clone of each project. Added repos are almost guarenteed to be missed. On Sunday 21 August 2011 17.46.29 Aaron J. Seigo wrote: > kdesrc-build was recommended again .. i took the time tonight (after a > long day in Taipei working on behalf of KDE) to examine it "from scratch" > again. > > first the good news: it took me less time to set up this time than in the > past, so it is indeed improving. there is no doubt that it is an > impressive tool. Same here, I tried and failed some monts ago, now it seemed to behave better. The README still misses a "how thit works in 3 steps" and I ignored it and typed the command to compile kdeutils. The tool responded by doing a checkout of qt-copy. This is in line with what the description of the tool says; «kdesrc-build is a tool to allow you to easily build KDE from its source repositories. » This, however, is not directly similar to the problem that is being put forward :) Most self-compiler I know don't actually want a full build of KDE, they just want to replace one module with the development version of it. So the tool as it is now is not a natural-match. Maybe it can be changed to do that, but until that date I would say that we still need an automated way to; * allow user to select from all top-level modules. (kdebase, kdeedu etc) * initial checkout of repos * update of all repos and detecting new projects that can be cloned too. * optional are things like detecting new branches and allowing the user to switch to the 4.7 branch once it gets created. -- Thomas Zander ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
On Thursday 18 August 2011 22.21.46 Raphael Kubo da Costa wrote: > Basically, the current CMakeLists.txt in svn can still be used, but aneven smaller version which just does a series ofmacro_optional_add_subdirectory() calls. Going back to Aaron'smessage, where should I put these instructions? Is there a kdeutils.git repo where this can be put? I fully agree with Aarons message; the amount of time spent tracking down sub- projects and their git checkout line is a big cause of worry for me too. I had had the wish in the past to have a simple repo for a (former) module like kdeutils, and kdegraphics etc and that that module would have at minimum a script to do the checkout of the other repositories. What do others think about a solution of that kind? And is it applicable to our other (former) modules too? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Add some apps to the 4.7 release?
On Monday 16 May 2011 15.05.11 Sebastian Kügler wrote: > > > - Create a couple of stable releases, > > > > > > > > I was hoping that the last 13 years of KOffice releases would help with > > that request :) > > In your other email, you point out the following: > > "The request is only for those 3 apps and their plugins. This is a far > far cry from what was released before as "KOffice"." > > There's an obvious mismatch. There is an very obvious mismatch; the 3 apps have been released for many years but indeed they have been released together with half a dozen other apps and plugins in a more technically and promotially challenging setting. It doesn't change the fact they have been released many times before, which is what your initial request was about, wasn't it? -- Thomas Zander ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Add some apps to the 4.7 release?
extragear supports this mechanism quite well. > > If Thomas is looking for someone to put a bunch of tarballs online, but > making it part of KDE SC doesn't sound like the right thing to do for > us. > > Since there is at least some kind of disagreement how to go about this, > I'd suggest Thomas takes his request to kde-core-devel, to have it > discussed there in a wider group. Maybe everybody agrees with him, and > in that case, I won't be the party-pooper, but right now, it just seems > too politically laden for the release-team to decide. > > Cheers, -- Thomas Zander ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Add some apps to the 4.7 release?
Good evening Sebas and the rest of the release team. On Sunday 15 May 2011 21.22.00 you wrote: > > It needs saying that there are a lot of names behind this code and you > > will find hundreds of names in the commit lists of the repo in the > > last decode, a significant number of whom now work in leading Qt based > > companies. The time has come for the the apps to come home and be > > released together with the KDE SC. > > You really don't have to educate us about KOffice's history, especially > if you leave out interesting bits such as the recent fork in the > community. That just makes me feel more uneasy about this request. Oh, so sorry Sebas, I had no intention of leaving anything important out. The calligra guys have indicated they continue to release their software under the new name and as releases separate from KDE, I had no intention of hiding such information, I just reasoned it would not be relevant to this request. Again apologies for not being upfront about it. > If you'd like to work towards making KOffice part of KDE SC, the > following would help: > > - Resolve conflicts with the Calligra team (Wasn't there an arbitration > process?) The arbitration is about the name "KOffice" and its usage, I think thats been communicated to the ev membership at least, in case you want to review my statements. In my request to the release team to release KWord, Showcase and KCells there is nothing that interferes with that. If you disagree, I'd like to know. As an aside; I'll personally continue to be vigilant in my usage of communication and actions to avoid any breakage of trust from you and the wider KDE community, as you can and should expect of me. It is my hope that I didn't break any trust by this request as its an honest try to get this cool software to users. Nothing more. > - Create a couple of stable releases, I was hoping that the last 13 years of KOffice releases would help with that request :) > - Show that there's a team maintaining them behind it We have over 1100 commits since the 'fork', without counting the various plugins. Bugs getting reported on bugs.kde.org are all fixed in 'master' and I'd like to get that work out to users. > Once that has happened, we can revisit this request. I hope this helps a little with your worries, if you have any questions or concerns I will do my best to address them. -- Thomas Zander ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Add some apps to the 4.7 release?
Good evening to you all. On Sunday 15 May 2011 21.45.02 Tom Albers wrote: > - Original Message - > > > Hi Thomas, > > > > On Saturday, May 14, 2011 21:28:40 Thomas Zander wrote: > > > I've been stabilizing and making ready for release some apps (in > > > git) and I > > > would like to get them released in the 4.7 release compilation. > > > > For 4.7, the hard feature freeze has already passed, it's too late to > > add apps > > at this point. You've also completely ignored existing review > > processes, as > > laid out on techbase. From a pure process POV, that's a bunch of > > show- > > stoppers. > > I think it is important to know which scenario Thomas wants: > > 1. > Make KOffice part of the main modules. That's indeed past the freeze > date, lacks review and lacks maintainers for all apps, so that's a > no-go. > > 2. > Keep KOffice as it is and release together with the other parts of the > SC. That's fine for me. KOffice is part of the KDE infrastructure and > therefore allowed to join the SC release. More below, as I assumed > Thomas applied for this scenario. Apologies for not being more clear about this; I see that my mail could be read in different ways. Tom is right, my intention was his point 2. I hope thats possible. The confusion about this is my fault as I didn't explain the scope of my request very well. Sorry about that. The request is only for those 3 apps and their plugins. This is a far far cry from what was released before as "KOffice". Its just 3 apps where most of their code is shared in one lib, all of this is well maintained. I hope that makes clear the request is much smaller than you might think when you read this as a next koffice release. Its not a next koffice release, there is no political background other than getting the much more stable versions of this software to users. > > I don't have a problem with you releasing KOffice separately, but at > > the same > > time as the SC releases, but I don't think we should make it part of > > the KDE > > SC. > > We have released extragear application at the same time as the main > modules. We even released completely unmaintained applications at the > same time as the main modules. I don't see any reason why we would deny > this to the KOffice team. > > Just as Amarok is welcome to release at the same day as the SC, KOffice > is too. And they both can have their lines in the announcement. Just > because I don't like Amarok, does not entitle me to block it. If we > don't want KOffice in the SC, it's time to say that it should leave the > KDE infrastructure. > > Again, I'm not talking about scenario 1. Which I would oppose as well. > > Best, Thank you Tom. -- Thomas Zander ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Add some apps to the 4.7 release?
good evening people, I've been stabilizing and making ready for release some apps (in git) and I would like to get them released in the 4.7 release compilation. Can you help me get through the steps to make this possible? Thanks. I have been working on several KOffice applications for well over a decade and after the first release together with KDE2.1 the koffice team back then (which included David Faure, and other famous people) wanted to keep a release schedule that was slower than KDE to allow the apps to mature more between releases. It needs saying that there are a lot of names behind this code and you will find hundreds of names in the commit lists of the repo in the last decode, a significant number of whom now work in leading Qt based companies. The time has come for the the apps to come home and be released together with the KDE SC. The work done since the last standalone release is mostly in making what already was there work better and without crashes or misbehaviors. As such users will get a significant upgrade when they get this new release. I hope you will agree :) The applications I am interested to see included in the release are; * KWord * Showcase * KCells As well as everything the koffice-plugins.git contains. Thanks for reading -- Thomas Zander ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
konsole resizes annoyingly ;) Show stopper?
I personally find this a showstopper, so I thought I should at least give you
guys a heads up;
http://bugs.kde.org/show_bug.cgi?id=172042
I 'fixed' this bug locally like this
Index: apps/konsole/src/MainWindow.cpp
===
--- apps/konsole/src/MainWindow.cpp (revision 866514)
+++ apps/konsole/src/MainWindow.cpp (working copy)
@@ -106,7 +106,7 @@
correctShortcuts();
// enable save and restore of window size
-setAutoSaveSettings("MainWindow",true);
+//setAutoSaveSettings("MainWindow",true);
}
void MainWindow::removeMenuAccelerators()
{
Cheers!
--
Thomas Zander
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: show stopper list?
Hi, here is what I know; To be honest, I don't check the bugs.kde.org, I know about 162793, which you quoted, because its been reported to TT (see comment 7 there). I don't know about the other bug that Rex quoted. 162793 is fixed in Qt, as I wrote, and is separate from the crasher that david put a patch for in qt-copy a week before. I asked our QA team to put it in 441, but its not decided upon just yet (TTId 219800) On Monday 21. July 2008 18:29:03 Sebastian Kügler wrote: > On Monday 21 July 2008 17:06:55 Rex Dieter wrote: > > Pino Toscano wrote: > > > Alle lunedì 21 luglio 2008, Rex Dieter ha scritto: > > >> One of the critical/annoying kind: > > >> * okular: print pdf produces no output, also print to file broken : > > >> http://bugs.kde.org/161759 > > > > > > Blame Trolltech, not Okular. > > > > Then please comment so in the bug, so more time/resources aren't wasted > > trying to figure it out for ourselves (in kde). > > From a discussion on IRC with pino and dfaure, I understand that the patch > for that is supposed to fix it is in Qt 4.4.2 and also in qt-copy. It's > tracked as http://bugs.kde.org/show_bug.cgi?id=162793 > The patch proposed there doesn't seem sufficient to fix the issue though > (comments #20 and #21). Thomas reports is briefly as fixed upstream > afterwards. If that's a different patch that fixes it upstream, can we have > it for qt-copy? If not, the bug should be reopened (also in TT's tracker, > or a new one created, whatever you prefer.) If you want to reopen that, thats fine with me. I closed it because its not a bug in KDE. No use in keeping it open in bugs.kde.org. -- 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: Move kwalletmanager?
On Tuesday 15 January 2008 14:51:46 Allen Winter wrote: > But I still think we need module coordinators for kdebase, kdeutils and > kdetoys. Perhaps we should put out a help wanted? Makes sense to do that, yes. The thing with a list like this is that the people on it tend to be swamped by work already... Idea; what about Albert post a blog about his experiences of becoming a coordinator for l10n? I'm hoping its not too much of a horror story, naturally, but some positive feedback on the job will surely help others step up. Albert; you up for that? :) -- Thomas Zander pgpAoORk2wwVm.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Move kwalletmanager?
On Monday 14 January 2008 21:23:44 Tom Albers wrote: > So, can we come to some conclusion in this thread. Maybe the best option is > to leave it all as it is right now? I think that when Allen took back his proposal we reached that point :) -- 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: Move kwalletmanager?
On Sunday 13 January 2008 14:55:44 Stephan Binner wrote: > > I think it is fine in kdemultimedia. > > So workspace makes sound/noise (and not few) but you have no control > over volume/mute without an additional module? doesn't phonon provide volume support nowadays? Admittedly, you still need some backend installed. But you need that anyway to play sounds in the first place. Makes me wonder; if we want to have sound; we depend on xine or gstreamer, right? I mean; depend as in a packaging manner. No sound without installing some multimedia backend. On that note; doesn't it make sense to tell people they need kdemultimedia to have some sound? Assuming that kdemultimedia will actually pull in a backend automatically (again, thinking packaging dependencies here). Alternatively; (thinking a bit more long term now) someone should write a applet we can ship in kdebase which only depends on phonon and is capable of muting and altering main volume via phonon. Which then naturally does not depend on any backend. Just to point out that moving kmix to kdebase is by far not the only solution to this also not exactly black&white problem ;) -- Thomas Zander pgpvEkHCwie8T.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Move kwalletmanager?
On Friday 11 January 2008 09:42:02 Tom Albers wrote: > Hmm, you sure about this? I was working on Mailody the past week and it > did not save the password - and I did not have kdeutils installed, I > installed kdeutils yesterday and suddenly it works. I'm not 100% sure this > was the cause but at first glance it looks like it. If that's the case; its a regression from KDE3 where I am sure that indeed you don't need kdeutils to get KWallet functionality. -- 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: Move kwalletmanager?
On Thursday 10 January 2008 15:37:33 Allen Winter wrote: > I think we should move kwalletmanager from kdeutils into kdebase/apps. > The kwallet seems like a critical app that should always be available > in our base system. Hmm, in the normal user experience there is actually nothing that kwalletmanager provides that I call critical. The only think I know of is opening your wallet and reading passwords when konqueror or kmail fail to get them correctly. I'm assuming you don't think that creating/managing a second or 3th wallet is critical ;) What usecase did you have in mind for calling it critical? Or, what can't you do without it being installed? As always we need to draw the line somewhere; and I'm not convinced kwalletmanager falls in the boundaries of 'critical' at all. There is no functionality that falls away in other apps when you don't have it (passwords storage and retrieval continues to work) unlike, for example, the helpcenter. So, I'd love to see the above question about what usecases you consider missing right now when users don't have kdeutils installed answered. Just to be on the same page when we talk about this suggestion. Thanks! -- Thomas Zander pgpBQxMW9cHP3.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Shipping a cursor theme with KDE
On Friday 28 December 2007 00:55:14 Riccardo Iaconelli wrote: > > [*] And you're having a very relaxed definition IMHO, cursor theme > > have a special treatment and can ruin user experience. > > See above. > > Still, maybe it's me, but I don't really get your point. > For what I understand, the practical reason for deadlines (apart for > translations) is to avoid regression before a release, and be sure to > have a consistent and finished product. No, thats not the only reason. There is a psychological reason to it as well. See the first mail on kde-core-devel with subject 'release mode'. > Oh, and about the "sends the wrong signal to people" this is not true, > at least from how I understant this theme. Because I do think that this > is not really a new feature, You hit one of the psychological issues exactly on the head here :) It may look like a new feature to some, it may not. So there should be a clear line and something that is very predictable to everyone using svn and not open to interpretation. I'm kinda in agreement on the not-for-this-release part. But the main reason for writing this mail was to strengthen the reasons also given by Kevin. -- Thomas Zander pgphT9kq1gqSg.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Modules and Maintainers
On Tuesday 18. December 2007 12:20:19 Sebastian Kuegler wrote: > > And there are still apps that haven't been ported, with their code laying > > around in trunk. We should have a list of each application with its > > maintainer. > > It'd be interesting how many more of those 'borderline' apps we have lying > around, I didn't really keep track of that ... KOffice doesn't have a maintainer, and there are various apps that are unmaintained (and buggy). KoShell and Kugar come to mind... Various filters suffer the same fate. I also have pity on anyone that tries to be the maintainer, I tried to maintain various bits but lets just say I have gained a deep respect of coolo (and the thickness of his hide ;)... All this as an FYI :) -- 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: GStreamer backend on kdebase
On Friday 14 December 2007 20:48:04 Albert Astals Cid wrote: > Vir says it does not work and it's not expected to work. That sounds odd... > 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. This code has been tested by various people (including myself) over the last weeks and it works great. On contrast, I never got anything sane out of the xine backend. I'm not sure what the problems you are referring to, but it surely is not a black and white thing. Multimedia is hard. Has there been a discussion with the trolls that maintain this code? (cc-ing) One of them, Jens, was still waiting for his svn account when I talked to him last night, as soon as that process is completed I'm positive he will fix any issues you might find. The code has been tested and has seen peer review from quite some people inside TT, so I don't think its fair to equate it to new code and the rules we have for that kind of code inside KDE. On top of that; this is a piece of code that gives people choice. If it doesn't work it doesn't take anything away. The xine backend is known to have problems, what is wrong with giving people a second choice if the xine one doesn't work for them. I think that is the bottom line here is; do we want phonon to work for a bigger chunk of people or not? Having more backends seems like a good thing to me... Oh, One thing with your mail. While I value Virs opinion immensely; he stated on his blog that he never looked at this multi-thousand LOC codebase before last week. So any statement that it can't work might be a bit quick, don't you think so? -- Thomas Zander pgpRuwnnXOSv9.pgp Description: PGP signature ___ 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: KCalc's Future
On Sunday 09 December 2007 12:36:51 Tom Albers wrote: > Op Saturday 8 December 2007 20:40 schreef u: > > I'm not sure there is a > > strong need for a maintainer. Its got well below the average amount > > of bugs (22) > > We are aming for a maintainer for each application. See for example the > gmp-issue, that still needs to be resolved. I did some quick bug triaging and there are just 18 open bugs left. One of them is most likely actually an oxygen bug (#153166). Such a low bug count may very well have something to do with the lack of maintainer, and using that as a reason to throw away code that *just works* is something I strongly object about. Anyway, that's just to make my opinion clear on such issues, I guess we actually have a maintainer so lets close this thread :) -- Thomas Zander pgpFaRMEkiFjC.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KCalc's Future
On Saturday 08 December 2007 20:59:48 Albert Astals Cid wrote: > So you mean typing 3 + 3 Enter and getting a 0 is the expected > behaviour? Hi Albert, thanks for one of your always illuminating emails :) I think that since we have seen various people try to reproduce it and it works correctly for most of them that, sure, there is something to investigate. But since you made it really clear you don't want to spent time on it, and so far you are one of the only developers actually seeing this, I fail to see that being significant in any way for kcalcs standing in the release. -- Thomas Zander pgpsTykAsMmlZ.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KCalc's Future
On Saturday 08 December 2007 20:00:08 Allen Winter wrote: > Hi Bernd, > > You are listed in kdeutils/AUTHORS as the maintainer for KCalc. > > Speaking for the KDE 4 Release Team.. I am wondering what > your plans are for KCalc in KDE4. There has been a lot of > mail going on in kde-core-devel discussing some critical > issues with KCalc There have? Can you provide me with a link since I can't find any such mails... I tried a full-text search on 'kcalc' in kmail. > and we haven't heard from you. There was one thread on this list which grossly overstated problems (none actually exist anymore) for the app, I didn't expect any mails from bernd myself. So, either I'm missing various mails, and in effect the reason for your mail, or this is based on some misunderstandings. In my tests kcalc from svn fits the role of a general purpose desktop calculator perfectly. So your mail surprises me, I'm not sure there is a strong need for a maintainer. Its got well below the average amount of bugs (22) *confused* -- Thomas Zander pgpENEICGBNKA.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: [Kde-pim] Request to exclude KMail from the KDE 4.0 release
On Friday 07 December 2007 16:15:01 Cornelius Schumacher wrote: > On Friday 07 December 2007, Sebastian Kuegler wrote: > > On Friday 07 December 2007 00:49:08 Allen Winter wrote: > > > Yes, KMail is really as bad as indicated in the enclosed message. > > > And so are many of the KDEPIM apps. > > > > That matches what Mirko of KDAB told me. He also said that it should be > > fine by April. > > "should be fine" is always a disturbing statement ;-) Depends entirely on the track record of the person(s) making that statement :) -- 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: KDE/kdelibs
On Wednesday 5. December 2007 10:44:15 David Faure wrote: > > Since it didn't, and he fixed all of kde-svn, I'm not particularly in > > favor of the requested revert... > > I didn't revert; I simply re-added a method with the old name [and almost > but not exactly the old behavior; a better behavior]. > > I didn't mark it as DEPRECATED because it actually does something useful > now (as a convenience method). Ah, great. Thats a good solution, sorry for stressing out here :) -- 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: KDE/kdelibs
On Tuesday 4. December 2007 19:38:07 Dirk Mueller wrote: > On Monday 03 December 2007, Hamish Rodda wrote: > > Replace KAction::associateWidget() with a set of methods to permanently > > associate / dissociate a widget with an action collection. This does not > > change the shortcut context, in contrast to the methods that I removed > > about a month ago; this approach was thought to be ok (in comparison to > > the one I removed) because it does not cause modification of the actions > > being added to the collection. > > > > Also, add all xmlgui client actions to the top level main window. > > > > These two changes fix bug 151421 and duplicates / related bugs. > > > > It is BIC as I have removed the old associateWidget(), for which I will > > commit patches to the rest of KDE which use it now. > > even worse, it is source incompatible. Did you notice that we have released > a stable platform that is now broken again? > > can the associateWidget() call be restored? Would be nice if this was replied to his repeated requests for feedback on k-c-d where he pointed out the incompatibility. :( Since it didn't, and he fixed all of kde-svn, I'm not particularly in favor of the requested revert... -- 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: new showstopper in kdegames
On Wednesday 28. November 2007 18:37:13 Andreas Pakulat wrote: > I'd like to add a new showstopper to the 4.0 release goals. lskat from > kdegames is completely unusable since revision 731909. Can you revert the bad change? -- 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: Removing kregexpedit and kcalc
On Monday 26. November 2007 20:30:51 Albert Astals Cid wrote: > > So, how about debugging and fixing that issue? > > My mood is past the line of trying to debug and fix programs i don't know > and i don't care, sorry about that. Ok, fair enough. I think we should avoid proposing to delete based on that, though. KCalc seems to actually be releasable and working for a substantial set of users :) -- 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: KDE Dev Platform Status
On Monday 26. November 2007 17:53:17 Dirk Mueller wrote: > On Sunday 25 November 2007, Sebastian Kuegler wrote: > > We should tap into coolo's experience here. My proposal would be to have > > one last BIC (but SC) monday. That should get us the critical > > stuff/fallout, and not break things. I hope. > > Aha. Why did we release the platform if we break BIC one last time? Either > we keep BC or we don`t. Why can be answered as 2 different things; 1) Because there are some showstoppers that can be fixed in a MUCH better way when BC is ignored. 2) Because there is nobody 'out there' that will find it a really big problem if we do break BC before we make a final release for the simple reason that this exact released version will not be in any distro's official release. So, the real question is why not allow this for critical bugfixes. (and those only, obviously or else we'll need one in 2 weeks again). ps. one such bug I'm thinking about is the kactioncollection one (151421) -- 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: Removing kregexpedit and kcalc
On Sunday 25 November 2007 17:21:08 Albert Astals Cid wrote: > Both don't work at all, and there's no maintainer. I vote for them to > be removed of KDE. Try posting a blog first to ask if someone will step up to do the work. -- Thomas Zander pgpjb8rG1WlFp.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Application Version Numbers
On Friday 23 November 2007 14:34:06 Allen Winter wrote: > Which brings up Dirk's (IIRC) idea of automatically assigning version > numbers based on the KDE release number. Sounds like a great idea to me for all apps where there is no active maintainer. -- Thomas Zander pgphzZj3J2I70.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: getting together all release critical for KDE issues in Qt4
On Tuesday 20 November 2007 23:00:35 Aaron J. Seigo wrote: > i'll be maintaining this list (hopefully with help, but even without) > to keep track of all release critical issues that deal with upstreams. I think its a good idea; maybe add the upstream bug-id or link to it? -- Thomas Zander pgpXD6EngR354.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
kwin status
Hi, I have been running KDE4 as my main desktop for the last couple of days and plasma is shaping up nicely; lots of thingies missing but I sure people are aware of that. What I have not seen any emails about is that status of kwin. I really got scared of the amount of problems in kwin. From focussing problems (loads of em) to missing support for xinerama. I hope this is on the radar! -- 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: Next Tagging
On Thursday 15 November 2007 16:52:47 you wrote: > On Tuesday 13 November 2007, Thomas Zander wrote: > > > Tomorrow 14 November is a big tagging day. > > > > Would it be possible to include the next KOffice alpha? > > sorry, forgot about it. do you want it to be called 1.9.95 or 1.9.96? > tarballs is essentially ready once this question is answered :) KOffice 1.9.95 (2.0 alpha-5). Thanks! -- 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: beta5 or rc1
On Tuesday 13 November 2007 22:27:46 Torsten Rahn wrote: > Well, I'd like to thank you personally that tagging rc1 tomorrow will > mean that people won't be able to fully test Marble due to the QToolBox > issues mentioned. As you can imagine I truely love that "additional > pressure" that you advocate in lack of project management skills. I'd say this is quite off base and far from being friendly and cooperative as I'd hope (no, expect!) within KDE. You can disagree, but this is a personal attack on someone 'doing the work' and I personally don't tolerate those very well. Neither should anyone else. Bottom line is that we need to release, and we already know for a fact that there will be bugs in the final release. Just because there are sections that don't get the 'many eyeballs' treatment doesn't mean they are going to end up as crap. Making that claim is ignoring that you and I can actually find bugs without users telling us. I hope you get the feeling of "good release" soon anyway, and if you want someone to find bugs, I'd be glad to take a long and hard look ;) -- Thomas Zander pgpcilmjsJwK0.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Next Tagging
On Tuesday 13. November 2007 16:52:34 Allen Winter wrote: > Tomorrow 14 November is a big tagging day. Would it be possible to include the next KOffice alpha? That would be great :) -- 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: beta5 or rc1
On Monday 12. November 2007 15:18:49 Eike Hein wrote: > Andreas Pakulat wrote: > > Apart from that the oxygen windeco (AFAIK) doesn't adhere to the kde > > color scheme completely (it ignores the titlebar color that is set). > > There's a bugreport for that, but I can't find it right now. > > http://bugs.kde.org/show_bug.cgi?id=152030 That bug definitely is a showstopper. -- 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: beta5 or rc1
On Monday 12. November 2007 13:48:19 Sebastian Kügler wrote: > That's really 'only' two showstoppers left, I think the point is that Torsten noted that QToolBox is not supported. Besides that tabbed panes seem to not be supported (according to the page). I'm sure you agree that those are show stoppers. No doubt there is great progress. Just wanted to point out why I replied to Torstens mail :) -- 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: beta5 or rc1
On Monday 12. November 2007 13:15:51 Cornelius Schumacher wrote: > > Next to that; you should add your found bugs (or, missing feature ;) to > > http://techbase.kde.org/Projects/Oxygen/StyleWinDec > > Interesting how a Wiki page turns into a bug tracker. Why isn't Bugzilla > used for that? Apart from the "don't ask me, ask the devs!" I can speculate that there is no 'application' section for it on bugs and this seemed easier then request a new one. Or maybe it never crossed their minds. Donno. -- 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: beta5 or rc1
Hi Torsten, On Monday 12. November 2007 08:25:18 Torsten Rahn wrote: > > while > > we do have some pretty minor showstoppers. > > Well, last time I checked the default style didn't support QToolBox yet. > This basically rendered Marble unusable as people are not able to make use > of the interface. Did we make oxygen (the style) a showstopper? I thought we'd look at the quality when nearing a release and just ship with plastique as default if oxygen was not good enough. We don't want to repeat the problem we had in KDE3.0 ;) Next to that; you should add your found bugs (or, missing feature ;) to http://techbase.kde.org/Projects/Oxygen/StyleWinDec > On the other hand the QToolBox issue I > mentioned is certainly something that is a showstopper for sure that can't > get removed. You can use the default Qt style :) -- 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: Fwd: Re: [Kde-cvs-announce] Dev Platform Tagging Freeze Next Week
On Wednesday 07 November 2007 23:17:32 Matt Rogers wrote: > > Hehe, you did not read the message from Justin Karneges - 1st message in > > the thread. He actually hopes knowbody is using kdesupport/qca from > > trunk. > > I did read the message. That is why I recommended we recommend that > people use QCA 2.0.0. Since it's already been released, why is this a > problem? Its not; but the qca people should then move their stuff to extragear since its not a support module anymore (as you say, its widely available) Would that be acceptable to everyone? -- 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: Fwd: Re: [Kde-cvs-announce] Dev Platform Tagging Freeze Next Week
On Wednesday 07 November 2007 11:34:05 Sebastian Kügler wrote: > On Wednesday 07 November 2007 09:51:50 Tom Albers wrote: > > It's news to me too. > > > > I don't think this should be done this way. kdesupport follows kdelibs > > release path. > > > > So they should not use trunk kdesupport to work on the next version. In > > case they want to work on the next version, maybe they should move to > > extragear/libs like any other application/library. > > We need to document that then (adding qca2 to the techbase build > instructions then). If we switch to a released qca in this state, it'd also > need some testing. Wasn't the original reason for kdesupport to put code there that was required for building KDE? In light of that concept the stable version should stay in kdesupport. I doubt Tom wanted to remove it from kdesupport. If people want to have a place to work on it, they are free to have a working copy in extragear or somesuch to do so, but that is a separate issue from having a realease-ready copy in kdesupport. -- 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: kwin4 rename?
On Tuesday 06 November 2007 19:37:17 Allen Winter wrote: > Howdy, > > I'm wondering if the games team would be ok with renaming "kwin4" > so we reduce some confusion between this fun game and our KDE window > manager? /me throws in kwordquiz as something that might be open for a similar treatment ;) -- Thomas Zander pgpaHPR1SqGEQ.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] Make KDE PIM 4 installable in parallel to KDE PIM 3
On Sunday 21 October 2007 17:09:41 Allen Winter wrote: > Ah, so I see where you are going with this... do we want to have a > kmail4 that courageous people can try out and report bugs, but isn't > the default kmail? > > My opinion.. if the developers aren't brave enough to use KMail then we > shouldn't let the distros install it at all. +1 The recent addition of having both the 'normal' as well as the enterprise branch of kde-pim3 is confusing enough. Adding a kde4 one to the mix may prove to be too much for both users and distros to stomach. If you are worried about this; I suggest to make QA-testing your main feature-set your top priority and leave out features that have not gotten the attention they deserve from the main (first) release. -- Thomas Zander pgpjtWTNUOPez.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: PROPOSAL: Moving the KDEPIM Enterprise Branch into the 3.5 Branch
On Thursday 11 October 2007 00:31:05 Allen Winter wrote: > So my proposal is: > % svn mv branches/KDE/3.5/kdepim branches/kdepim-crappy > % svn mv branches/kdepim/enterprise/kdepim branches/KDE/3.5/kdepim 'kdepim-crappy' ? ;) Its the one we have been releasing for some time, not a good signal :) -- 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: blockers.
Missing email-adres from the debian packaging team, which I think is great to have on this list is interrested parties :) > Kde3libs and kde4libs is afaik currently coinstallable in the same > prefix (But is quite unusable, unless kde4base also can be installed > there) This I don't understand, what kdebase stuff needs to be coinstallable, but is not yet able to do so? Icon themes either replace but mostly have a different name, which is the same for all things in 'runtime', even applications in runtime simply replace the old ones. Looking at workspace I think that debian wants to package that as a separate thing and make that package conflict with their kde3 counterparts (i.e. only have one installed at a time) because they really replace the kde3 *desktop*. This to me is like you the long standing concept that you can not have two versions of one application installed. (like apt 0.6 and apt 0.7) Am I missing some problems? -- Thomas Zander pgp0I4Ve65TwA.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Questions About the New Schedule
On Monday 01 October 2007 12:44:59 Cyrille Berger wrote: > > Thats not enough. somebody has at least to be able to confirm that the > > bindings *compile*. right now, kdebindings does not compile, and after I > > spent an hour or so looking, I'm sure that it can not compile for anyone > > at all, given the fundamental bugs in the build system. > > I can confirm that the ruby part compile for me. Never tried csharp and/or > python. And I have no special local change. Maybe if you can provide > specifcs error message to [EMAIL PROTECTED] it would help the situation > (even if it's not you who fix the issues in the end). This is what I always use, may be useful for everyone; http://ktown.kde.org/~dirk/dashboard/ According to that, it has not build in almost 2 and a half months. -- 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: Questions About the New Schedule
Hi all, On Saturday 08 September 2007 15:08:02 Allen Winter wrote: > A few questions have come up about the new Release Schedule. > Namely: > > 1) Is kdelibs/kate exempt from the kdelibs freeze on 3 Oct? > [Ed: since the kate application may need to make fixes there] If API needs to be changed (SC) / added (BC) in this part to do bugfixes (not new features) in kate, that would seem reasonable. Otherwise I fail to see a reason to exempt the kate libs/app. > 2) Is kdebase/runtime/kstyles exempt from the kdelibs freeze on 3 Oct? > [Ed: since boemann told me that oxygen still needs a couple months] The way styles work, together with my experience working with Casper lead me to think that it makes most sense to have a mindset of 'release mode' there sooner rather than later. Oct 3 is still quite some time away, if the authors need help, I suggest asking for that on blogs/mailinglists. Bottom line; a style needs more time to stabilize then most apps (and needs more eyeballs as well), so I think we should avoid the question for exemption and work together to beat it into shape before the freezing. [no comments on 3, 4, 5] Cheers! -- Thomas Zander pgpcn7S1x8Ora.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release dates/nomenclature
On Thursday 06 September 2007 18:48:26 Helio Chissini de Castro wrote: > Can we please turn on krazy again ? > > Adrian blogged about that, so now my fear of damage is complete, people > already will ask "what the fuck is happening.." And divide more and > more attention to explain what we're doing to everyone and increase the > fud is exactly what we don't need now :-/ What FUD? His comment, for example, still shows zero comments. -- Thomas Zander pgp7GczYF03jl.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release dates/nomenclature
On Monday 03 September 2007 02:11:06 Allen Winter wrote: > There are several issues: > 1) people with limited experience trying to fix non-trivial stuff and > making things worse 2) people fixing trivial stuff which causes lots of > extra recompiles 3) people getting their hands in places they don't > belong I agree with this; the mindset is still very much on polish before the codebase closes. Never mind we froze some time ago, people are still doing it. With krazy showing all this low hanging fruit people get an urgency of "Oh, there is so much left to do!" but its all of the wrong kind. In the end people apparently become quite bad at simple procrastination :) so shutting down at least the discovery of bugs that are not relevant in this phase of development (freeze and all) makes sense, and can be explained to people under the guise of; what use is it to report bugs that you shouldn't be fixing right now anyway. -- Thomas Zander pgpvDburItnXY.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release dates/nomenclature
On Monday 03 September 2007 04:57:08 Pradeepto Bhattacharya wrote: > So maybe people come to common ground here and decide > which Krazy tests can be suspended temporarily and which can run. Which do you propose? -- Thomas Zander pgptCUNjAFPFE.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release dates/nomenclature
On Saturday 01 September 2007 17:30:34 Matt Rogers wrote: > That's no different than what we have now. The problem is that people > seem to be too interested in fixing Krazy issues rather than fixing > actual bugs. How do you propose we get them interested in fixing real > bugs? Stop running the not-so-interresting krazy tests? ;) -- Thomas Zander pgp76sFJraTPL.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release dates/nomenclature
On Wednesday 29 August 2007 18:23:40 Tom Albers wrote: > Well, I would rather take it one step at a time. I'm pretty sure we > need a beta after this beta Personally, I'm optimistic that when people realize that, really, its unacceptable to work on 'innovative' kdelibs stuff and more and more people start to run kdebase the pace of development will go up quite a bit. -- Thomas Zander pgpwq8UQr7TKQ.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release dates/nomenclature
On Tuesday 28 August 2007 16:36:34 Thomas Zander wrote: > Because of the new reality that the 'customers' of KDE are not just the > users downloading packages. Its also users that want to be able to get > a kubuntu CD shipped to them by email. ugh, shipped by snail mail naturally. -- Thomas Zander pgpIHt0PQM75e.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release dates/nomenclature
Hi Luciano, good question that is super important for our overall release strategy. On Tuesday 28 August 2007 12:29:02 Luciano Montanaro wrote: > Why the long delay between the tag and the announcement? > > If the announcement is meant for January 17, the tag could be delayed > until a week or so before that... Because of the new reality that the 'customers' of KDE are not just the users downloading packages. Its also users that want to be able to get a kubuntu CD shipped to them by email. [1] In other words; the time is to allow distro's to to their quality control and actually get the stuff out onto physical media to physical places. This also factors in the ability for magazines to print articles 'on time' for our release. Since a typical physical magazine has at least that time between deadline and being in the shops. 1) Or suse / mandriva / red-hat / etc. -- Thomas Zander pgpNOm5NPeAQn.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: ERROR: there are duplicated POT files:
On Wednesday 08 August 2007 11:34:33 Pino Toscano wrote: > Hi, > > now the "duplicates" left are: > kdgantt1.pot I removed this one just now. I recall someone saying that the l10n-kde4/scripts/process_orphans.txt should be edited. But there is no explanation in the file and I have no idea what that file does. (well it moves and deletes stuff, sure, but why?) So I left that one alone. Note that there is a kdgantt module in koffice now, not sure if that generates a pot, though. I'm sorry if I screwed anything up; but KDE translations are very close to black magic for me. And apparently there is nobody that knows more about this stuff that works on KOffice :) -- Thomas Zander pgpH1btFAComO.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: ERROR: there are duplicated POT files:
On Saturday 04 August 2007 08:36:17 Stephan Kulow wrote: > kdgantt1.pot Allen was right, please remove the one coming from KOffice. We no longer svn-import kdgantt1 but we have kdgannt (which is v2) now. That one doesn't have any *.sh file; so I guess we won't be seeing any duplicates. -- Thomas Zander pgpDZOlC3uk4B.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: tagging beta1
On Friday 27 July 2007 07:57:52 Boudewijn Rempt wrote: > People: what are the cool things you want listed in the changelog? What > are we definitively going to do for 2.0 final that we want people to > focus on instead of the bugs and gaps? I think it warrents repeating that the reason we are making this release is mostly to get new developers and bugreports, showcasing our product is a distant second. So while its ok to give a plan or strategy the changelog should be about what we already have in this (alpha) release, not what we plan to have done in a future final release. Exactly because we *want* people to focus on bugs and gaps. Its an alpha release and there is no need to hide it is incomplete, buggy and in need of lots of love. So the message IMO is; "this is an incomplete version, try it out and see the great promise this product has, find a piece that you think is worth hacking on and join us." -- Thomas Zander pgpdFdXg9KXIp.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: tagging beta1
On Friday 27 July 2007 01:24:31 Sebastian Kügler wrote: > Thanks, Dirk :> Thanks from me too :) > Is someone from the KOffice team on this list? Are there some > changelogs for KOffice, maybe an overview of what changed, what the > status is and what plans there are. Not really changelogs, as Boud also noted. While it may be alpha2 we never found the tarballs for alpha1. Which was silly as dirk placed them in the latest dir. I was just looking for a top-level koffice dir. Anyway; its the first public release and I hope we can have a nice part of the announcement for us (or, if the pr team thinks its better, have a separate announcement on the dot). Some words; KOffice2-alpha-2 is a release showing the integration of various KOffice-wide technologies with Flake[1] as its centerpoint. KOffice is already showing much better integration between applications and a more seemless shift from one application to the next. KWord has received a new text engine for better printing and WYSIWYG support and continually increasing support for fonts through work in Qt. KWord now can host vector art on its pages as well as bitmaps, it does text-runaround for non-square frames and has much improved support for right-to-left scripts. Cheers! 1) http://wiki.koffice.org/index.php?title=Flake -- Thomas Zander pgpEunr0UiQdS.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Are We Ready? Beta1 vs. Alpha3
On Tuesday 24 July 2007 16:09:42 Tom Albers wrote: > > Why do you think that? It sounds a bit based on being hopeful to me > > :) > > I think that because when there is a public beta, more users will use > the software and run into these problems. Hence increasing the pressure > on the developers responsible for that part (or annoy a developer so > much that he will fix it). But the difference in alpha and beta lies not in the willingness of the developer to delve in and do work, does it? What I've been trying to explain, and I feel you are not getting, is that when kdeprint moves from having 1 input format to having 2 (since Qt4) that requires a lot of rethinking and work all over the codebase. And I see that has not been done and that one dialog shows this very clearly. Your answer that this is just a bug seems to miss the point I'm trying to make. Bottom line; if fixing this problem requires certain rewrites and breaking of stability and possibly the breaking of the API, that to me is a module that is alpha quality. > I think all developers have a list of most hated bugs in kde4. That you say this makes me a bit sad; I'm not using this thread to push a bug I struggle with. -- Thomas Zander pgp1yZVx8Flb3.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Are We Ready? Beta1 vs. Alpha3
On Tuesday 24 July 2007 15:32:12 Tom Albers wrote: > That can be solved during the beta period, non? Why do you think that? It sounds a bit based on being hopeful to me :) The point of showing this dialog was that some very basic assumption that I bet is lined through all of this module has been broken since Qt4. And that's not your ordinary bug. I've been having (and posting reports on k-c-d about) this problem for the whole time since I started using the PDF creation framework from Qt4. Sad reality is that nobody seems to be really working on kdeprint. So, I hope it can be fixed[1]; how can we find out? 1) in the mean time KOffice uses QPrinter exclusively and is thus unable to use kdeprint at all. -- Thomas Zander pgpkh2xY4xDcy.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Are We Ready? Beta1 vs. Alpha3
I have been lurking for some time, I just want to comment on the release-based schedule thing which is a way of developing I'm a huge fan of. On Saturday 21 July 2007 2:51:51 pm Rex Dieter wrote: > > For anyone who missed Mark Shuttleworth's akademy talk... he stressed > > the absolute importance of regular, reliable release cycles. Not > > sticking to release schedules sucks. And I fully agree with just about all he said on that topic. One thing of importance is that he immediately conceded that KDE4 is a different beast altogether and this idea doesn't work for 4.0 This is the core point; > > Don't hold releases hostage for > > features. Again, fully agreed. But this is not about features; KDE4.0 is (still) about heavy refactoring and reinstating basic functionality before being able to release (a beta). The reason why the concept that Mark proposed can work is that you can just remove or not release a feature which is not ready. And thus avoid a schedule slip because that feature needs more work. But, unfortunately, we can't just leave out kcontrol or plasma because its not ready. So the release schedule must slip. I'd love to see the idea of timed releases based on optional-feature-inclusion in the future. But unfortunately Fedora will have to wait until "its ready" on this one. Cheers! -- Thomas Zander pgpLg4KYEPOoU.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [ANNOUNCE]: Updated KDE4.0 Release Roadmap
On Monday 25 June 2007 17:45:12 Dirk Mueller wrote: > On Saturday, 23. June 2007, Thomas Zander wrote: > > > * 27 June: Alpha2 Tagging > > > > Just in case casper didn't contact you guys; please tag KOffice as > > well at this date to include us in the alpha. > > whats the version number for it? I upped the version to 1.9.91 (from 1.9.90 it was before) in r680264. Textually; "2.0 alpha-1" To avoid confusion with the previously released version that the openSuse and Kubuntu guys made. Cheers! -- Thomas Zander pgpK7vtIX2hiG.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [ANNOUNCE]: Updated KDE4.0 Release Roadmap
On Saturday 23 June 2007 16:53:35 Allen Winter wrote: > Howdy, > > The Release Team officially announces the following changes > to the KDE4.0 Release Roadmap [1]: > > * 27 June: Alpha2 Tagging Just in case casper didn't contact you guys; please tag KOffice as well at this date to include us in the alpha. Thanks! -- Thomas Zander pgpiFa51X52Hi.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
