[bt-devel] Your changes in CVS

[Eeli Kaikkonen]

On Tue, 17 Nov 2009, Jaak Ristioja wrote:
> I completely agree that we should branch before beta or RC. I'd prefer
> that we branch the RC and that branch will only get bug fixes and
> improved translations.

The normal convention is that the last RC will not be changed at all
before the final release. If there will be changes, a new RC is released
until there are no changes. We haven't followed this convention but
introduced even new features for an RC which actually would need another
beta testing phase, and fixed quite many things after RC which would
need another RC or even beta. My commit of Get Remote Source List
feature was such (though before RC, not after). One reason I committed
it too late was that I couldn't have committed it for a long time
otherwise. But anyways, RCs should be open for important bugfixes only.
Therefore bug-a-thons and other activities should happen before an RC,
not after. Otherwise our RCs are actually betas and should be labeled as
such.

On the other hand, I have wondered whether our release schedule is too
quick. Now the beta and RC releases aren't very useful if they are only
reminders for developers. It would be more useful to get them in to
"on-the-edge"  repositories and let eager users test them for a while.
Two weeks is too short a time for that. We should allow two weeks for
packaging/publishing and two weeks for testing. It's almost a month. But
now we have major relases about once a month which is too much.

I know this is against the "release early, release often" idea, but I
don't see a rapid release schedule very useful if it makes packagers
work all the time or users lagging behind when new release have come
out even when the older one isn't yet packaged.

This all may of course be my own imagination. Maybe we just understand
beta, rc and final labels differently. But we should come to a
conclusion so that we can orientate properly for each release.

  Yours,
	Eeli Kaikkonen (Mr.), Oulu, Finland
	e-mail: eekaikko at mailx.studentx.oulux.fix (with no x)