Re: Review Request: aprs: use external QextSerialPort for TTY reading
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107536/#review22856 --- Ship it! Tjanks a lot Pino for your latest great Marble patches. This patch looks like a good idea to solve the QExtSerialDevice issue (And lazlo is right that in the future we should move to or offer parallel support for QSerialPort :-)). Hm, actually we should enable this aprs plugin by default :) - Torsten Rahn On Nov. 30, 2012, 8:24 p.m., Pino Toscano wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/107536/ > --- > > (Updated Nov. 30, 2012, 8:24 p.m.) > > > Review request for kdewin, Marble, Release Team, and Wes Hardaker. > > > Description > --- > > Instead of embedding an (old) copy of the QextSerialPort library, find for an > external one; only if found enable the reading from TTY, which is otherwise > disabled (leaving its configuration tab disabled). > > The drop of the internal QextSerialPort should also fix all the portability > issues, since the plugin itself does not use any OS-dependent API, and it is > then reenabled unconditionally. > Hence, bug 241125 should now be fixed, and bug 237931 and bug 242039 should > not happen anymore. > > @release-team: yes, I know this would introduce a new optional dependency, > but on the other hand a copy of a 3rd party library would go away. Would this > be acceptable at this point? > > > This addresses bug 241125. > http://bugs.kde.org/show_bug.cgi?id=241125 > > > Diffs > - > > cmake/modules/FindQextSerialPort.cmake PRE-CREATION > src/plugins/render/CMakeLists.txt d82293ee782e735ff1c90e6e13d330fb7cf8563c > src/plugins/render/aprs/AprsPlugin.cpp > f406cec2ad665977830416aa7f5df59851a5e430 > src/plugins/render/aprs/AprsTTY.cpp > c65ac38b24269b608c8f3ea1452b670f9422174d > src/plugins/render/aprs/CMakeLists.txt > fb6ef13c80568a72a5bfcf8a2e675b969238b9f6 > src/plugins/render/aprs/aprsconfig.h.in > d0e6b5c4ce36080dc0e59422529c55728ff04b3a > src/plugins/render/aprs/posix_qextserialport.cpp > 118843f02a5c62fd708b9157e59a039dff06e238 > src/plugins/render/aprs/qextserialport.h > 457d831cffc4ae8c43ac7db2d85a20546eb65044 > src/plugins/render/aprs/qextserialport.cpp > 790e5a2701ba1291a645c4fd4b09a8a1c55d7541 > src/plugins/render/aprs/qextserialport_global.h > 013a6dcd4ecab97425b1286139af4f0e911c38c9 > src/plugins/render/aprs/win_qextserialport.cpp > 5f21d7302e61b50825f79a68b352d5b9544b3fa3 > > Diff: http://git.reviewboard.kde.org/r/107536/diff/ > > > Testing > --- > > The Aprs plugin compiles fine with and without an external QextSerialPort > library. > > > Thanks, > > Pino Toscano > > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Dezibel-ḰDE
We have reconsidered the case and it looks like we'd rather like to see the dezibel-kde part shipped for KDE 4.3. Regards, Torsten On Friday 21 November 2008 18:33:26 Aaron J. Seigo wrote: > On Thursday 13 November 2008, Torsten Rahn wrote: > > It's important to provide and ship the Decibel-KDE libs support soon. You > > can't always assume that people will always use trunk to develop with. > > I'd claim that most people who develop against KDE 4 these days try to > > develop against the stable version of KDE unless there is a really > > important API enhancement in trunk that they need to depend on (and that > > this has always been the case. the majority of application developers do > not use trunk, and even if they do they realize many of their users don't > and so avoid using library features that are only in trunk. > > > > Which apps are using/want to use Decibel? > > > > Except for Kopete and other IM messaging clients there are possible other > > applications which could use Decibel: ? > > this is where we ought to be aware of KDE4's likeness to KDE2 more than > KDE3. in KDE3 we had a pretty strict "Must already be used in applications" > policy, while in KDE2 it seemed a lot more technology was added "because > applications should be able to $FOO". that's because in KDE3 we had what we > needed and we wanted to avoid unending bloat for no purpose while in KDE2 > (and KDE4) we were adding tools to let us do what we wanted to able to do. > > decibel certainly falls into that category. > > > as for the rest of Torsten's observations and comments, i think he's > correct across the board. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Dezibel-ḰDE
Hi, > Are there KDE apps that will use Decibel in KDE 4.2? > We only have a few days before the hard freeze so I don't know that > any apps will have the time to use Decibel-kde even if it were in > kdenetwork already. The motivation to include decibel-kde now is this: With the inclusion of Decibel into KDE 4.2 we want to enable and support implementation of new IM clients as well as porting of existing ones to Decibel. Kopete has already chosen Decibel/Telepathy as the way to go and we want to make sure they can start with parts that are fully part of KDE. In addition to Kopete there is a spanish group of university colleagues around aleixpol, which is applying to do a new IM application from scratch using Decibel and fully integrating it to KDE under a free sofware contest that's happening in spain. In addition we see activity around a telepathy/qt4 layer and mission control, Gnome is still strong with regard to this topic. We want to make sure we have a visible Decibel implementation, because otherwise further telepathy will likely not consider any KDE interests. It's important to provide and ship the Decibel-KDE libs support soon. You can't always assume that people will always use trunk to develop with. I'd claim that most people who develop against KDE 4 these days try to develop against the stable version of KDE unless there is a really important API enhancement in trunk that they need to depend on (and that they need to be aware of to use it). This is especially true for applications which are more "specialized" on a topic that doesn't focus on the interaction with the desktop environment itself. Shipping the Decibel-KDE libs with KDE 4.2 now would mean that people have a stable release of a tiny library that comes with their distribution and has got a stable release. Just to address possible concerns with regard to compatibility and stability of the interfaces: The core of decibel is supposed to stay stable, we rather will see extensions than changes. The Telepathy/Tapioca part will be changed for KDE 4.3 and will be ported to the upcoming Telepathy/Qt4 bindings. We were hoping the layer would be ready to port to earlier, but it still will take more time. However, APIs are not fundamentally different, so we expect porting changes acceptable. Most changes will arise from Qt 4.5's DBUS to be asynchronous in contrast to Qt 4.4. > Which apps are using/want to use Decibel? Except for Kopete and other IM messaging clients there are possible other applications which could use Decibel: * Marble: Plugin for viewing Presence-Information * Plasmoid for Presence-Information * collaborative Editing using Telepathy-Tubes. Decibel is the central place to start up applications for incoming channels * starting/controlling IM from other apps such as addressbook etc. Again I'd like to stress that rather providing a stable library as soon as possible that people can develop against is very important. As an example: If I would have changed Marble in some way that people would have needed to install trunk in order to develop for Marble I'm pretty sure that Marble wouldn't even have received half of the development that it got during the last half year, as several core developers either just use the stable KDE 4.1 version of the libraries or they just use the last stable Qt only version of Marble. Many of these people wouldn't compile trunk as the compilation would cost them the little time they have available for implementing Marble features. For the same reasons I'd strongly suggest to ship the decibel-kde lib rather early with a stable KDE release. As pointed out already we'll have several employees at Basyskom available who will be able to fix remaining issues as they are found during their working day during November, December and in January (Currently Dominik Haumann is available for this kind of work). Regards, Torsten ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Initial revision of KDE 4.1 schedule available on Techbase
> On Wednesday 13 February 2008 14:43:05 Torsten Rahn wrote: > > I think that the points of times for freezes and their definitions as > > suggested by Matt are quite good actually. I just feel that people won't > > get into release mode this fast, so we need to have a "real" alpha > > release in March first (and basically call your Alpha1 a Beta 1, etc.). > My impression (and the one of other, I gathered that from past discussions) > is that two months to stabilise a 4.x release should really be enough. More > time in freeze is not a good thing. Well, if you read my last mail closely you'll realize that I didn't suggest to change anything about the freeze milestones that Matt has suggested. However my suggestion was to have another release in March to get people into release mode early and to give users a chance to test new stuff early to be able to provide feedback and to give developers time to adjust to the feedback. With the current schedule I don't see this chance. Looking back it has always taken considerable time to get people to realize that now it's time to stop work on new stuff and to start work on bugfixing and polishing things. An early alpha would provide this clue. While with the development of LiveCDs it's much easier for people to test and follow KDE's progress it still takes a release to get the public's attention and the awareness of testers that "this development state" is supposed to be where the software is about to head and that the testers better give feedback now if they feel that stuff is wrong instead of hesitating. Looking back at e.g. the KDE 2.1 schedule which worked really well I notice that the first Beta there happened exactly 2.5 months before the actual release (i.e. December 18th, Beta 2 was on January 31st and KDE 2.1 on February 26th. So far the KDE 2.1 has been the most fast tracked release in KDE's history and given that KDE has grown quite a bit I'd consider it a true challenge to release within such a short time frame again while still delivering a quality release. -- 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: Initial revision of KDE 4.1 schedule available on Techbase
Hi, I mostly agree with Dirk. Personally I think that the current proposed schedule is unrealistic in terms of timescales. Having 2.5 months between an Alpha Release and a Final Release simply won't work. I'd suggest to have an Alpha Release in March, the first Beta at the end of April, the second Beta at the end of May and the Release Candidate at the end of June / begin of July. This would make sure that people get into release mode early again (otherwise we'll have too many construction sites still two months before the actual release). I think that the points of times for freezes and their definitions as suggested by Matt are quite good actually. I just feel that people won't get into release mode this fast, so we need to have a "real" alpha release in March first (and basically call your Alpha1 a Beta 1, etc.). Regards, Torsten > On Tuesday 12 February 2008 19:01:10 you wrote: > > On Saturday 26 January 2008, Matt Rogers wrote: > > > I've posted a new schedule on > > > http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Release_Sche > > >du le that should work as the nearly final release schedule. > > > > > > Feedback is appreciated. > > > > I have a couple of questions: > > > > a) "Binary compatibility is not required". what do you mean by that? > > you're saying that newly added features do not have to be binary > > compatible? you're saying that binary incompatible changes are allowed in > > kdelibs? > > That was something I ripped from the 3.5.x release schedule. It's intent is > to say that BC will not be guaranteed for new API. > > > b) Why a hard feature freeze for alpha1, e.g. before any user announced > > release? that doesn't make sense. we should have alpha releases that > > attract user attention and be able to react to the feedback, which often > > means changing or implementing new features. imho the feature freeze > > shouldn't be before beta1 or beta2. > > This is, again, something I did based on the 3.5 schedule. We can push the > feature freeze off until later. No problems for me. > > > c) Why a message freeze before beta1? bugfixes often require message > > changes. > > hehe, ok, so maybe basing my wording on the 3.5.x release schedule wording > wasn't such a good idea. When do you think it would be a good idea to put a > message freeze in place? RC 1? I don't particularly have a preference. > > > d) it is still a mis-aligned schedule, however I'm not going to complai > > too loudly about it given that it might slip by one month and then be > > aligned > > > > :) > > > > e) I like the no-new-artwork freeze. > > > > Greetings, > > Dirk > > Thanks for the feedback. I'll work on making the changes. Should be done by > the end of the week. -- 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?)
> 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: Delaying 4.0?
> From a KDE point-of-view: I doubt the extra time will help, given the holidays. I think that's a very pessimistic assumption. If I look at the past two years (which probably reflect the commit-habits of our current contributor base best) then I see that the month december has been even slightly better in terms of commit numbers than november. And looking at the last week of commits during the last year I see several names that are important to make KDE 4 shine :-) Torsten -- 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: [kde-ev-marketing] Delaying 4.0?
On Wednesday 28 November 2007 15:29:26 Sebastian Kügler wrote: > From a PR point of view, and for the sake of the release party, KDE is in a > state where we'd be able to present it at such an event. > I don't share your opinion on what's worse, party before release or party > after release. You really want to have the release out when you're showing > it to the public (which is what the event is all about, Industry, Press and > Community). Telling them that it's not released and thus still very much > vapourware would be "quite unfortunate" (read "sucks"). Well, at the current pace I'm pretty confident that we can do a decent release right in time before the release party (and I'm all in favour of the release delay Sebas suggested). However even if it turned out that we had to tag during the release party or even a week afterwards I don't see a big problem with that. There is no problem having a release party while you're doing the final stitches. By that time we _will_ have something that will resemble our final product pretty closely. However if I had to choose between 1.) the situation where in two years people remember that we had a release party that happened 1-2 weeks before tagging 2.) the situation where in two years people remember that we released KDE 4 some days too early with obvious showstoppers not being fixed just to meet the date of the release party. I'd gladly choose 1.). It's really better to have a release party during the last contractions while waiting for our baby to arrive than to go through all the hazzle of releasing something that sucks in terms of quality just to meet the date of the release party. In a few months nobody would remember the former "glitch" but everybody would remember the latter. And we for sure wouldn't be the first software project that would have a party immediately before the release either. Again as I said I'm pretty sure that we can get KDE 4.0 tagged before the release party. So let's concentrate on that right now. Torsten -- 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: Showstoppers, was: Re: Fwd: Re: Release Mode
> - QToolBox (Can someone show me what's wrong? I fail to find the issue here) Well,last time I checked the whole QToolBox-Widget didn't get painted at all in Oxygen. This means that e.g. Marble (which uses QToolBox) can't be used as intended as most of its features are hidden. You can see it in: http://www.kde.org/announcements/announce_4.0-beta3/edu_marble.jpg On the top left (where the empty space is located) the tabs "Navigation", "Legend" and "View" are missing. Switch to Plastique to see the difference. This makes it basically impossible for users who are using Oxygen to access different maps, different map projections and to adjust map settings. Torsten -- 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: beta5 or rc1
> I'd say this is quite off base No. It's not. Sebastian has advocated that the only way to "push" a project forward means _skewing_ technical terms for release states and _disregarding_ matter-of-fact criteria for a release. Sorry, but at this stage of development this is way off and demonstrates a pretty poor single strategy attempt. That being said I believe that Sebastian has awesome Community Management and Marketing skills, no doubt. > Bottom line is that we need to release, and we already know for a fact > that there will be bugs in the final release. With that attitude you can justify _any_ release date. Yes there will be bugs in the final release. But if we have the chance to ship an RC1 without any known relevant showstoppers a week later (without having the final release date being affected by slipping even) then I'd certainly prefer it like that. -- 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: Next Tagging
> > Wouldn't it be better to treat trunk as the stable branch, keep it frozen > > and release from that, if needed? This seems to be simpler to me and > > keeps people focused on what's important, releasing the desktop. We can > > branch the platform together with the desktop. > I do agree here. We should not open trunk to new features too early, as > that would draw the attention away from what we need to do now, which is > fixing issues in the current codebase. I fully agree with this one. -- 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: beta5 or rc1
Sebastian Kügler wrote: > I still do believe that more pressure in this > phase is good. This additional pressure means calling it -rc1, telling > people that this will be it if they don't fix their stuff. 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. As a result Marble will only receive a single week of full testing and this only by people who are able to build from source (read: developers only). Not that you get me wrong: 1) All bugs inside Marble that I'm aware of and that are critical for the release have been fixed already. So I consider Marble ready for a KDE 4.0 release. Still I would have liked it if users actually would have been able to fully test the KDE version of Marble. Unless they will change the style themselves (which is pretty unlikely for most people) this will not happen. 2) Don't get me wrong: Oxygen must be the default style for KDE 4.0: It's what people expect to be included and shown off by default in KDE 4. For some people it will be the most significant difference compared to KDE 3 even. Yes, this is just an example that concerns Marble. So I'm selfish in mentioning it. However I'm pretty sure that there are other examples resulting from the other showstoppers that affect other software as well (like a PDF viewer that essentially doesn't have printing tested). -- 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: beta5 or rc1
Sebastian Kügler wrote: > I would also see a release rather sooner than later. That's certainly what we all would like to see. Still we need to check whether it's possible to do that without releasing seriously broken stuff. Because that would even be worse PR. Look up rushed "Gnome 1.0" on the internet. Back then they rushed the release out of the door just for an announcement during LinuxWorld (and Redhat 6.0 inclusion). And this did hurt them a lot more than the "advantage" of being "right in time". Yes, many people remember them releasing during LinuxWorld however the same and even more people remember that this release was really really bad. Albert Astals Cid wrote: > okular still can't print (although it seems that might be done *soon*) so i > agree Well at the current point of time there is no way to get heard if you won't get more specific and commit yourself on an exact point of time. Tell a reasonably estimated date when printing will be done (unless you get hit by a car) and chances are much higher that okular's showstoppers can get considered while planning the release. So are you able to tell whether printing will be ready by Wednesday 21st (just like plasma will have stuff ironed out by then) ? Aaron Seigo wrote: > this is hardly a showstopper. not painting menus or tab pages would be; so > let's try not to distract the limited resources we have working on these I fully agree. If people who are responsible for the last few real showstoppers can up to their best knowledge be sure that the last few showstoppers will be ironed out by next wednesday then we should move the RC1 to Wednesday 21st. Given that a higher RC release frequency is pretty normal for software development I'd suggest that we still stick with the RC2 milestone Dec. 5th. As all real showstoppers should be ironed out with RC1 I don't expect that we need a full three weeks for the next RC 2 release after (unless there are any organizational issues left). Torsten -- 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: beta5 or rc1
On Sunday 11 November 2007, Torsten Rahn wrote: > of course, our show stoppers themselves are somewhat funny (as in "they > smell funny ... ") since last time i looked we did no have anything about > the keyboard shortcuts control panel not working at all (though this has > had the side effect of getting me used to the kde defaults again ;) 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. > i'm dangerously close to having resizable and movable panels. they'll be > done this week. multiple panels are there, xrandr works, xinerama works. > taskbar and systray both need bugfixes; i wont get to working on those > until next week, however. (i figure i only need 2 days to get the panel > stuff done, which means it'll take a week ;). So do I understand it correctly that you think that Plasma will have sorted out all remaining issues that are left for an RC1 only until next wednesday? Sounds good to me. > > involved with the last few showstoppers when those showstoppers will be > > fixed. Based on that we should decide how to proceed. I remember that > > this was done for earlier releases. It helped to make people commit > > themselves to get the release out of the door soon while at the same time > > making sure that we'd adhere to our quality standards. > this makes more sense to me: a ballance between "well, let's just slip the > date without putting any pressure on our work schedule" and "let's stick to > the schedule regardless of what we've accomplished". Balance is always good. But it needs to be based on criteria. The only balance I see is that we go through the showstopper list and see whether there are any "made-up" showstoppers left that could easily be removed by disabling related functionality. E.g. for the keyboard shortcuts e.g. I could easily imagine that we disable the related dialog completely (so no luxury of changing shortcuts, bad luck). On the other hand the QToolBox issue I mentioned is certainly something that is a showstopper for sure that can't get removed. > we should really strive to make a december release if at all possible (for > so many reasons which we've gone over so many times now), and that may well > mean a big final push. I'd love to see a release being tagged right before christmas. But I'd hate to receive a release from Santa where you get the feel that the QA Santa dwarves were on Christmas holidays already concerning the most basic functionality. :-) -- 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: beta5 or rc1
> Let's just do RC1 and get this thing out the door. I'm tired of > watching the release date slip and we don't do anything for the > project by allowing it to slip further. > > We _need_ to get a release out the door. Wrong attitude at this point of time. We are almost there and don't need to jump the gun (that's what you suggest). Let's carefully review whether all showstoppers for an RC1 have been solved. If this is the case then I'm indeed all for releasing RC1. If this is not the case then we should either consider postponing tagging for a week or we should just go for releasing Beta5 instead. At this point of time it's clearly obvious that we don't need to fear that it will take eternally to get KDE4 out of the door. I think it would be helpful if the release dude would ask the people involved with the last few showstoppers when those showstoppers will be fixed. Based on that we should decide how to proceed. I remember that this was done for earlier releases. It helped to make people commit themselves to get the release out of the door soon while at the same time making sure that we'd adhere to our quality standards. -- 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: Release schedule clarifications
back (which hopefully comes :) ) > > > Another issue that doesn`t seem to be solved so far is that we don`#t have > a clear list of things that are just there that are going to be deprecated > with the 4.0 release (kjsembed? khtml? kjs? plasma layouting stuff which (I > heard rumours) is going to be deprecated with Qt 4.4?)). > > > Thanks, > Dirk -- 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: Release dates/nomenclature -- Revised proposal
> October 22, 2007: Tagging Beta4 (Again, a Monday) > October 30 2007: Release Beta4 (Beta4 is only 2 weeks long) Having a Beta for two weeks long makes no sense. Betas are made to get feedback from the people who are meant to test the beta release. Subtract 8 days for packaging from the 2 weeks and about 3-5 days until people manage to get the spare-time to look at the release. Then how much time do developers have left to fix the issue reported from the last Beta to get the feedback right in time into the next Beta? None. So in that case people will report the same bugs for the next Beta. Brilliant. > November 13 2007: Tagging Release Candidate 1 (move closer to the freeze?) Same issue there. Too little feedback. Releases are not only there to pressure developers to get working but also to incorporate feedback from the testers. Personally I think the current suggested schedule is the first one that is close to being realistic. Except that I think that you won't be able to squeeze the release before Dec 20th without risking to delay the release highly likely again later on. Torsten November 5, 2007: Total Release Freeze (a Monday) November 20 2007: Release Release Candidate 1 November 21 2007: Tagging Release Candidate 2 (to close to -rc1?) Definetely too close to gather any useful feedback that -- 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
