Change release schedule 4.2 and schedule for 4.3

[Aaron J. Seigo]

On Thursday 11 September 2008, David Jarvie wrote:
> For application development, the biggest obstacle to updating
> kdelibs/kdebase (whether by moving between branch and trunk, or simply
> updating the existing checkout) is not updating the SVN checkout (which if
> you have a broadband connection is easy), but rebuilding and reinstalling
> once the code has been checked out.

this is where having an SCM that can pull changes between branches without 
touching *every file* is pretty important. with an decent SCM when one switches 
branches it should only rebuild what's actually different between the branches.

obviously this is more than "no changes" but it should be less than what it 
would be right now with our current SCM solution.

> If the application needs new features in kdelibs, then updating is
> obviously necessary. But if it doesn't need new kdelibs features,
> rebuilding is a risky and often time consuming process which brings no
> real benefit to developing the application.

... aside from identifying bugs in the libraries it depends on before those 
bugs are passed on to your users.

> If I'm doing application work,
> I'd rather spend time dealing with build or dependency problems, bugs or
> functional changes in kdelibs/kdebase only when really necessary rather
> than every week or two. A constant non-updating environment to work in is
> the most productive, regardless of whether it's trunk or 4.x branch.

right, so what i suggested is that we put app developers who want/need this 
onto the most-stable-but-still-development branch at all times: stay on 4.x 
branch until trunk is declared feature frozen, then when trunk is branched for 
the 4.(x+1) move to that.

this is a way for app developers to help out by testing without causing more 
grief than necessary for them, as they won't be following a hot branch at any 
point.

> So I'm sceptical as to whether changes to the development model or VCS
> will make a lot of difference to the numbers of people testing the latest
> and greatest in kdelibs or kdebase.

well, the first goal is to not to decrease the number of testers.

the second goal is to increase them, and as noted above the suggestion is not 
"latest and greatest" but "current release until we feature freeze and then 
move to what will be the next release".

this is nearly identical to how qt-copy works now (only with not huge lags 
between bug fixes and having those fixes land in the repository)

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080911/4421be6f/attachment.sig>