From kde-release-team Wed Aug 05 21:10:04 2009 From: Maciej Mrozowski Date: Wed, 05 Aug 2009 21:10:04 +0000 To: kde-release-team Subject: Re: Possible 4.3.0 blocker in the Konsole KPart? Message-Id: <200908052310.04447.reavertm () wp ! pl> X-MARC-Message: https://marc.info/?l=kde-release-team&m=124950667623359 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0279901793==" --===============0279901793== Content-Type: multipart/signed; boundary="nextPart3025781.jxzKfcdXOn"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart3025781.jxzKfcdXOn Content-Type: Text/Plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable On Wednesday 05 of August 2009 08:17:03 John Tapsell wrote: > Agreed. I can't get the hang of svn backporting, and so I simply never do > it. I'm a bit scared hearing this.. Maybe because being packager I usually rely on developers to decide about t= he=20 way product is supposed to look like (not to mention it's far easier this=20 way...) - and if backporting was not popular among developers (fortunately= =20 it's usually not the case), then trunk would always feel "broken" (hey, it'= s=20 supposed to be that way :) - and stable branch would be=20 underdeveloped/abandoned/forgotten - this way users would never really get= =20 polished release. That being said I really think that migrating to better SCM is crucial and= =20 should be done as soon as possible. Aaron mentioned possibility of working in stable and then forward porting.= =20 While it may certainly bring more focus on bugfixes, it may cause features= =20 being introduced at smaller pace - it's up to you to decide what's most=20 appropriate at this point of KDE release timeframe. In any way - like Aaron noted, SVN doesn't help here (unless you forget abo= ut=20 branches and go back to continuous in-trunk development - but that would=20 expose patch releases to regressions so it's dead end). > Once we have git, I'd like to see this issue revisited. I would > prefer that KDE got a reputation of "releases when ready". Just start > skipping the release that we currently call ".0". That won't solve anything. x.y.0 releases are important - even just for the= ir=20 PR value - even if they're half-baked - it's just up to distributions to p= ick=20 the one that satisfies it best. Reputation of high quality can be achieved without skipping releases. It=20 "just" needs: =2D regarding developers - the will to write reliable, bullet-proof code an= d=20 backport it if needed =2D for developers - tools that help and don't disturb (currently lack of=20 thereof can be only compensated by even greater developers' will) =2D better distro<->developers cooperation, distributions provide free test= ers=20 after all (btw, how many of you use stable branch daily?) Are there current= ly=20 any serious problems with such cooperation? =2D-=20 regards MM --nextPart3025781.jxzKfcdXOn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEABECAAYFAkp59SwACgkQFuHa/bHpVdszRgCgo4aK+24Hy9WXqu8BP+Lk85ky AhAAni34MnZuvYdA+5yLOZ0t51brBLIb =LSN+ -----END PGP SIGNATURE----- --nextPart3025781.jxzKfcdXOn-- --===============0279901793== 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 --===============0279901793==--