From kde-release-team Thu Dec 13 17:25:16 2007 From: "Aaron J. Seigo" Date: Thu, 13 Dec 2007 17:25:16 +0000 To: kde-release-team Subject: Re: Discussion about 4.1 timeframe (was Re: What to do about Kompare?) Message-Id: <200712131025.16492.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-release-team&m=119756675917316 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0216318123==" --===============0216318123== Content-Type: multipart/signed; boundary="nextPart14264431.1V5rIZfaoR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart14264431.1V5rIZfaoR Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 13 December 2007, Mauricio Piacentini wrote: > > > I'm not. :P You get basically two months to develop and add new > > > features and that's quite crazy. If we do this, you once again leave > > > out KDevelop and kdewebdev from the release because i don't think > > > those are going to be ready in 3-4 months. You also leave out a > > > significantly better version of Kopete since all the new stuff we > > > want to do for that (which is currently planned for 4.1) won't get > > > done either. > > > >I'm with Matt here, the same applies to kompare as I doubt everything > >thats needed can be done in just two months (also looking at the fact > >that I won't have much time for hacking myself until may). > > Well, I think that *AFTER* 4.0 it is wrong to continue doing > feature-based releases, and we could experiment a bit with > schedule-driven ones.=20 of course that's what we always used to do. 2.0 and 4.0 have been the only = two=20 exceptions i can think of since i've been around the project. > game, or a new Kopete feature, or KDevelop is not ready, then it sits > out, and waits for the next round. Simple, easy. People continue to use > the existing versions. No loss. Less pressure as well for the developer > imo. yep. > this example, to be concrete: if we release 4.1 only in August then I > doubt we will be able to keep momentum on the games and perhaps the edu > teams as well.=20 there's also the issue of Qt 4.4 to keep in mind. it will bring a number of= =20 significant strides forward that we will likely want to take quick advantag= e=20 of, and it comes out in Q1 (more towards the end of Q1 than the beginning). > The point is that some applications are ALREADY waiting for inclusion > since July/07! That is why I think a release in April makes sense, it 4 months after 4.0? that's 2.5 months of development time at best. seems=20 rather short. personally, i'd rather see a June date for 4.1; 4 months of devel, 2 months= to=20 stabalize, be able to take advantage of Qt 4.4 stuff. oh, and note that a April release would mean delaying BC for libplasma by=20 another release due to Qt 4.4 availability. > would have been 9 months after the last chance for inclusion. But it > could be in May as well: starting NOW, it would give us at least 3 > months for development of these new features. well, one might also suggest that right now is the time to actually be work= ing=20 on stabalizing / completing 4.0 =3D) the games have many possible improvements left as well; some of lskat's=20 animations are still dreadfully long; you can't tell which cards are the la= st=20 cards in that stack (which is pretty important for strategy in that game);= =20 icons in the status box are misshapen... etc... i'm sure this is the case with most parts of 4.0. so starting development f= or=20 4.1 now, while tempting, is perhaps not thte best idea? > If something can not be=20 > done in 3 months, it is doubtful that it would be ready in 4 or 5, at > least in the open source world, right? i haven't seen that to be the case, no. > 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=20 immediate and noticeable decline in both mailing list traffic and commit=20 rates when a 6 month cycle was adopted. i'd sooner see us (loosely) sync along with the Qt dev cycle (which has bec= ome=20 much more regular, ~9 month per release) to keep a steady flow of feature /= =20 bug fixes going between KDE and Qt. =2D-=20 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 --nextPart14264431.1V5rIZfaoR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHYWr81rcusafx20MRAhMVAJ0bh6GErVDVhZgx5BQgPa/KzKZWfwCghDzj DyF+sKfAy7n6bzD/CuiK5Dw= =X8ON -----END PGP SIGNATURE----- --nextPart14264431.1V5rIZfaoR-- --===============0216318123== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team --===============0216318123==--