KDE release event
Hello release team: My name is C Lee and I want to participate to this event. I am most likely will come on Fridat, 1/18/2008. My organization is NTea I (C Lee) will be attending Most likely I will be there on Friday, 1/18/2008 No need for hotel reservation Thanks. regards, C Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE release event
[forwarded to release-*event*] On Saturday 05 January 2008 10:15:17 C Lee wrote: > Hello release team: > > My name is C Lee and I want to participate to this > event. I am most likely will come on Fridat, > 1/18/2008. > > My organization is NTea > I (C Lee) will be attending > Most likely I will be there on Friday, 1/18/2008 > No need for hotel reservation -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE 4.0.x planning
Hi, are there any opinions about 4.0.x release plans already? I would like to schedule 4.0.x releases in roughly monthly schedule, beginning with ~ end of the month. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.0.x planning
A Dilluns 07 Gener 2008, Dirk Mueller va escriure: > Hi, > > are there any opinions about 4.0.x release plans already? I would like to > schedule 4.0.x releases in roughly monthly schedule, beginning with ~ end > of the month. I agree, monthly updates seems a good idea to me. Albert > > Greetings, > Dirk > > ___ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE 4.1 planning
Hi, anyone want to start the lead on 4.1 planning? I would like to align with the timebased schedule, which means a release around September. I think something around April would be rather short, but I'm open to suggestions. It is unclear to me how the plasma mes^h^h^hproject is planning to advance. Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
On Monday 07 January 2008 13:51:27 Dirk Mueller wrote: > anyone want to start the lead on 4.1 planning? I would like to align with > the timebased schedule, which means a release around September. I think > something around April would be rather short, but I'm open to suggestions. > It is unclear to me how the plasma mes^h^h^hproject is planning to advance. Thanks for bringing it up. Trying to untangle two things here: timeframe for 4.1 and the release frequency. Why do you think April is rather short? (I do agree, although I think September is rather late ...). It also depends where we draw the "feature-but-not-a-bugfix-line". How about a 4.1 in June? I'm too very much in favour of a time-based schedule, as I wrote in an earlier email. For the release frequency, we have basically two options (at least those seem to be left after the previous discussion): - Release 6-monthly, that would align us with downstream (distros) - Release 9-monthly, that would align us with upstream (Qt at least, not sure about X, and its relevance in this context) I'm slightly leaning towards 6 months, hoping that this would give us back some traction with 'larger' distros which we seem to be losing lately. As to plasma, it's possible to ship updated applets from extragear-plasma, but I'm not sure how this would work for kdebase plasma applets. Having a configurable / movable panel before the Summer or September would be nice in any case ;-) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
I personally would like to at least try for a 6 month timetable. That would put us at about June, which seems reasonable. I know many people feel 6 months is too short, but personally it's annoying to have people filing bugs that I fixed 9 months ago. Release often I say. :-) If 6 months doesn't work out, then at least we tried. We can then fall back to 9 months or so. John ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
On Monday 07 January 2008, Sebastian Kügler wrote: > On Monday 07 January 2008 13:51:27 Dirk Mueller wrote: > > It is unclear to me how the plasma mes^h^h^hproject is > > planning to advance. let's compromise here: i can give the release team all the information it needs/likes, and in turn the release team can stop being asshats when asking for said information. "mes^H^Hproject" indeed. seriously, what did you think you were going to accomplish with that? > Thanks for bringing it up. Trying to untangle two things here: timeframe > for 4.1 and the release frequency. > > Why do you think April is rather short? (I do agree, although I think > September is rather late ...). It also depends where we draw > the "feature-but-not-a-bugfix-line". How about a 4.1 in June? personally i think july works well; that's 6 months from january, and would mean a feature free in may. the various reasons i'd personally like to see a quick turn around for 4.1: * we have a lot of 90% done stuff, such as the win/mac ports, akonadi, decibel .. it woul be great to have a quick release that gives those projects the opportunity to get into the game quickly (obviously this means asking these groups if six months works for them) * Qt 4.4 is imminent and so would bring our release cycles a bit more into coordination * it communicates the right things to downstreams: it sets a nice pace for our developers, lets our users know with clear action that we're done with feature based release schedules, etc. > - Release 6-monthly, that would align us with downstream (distros) > - Release 9-monthly, that would align us with upstream (Qt at least, not > sure about X, and its relevance in this context) thing is that 4.4 will be out this quarter. if 4.1 was done in ~6 months and then we go to a 9 month cycle after that, we'll align pretty well with new Qt versions coming out a few months before KDE versions. > I'm slightly leaning towards 6 months, hoping that this would give us back > some traction with 'larger' distros which we seem to be losing lately. lately? and it's because of a six month release cycle? note that no matter which 6 month release cycle we pick there will be N-(N-1) distros that we don't align with perfectly, where N is the number of interesting distros since pretty well none of them follow the same release timing afaik. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech pgpNFaLJXVyhn.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.0.x planning
On Monday 07 January 2008, Albert Astals Cid wrote: > A Dilluns 07 Gener 2008, Dirk Mueller va escriure: > > Hi, > > > > are there any opinions about 4.0.x release plans already? I would like to > > schedule 4.0.x releases in roughly monthly schedule, beginning with ~ end > > of the month. > > I agree, monthly updates seems a good idea to me. +1 here as well; we already have a couple of dozen noticeable fixes for plasma since the 4.0 tagging so i'm sure there'll be lots of new content to make such regular releases interesting for downstream. it would be great to even say "every N weeks, we freeze for tagging and put out a new minor release"; a reminder a week in advanced on k-c-d and k-d would be great too so that people are reminded... would likely help keep everyone's feet moving. Kevin and i talked quite a bit about time boxed schedules like this when he visited in the summer; well, he talked and i mostly listened ;) so perhaps Kevin has some input here as well? *nudge* -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech pgpbjMhu9S5PF.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.0.x planning
On Monday 07 January 2008 13:50:01 Dirk Mueller wrote: > are there any opinions about 4.0.x release plans already? I would like to > schedule 4.0.x releases in roughly monthly schedule, beginning with ~ end > of the month. Sounds sensible. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Bringing ebn krazy back
On Saturday 05 January 2008 20:57:52 Allen Winter wrote: > On Saturday 05 January 2008 08:14:03 Urs Wolfer wrote: > > I think it's now time again to enable all krazy checks for trunk. > > > > Bye > > urs > > I will do so. But first I need to add 4.1 apidox to api.kde.org. > > Should I enable all Krazy checks in extragear, playground, kdereview > and koffice too? > OK, full-krazyness should run tonight in all supported components, including: trunk, koffice, extragear, playground, kdereview. krazy is no longer run at all in the 4.0 branch. report problems to me. -Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
On Monday 07 January 2008 18:14:04 Aaron J. Seigo wrote: > On Monday 07 January 2008, Sebastian Kügler wrote: > > - Release 6-monthly, that would align us with downstream (distros) > > - Release 9-monthly, that would align us with upstream (Qt at least, not > > sure about X, and its relevance in this context) > > thing is that 4.4 will be out this quarter. if 4.1 was done in ~6 months > and then we go to a 9 month cycle after that, we'll align pretty well with > new Qt versions coming out a few months before KDE versions. Yep, that way thing would fall into place neatly. > > I'm slightly leaning towards 6 months, hoping that this would give us > > back some traction with 'larger' distros which we seem to be losing > > lately. > > lately? and it's because of a six month release cycle? Not sure about the root cause here, but Fedora, openSUSE and Ubuntu have 6 months schedules. For them, it's an advantage to have a new desktop version every release. Having a 9 month schedule makes that align less neatly. For the distros, it's a plus to have a fresh upstream product to integrate every half year. They could even shift their schedule in a way that the desktop is both fresh enough and well-integrated as they need. Of course, those reasons apply in pretty much the same way if we s/distros/KDE and s/KDE/Qt. > note that no matter > which 6 month release cycle we pick there will be N-(N-1) distros that we > don't align with perfectly, where N is the number of interesting distros > since pretty well none of them follow the same release timing afaik. That's actually surprisingly not true :-) openSUSE 11: May - July (no exact date known yet) Fedora 9:29 April 2008 Ubuntu 8.04: April 2008 So it is possible to 'somewhat' align with most major distros. Simplified, 6 months means we choose downstream to align to, 9 months means we choose upstream. The more exciting /me leans towards 9 months, the 'let's keep our distribution channels in mind'-sebas prefers 6. Note that I deem it *much* more important to settle down to a release schedule and stick for that than wether it should be 6 or 9 months. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
On Monday 07 January 2008, John Tapsell wrote: > I know many people feel 6 months is too short, but personally it's > annoying to have people filing bugs that I fixed 9 months ago. Then you should backport your fixes to the stable branch. ;) I'm for the September release. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org 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 4.0.x planning
On Monday 07 January 2008 13:50:01 Dirk Mueller wrote: > Hi, > > are there any opinions about 4.0.x release plans already? I would like to > schedule 4.0.x releases in roughly monthly schedule, beginning with ~ end > of the month. Very good idea! What about doing a new minor release each 3 weeks, setting this as fixed time? At least for the first period. Or, even better, promising with the announcment of the 4.0 a bugfix/minor release each 3 weeks for the whole lifespan of KDE 4.0. For a promo/marketing POV I think this would just rock, and will probably make many more users aware of how well and how fast is the development proceeding... what do you think? Bye, -Riccardo -- GPG key: 3D0F6376 When encrypting, please encrypt also for this subkey: 9EBD7FE1 - Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平 Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.0.x planning
Alle lunedì 07 gennaio 2008, Riccardo Iaconelli ha scritto: > On Monday 07 January 2008 13:50:01 Dirk Mueller wrote: > > Hi, > > > > are there any opinions about 4.0.x release plans already? I would like to > > schedule 4.0.x releases in roughly monthly schedule, beginning with ~ end > > of the month. > > Very good idea! > What about doing a new minor release each 3 weeks, setting this as fixed > time? At least for the first period. That's a too short time, as it would mean less than two weeks between a release and the freeze for the next one. Four weeks should be the minimum, I think. -- Pino Toscano 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 4.0.x planning
On Monday 07 January 2008 22:22:56 Riccardo Iaconelli wrote: > What about doing a new minor release each 3 weeks, setting this as fixed > time? At least for the first period. 3 weeks is really much too often. We'd be tag-frozen half the time and spent a couple of days a week rolling tarballs and annoying the media with yet another one-bugfix-release. It's not like releasing comes at no cost ... > Or, even better, promising with the announcment of the 4.0 a bugfix/minor > release each 3 weeks for the whole lifespan of KDE 4.0. That's even worse. :-) That said, we need to smoothen our release process somewhat, especially from the marketing POV. But I guess now that 4.0 (and with it feature releases) are there again, we can probably do with a one-paragraph text, the usual boilerplate and a link to the changelog. If only people would write changelogs... -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.0.x planning
On Monday 07 January 2008 14:37:42 Aaron J. Seigo wrote: > On Monday 07 January 2008, Albert Astals Cid wrote: > > A Dilluns 07 Gener 2008, Dirk Mueller va escriure: > > > Hi, > > > > > > are there any opinions about 4.0.x release plans already? I would like > > > to schedule 4.0.x releases in roughly monthly schedule, beginning with > > > ~ end of the month. > > > > I agree, monthly updates seems a good idea to me. > > +1 here as well; we already have a couple of dozen noticeable fixes for > plasma since the 4.0 tagging so i'm sure there'll be lots of new content to > make such regular releases interesting for downstream. > +1 here too. I like the monthly schedule. easy to remember. > it would be great to even say "every N weeks, we freeze for tagging and put > out a new minor release"; a reminder a week in advanced on k-c-d and k-d > would be great too so that people are reminded... would likely help keep > everyone's feet moving. > yes, we need to get better at communicating. we also need to keep the techbase schedule page updated. -Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
On Monday 07 January 2008 07:51:27 Dirk Mueller wrote: > Hi, > > anyone want to start the lead on 4.1 planning? I would like to align with > the timebased schedule, which means a release around September. I think > something around April would be rather short, but I'm open to suggestions. 6 or 9. hmm.. how many beta or release candidates do we expect? when would the feature freeze hit? if we do 1 beta, and feature freeze at that time. and then 1 RC. .. then I think 6months is enough. If we expect more than 1 beta or RC, then I think we need more time. -Allen ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
Put me down as another vote for at least trying a 6 month release cycle, with 4.1 in June. Now that the big baby is out, we can attempt to pack less changes into each release, but make them more frequent. If something is not ready by 4.1, then 4.2 is not that far away. Rinse, repeat. A 9 month interval for inclusion of new features and applications in the main release seems too long, at least for me. Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
On Monday 07 January 2008, Mauricio Piacentini wrote: > Put me down as another vote for at least trying a 6 month release cycle, > with 4.1 in June. are we really counting january as the first month of 4.1 devel? shouldn't we try and let 4.0 dust settle and get people focussed on bug fixing and what not? esp if we announce the release sched and say "it's six months.. except we're nearly a month into it now, sorry you didn't know" i would expect some devs to be a little annoyed ;) maybe i'm just being cautious but july sounds saner to me. note as well that akademy is in august so it will work out nicely to have a 4.1 out the door soon before that, in either case. > Now that the big baby is out, we can attempt to pack > less changes into each release, but make them more frequent. If > something is not ready by 4.1, then 4.2 is not that far away. Rinse, > repeat. A 9 month interval for inclusion of new features and > applications in the main release seems too long, at least for me. it's actually a 7 month interval, not 9. it worked well in the 3.x and 2.x days. it's also useful to remember than not everyone starts developing on the first day. our contributors, for work or personal reasons, often start and stop throughout the devel cycle. if the calendar-time window is too small we'll miss fitting some (many, even) of the man-hour sets needed to complete a given set of features. which is to say that 7 months of man hours is a huge amount of time to work on feature if you work on an app every day and are doing the usual not-world-changing-overhaul type development; but we're talking about 7 months of calendar time, not man hour time. a 4 or 5 month window is considerably smaller and as such risks putting features off for another release (and 2*6 is 12, which greater than 9 ;) the fact that this pace worked really well for us in the 3.x days should not be discounted imho. oh, and phonon: since Qt will be including phonon and it has a 9 month cycle, if we go to a 6 month cycle every 2nd or 3rd release (depending which way you look at it) we'll have mismatched phonon versions. it would be cool to avoid doing that if possible. that said, i'd like to see a 6 month cycle for 4.1. it's after 4.1 that i'm in favour of a 9 month cycle. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech pgpOhVhrOi3D1.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 7, 2008, at 3:04 PM, Sebastian Kügler wrote: > On Monday 07 January 2008 18:14:04 Aaron J. Seigo wrote: >> On Monday 07 January 2008, Sebastian Kügler wrote: >>> - Release 6-monthly, that would align us with downstream (distros) >>> - Release 9-monthly, that would align us with upstream (Qt at >>> least, not >>> sure about X, and its relevance in this context) >> >> thing is that 4.4 will be out this quarter. if 4.1 was done in ~6 >> months >> and then we go to a 9 month cycle after that, we'll align pretty >> well with >> new Qt versions coming out a few months before KDE versions. > > Yep, that way thing would fall into place neatly. > >>> I'm slightly leaning towards 6 months, hoping that this would >>> give us >>> back some traction with 'larger' distros which we seem to be losing >>> lately. >> >> lately? and it's because of a six month release cycle? > > Not sure about the root cause here, but Fedora, openSUSE and Ubuntu > have 6 > months schedules. For them, it's an advantage to have a new desktop > version > every release. Having a 9 month schedule makes that align less > neatly. For > the distros, it's a plus to have a fresh upstream product to > integrate every > half year. They could even shift their schedule in a way that the > desktop is > both fresh enough and well-integrated as they need. > Of course, those reasons apply in pretty much the same way if we s/ > distros/KDE > and s/KDE/Qt. > Why exactly do the distros matter when planning our releases? (I know I've asked this and it's been explained before, but I still don't get it. Perhaps I never will.) If you're just proposing a 6 month release schedule because that's what the distros do, well, then that's a load of bunk, IMHO. If you're proposing a 6 month release schedule because you think it provides good sustainable pace for the majority of us, then that's an actual reason. >> note that no matter >> which 6 month release cycle we pick there will be N-(N-1) distros >> that we >> don't align with perfectly, where N is the number of interesting >> distros >> since pretty well none of them follow the same release timing afaik. > > That's actually surprisingly not true :-) > > openSUSE 11: May - July (no exact date known yet) > Fedora 9:29 April 2008 > Ubuntu 8.04: April 2008 > > So it is possible to 'somewhat' align with most major distros. > > Simplified, 6 months means we choose downstream to align to, 9 > months means we > choose upstream. The more exciting /me leans towards 9 months, the > 'let's > keep our distribution channels in mind'-sebas prefers 6. > I'd prefer 9 months. As Aaron points out, there's lots of things that are nearly there that would be nice to showcase in 6 months, but there's also other things that are not. It really depends on how important those are vs. the stuff that's nearly ready. > Note that I deem it *much* more important to settle down to a > release schedule > and stick for that than wether it should be 6 or 9 months. Right now, I actually lean closer to 7 or 8 months. 6 seems to short and 9 seems too long. - -- Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHgs5aA6Vv5rghv0cRAulxAKCwurSxwWMxH6IUFGa2c+L1Nu413QCeO+xI BtHQrOCqyLtJphNJErwmumw= =xz9A -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
On Monday 07 January 2008 23:14:55 Andras Mantia wrote: > On Monday 07 January 2008, John Tapsell wrote: > > I know many people feel 6 months is too short, but personally it's > > annoying to have people filing bugs that I fixed 9 months ago. > > Then you should backport your fixes to the stable branch. ;) > I'm for the September release. I completely agree with Andras and think that 9 month release is better. KDE 4.0 release rush was already too much of a change comparing to what we did in the past. Let's get back right now to proven 9 month release cycle and experiment no more. PS: I don't want to see us writing messages like "KDE 4.1 is not yet KDE 4" ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
On Tuesday 08 January 2008 02:14:02 Matt Rogers wrote: > Why exactly do the distros matter when planning our releases? (I know > I've asked this and it's been explained before, but I still don't get > it. Perhaps I never will.) Distros are the ones that get our software to the user. KDE is a 'raw' product, we need the distros' integration work (adding an OS, that kind of details ;-)), There's a mutual dependency between us and the distros, we need them to get to software shipped for users, they need us because we provide raw material for their finished 'product'. Aligning schedules makes it easier for distros to ship new products based on new KDE versions. > If you're just proposing a 6 month release > schedule because that's what the distros do, well, then that's a load > of bunk, IMHO. If you're proposing a 6 month release schedule because > you think it provides good sustainable pace for the majority of us, > then that's an actual reason. Both applies. A 6 month cycle makes it easier to get our software also to our fellow developers. The KDE4 platform is in pretty good shape, so we probably don't need too much integration work (in the range of 8 - 6 weeks to settle down a 4.x). We will be building software on top of that, and not change the underlying system too much (so that we need lots of time before the code is releasable again). That gives us a good 4 months from release to next feature freeze. For larger changes, it basically means: "Work in a branch until you can get your code stabilised within 2 (worst case) to 6 (best case) months." That sounds reasonable to me. 6 months also keeps the amount of changes surmountable. With a stable basis, we can release more often, so the integration work (fixes in A with features in B to work together seamlessly) is done more 'in the process'. Less powerplanting, which I think is good. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
On Monday 07 January 2008, Alexander Dymo wrote: > On Monday 07 January 2008 23:14:55 Andras Mantia wrote: > > On Monday 07 January 2008, John Tapsell wrote: > > > I know many people feel 6 months is too short, but personally it's > > > annoying to have people filing bugs that I fixed 9 months ago. > > > > Then you should backport your fixes to the stable branch. ;) > > I'm for the September release. > > I completely agree with Andras and think that 9 month release is better. > KDE 4.0 release rush was already too much of a change comparing to what we > did in the past. Let's get back right now to proven 9 month release cycle > and experiment no more. i agree for after 4.1, but for 4.1 the following should be considered: - Qt 4.4 is out *very* soon now and it would be good to take advantage quickly of some of those things (like aliens and WOC) - future 9 month cycles would then align with Qt releases (they are on a 9 month cycle too) - we have quite a few things that are 90% done that would be good to get out sooner rather than later - this would give us a great way to show momentum (essentially because we have all those 90% done features just waiting in the wings) after 4.1 i agree with you completely though =) > PS: I don't want to see us writing messages like "KDE 4.1 is not yet KDE 4" i honestly don't think we'll need to =) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech pgpxPkFptILT4.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 7, 2008, at 7:49 PM, Sebastian Kügler wrote: > On Tuesday 08 January 2008 02:14:02 Matt Rogers wrote: >> Why exactly do the distros matter when planning our releases? (I know >> I've asked this and it's been explained before, but I still don't get >> it. Perhaps I never will.) > > Distros are the ones that get our software to the user. KDE is a 'raw' > product, we need the distros' integration work (adding an OS, that > kind of > details ;-)), > > There's a mutual dependency between us and the distros, we need > them to get to > software shipped for users, they need us because we provide raw > material for > their finished 'product'. Aligning schedules makes it easier for > distros to > ship new products based on new KDE versions. > >> If you're just proposing a 6 month release >> schedule because that's what the distros do, well, then that's a load >> of bunk, IMHO. If you're proposing a 6 month release schedule because >> you think it provides good sustainable pace for the majority of us, >> then that's an actual reason. > > Both applies. A 6 month cycle makes it easier to get our software > also to our > fellow developers. The KDE4 platform is in pretty good shape, so we > probably > don't need too much integration work (in the range of 8 - 6 weeks > to settle > down a 4.x). We will be building software on top of that, and not > change the > underlying system too much (so that we need lots of time before the > code is > releasable again). That gives us a good 4 months from release to > next feature > freeze. For larger changes, it basically means: "Work in a branch > until you > can get your code stabilised within 2 (worst case) to 6 (best case) > months." > That sounds reasonable to me. > > 6 months also keeps the amount of changes surmountable. With a > stable basis, > we can release more often, so the integration work (fixes in A with > features > in B to work together seamlessly) is done more 'in the process'. Less > powerplanting, which I think is good. > -- This is the best explanation as to why distros matter in our release planning that I've read. Thanks for that. I'll draw up a proposed schedule later tonight - -- Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHgtf7A6Vv5rghv0cRAgR1AJ9vICHG89TMkgTfgoXjEALuDhqBjACgneuv dhscJ01LA5FkIjk9DXfEcWc= =W1CW -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Proposed KDE 4.1 Release Schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Based on the feedback so far, I've come up with the following very rough schedule for KDE 4.1: April 28th: Soft Feature Freeze. Features not already finished or listed on the planned features page will have to wait until KDE 4.2. May 19th: Hard Feature Freeze. Any unstarted feature (even if it's on the planned features page) will have to wait until KDE 4.2. Any currently in progress features will need to be completed. May 19th: Tag KDE 4.1 Alpha 1 June 16th: String Freeze. Tag KDE 4.1 Beta 1 July 7th: Tag KDE 4.1 RC 1 July 21st: Tag KDE 4.1.0 July 28th: Release Announcement Not perfect, but it's a start. Comments? - -- Matt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHgtvSA6Vv5rghv0cRAuhXAJ9jtmCnZa8wl+pUpSTfd0U9k9F5pgCeM6uv dKP4zB5oPsvEApV7TZydBUo= =dDuM -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
On Monday 07 January 2008, Sebastian Kügler wrote: > 6 months also keeps the amount of changes surmountable. With a stable surmountable is good. anemic is not. the cycle needs to be tuned to the size of the project and where it is in development. it's not unusual to see CMS projects with 6 or even 4 month dev cycles and just flourishing under it; but then their releases are full of tiny feature improvements with a relatively small set of big features. the linux kernel manages largely by how they manage alternate trees and patches; it's realistic to note that the combination of svn and having dozens of rather discrete (though often interdependant) projects does hobble us to some extent here. gnome releases these days are just one anemic set of changes after another. maybe they are spending too much time reimplementing the ui from scratch on every portable device, or maybe they are spending too much time on middleware like HAL or whatever ... i've also noticed that features and apps that start out in dev often don't fit within the first couple 6 month cycles and so end up getting included 3-4 cycles in; iow new application and large feature set performance is likely no better than with a 9 month cycle. and if you look at the 2 months following the first 6 month release cycle they had, commit list traffic and svn commits both fell dramatically and never recovered. i've read papers showing that for some projects short cycles are a real hindrance, and other papers showing how they are a boon for other projects. i guess that's a key point here: knowing what works for us and trying to understand why what does and doesn't work for other projects (so we can learn from them). i understand you are looking at this from the POV of downstream distribution. that's a good thing, too. it's a bit like trying to get your new toy out in time for christmas. but the other major concern is that our development cycles fit our developers; delivering a lesser product but more often isn't a great thing. perhaps there's a way to do both, though, with some strategy we haven't considered yet. i don't know, but its something i know i'll be thinking about. if we do go for a june/july release of 4.1 perhaps we can also use that as a learning experience to see just how well it does work (though understanding that we do have a unusual load of 90% done stuf =). that's a process i'd be very comfortable with personally as it would give us some new experience, and if we're careful to be aware of the process as we go through i'm sure we'll learn a *lot* of useful things =) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Trolltech pgpg89d3dkjFw.pgp Description: PGP signature ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
Aaron J. Seigo wrote: > On Monday 07 January 2008, Mauricio Piacentini wrote: >> Now that the big baby is out, we can attempt to pack >> less changes into each release, but make them more frequent. If >> something is not ready by 4.1, then 4.2 is not that far away. Rinse, >> repeat. A 9 month interval for inclusion of new features and >> applications in the main release seems too long, at least for me. > > it's actually a 7 month interval, not 9. it worked well in the 3.x and 2.x > days. it's also useful to remember than not everyone starts developing on the > first day. our contributors, for work or personal reasons, often start and > stop throughout the devel cycle. if the calendar-time window is too small > we'll miss fitting some (many, even) of the man-hour sets needed to complete > a given set of features. For each new feature there is an optimum development schedule length, be it 9 months, 6 or 3.14159 months, but it is always different for each feature. A fixed schedule like 6 or 9 months is always going to small (not enough time for big features), or too long (completed small features waiting around in SVN for ages before release). So I think the goal should be to minimise the time penalty of a feature not fitting the schedule. This pushes me towards shorter schedules. As for whether this means less feature development, I would say no, it doesn't make a real difference. There are still only 24 hours in a day for hacking, 12 months a year, regardless of how you divide that up. For most developers who developer when they can find the spare time, planning a calendar based schedule for a feature isn't really practical. Real life tends to intervene. Of course a shorter schedule incurs more release process overhead. I see the KDE releases more as "a bus to be caught", and less as a schedule for my development. YMMV. I think that with a project the size of KDE which contains so many smaller (relatively speaking) sub-projects, the SVN trunk should be kept in a fairly stable state almost all the time. The development window in the schedule should be used for landing and integrating large features that have been developed and stablised on their own feature branch. just my take on it. cheers, -- Simon Edwards | KDE-NL, Guidance tools, Guarddog Firewall [EMAIL PROTECTED] | http://www.simonzone.com/software/ Nijmegen, The Netherlands | "ZooTV? You made the right choice." ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
