[bt-devel] [Pkg-crosswire-devel] Packaging Project Planning

[Eeli Kaikkonen]

On Wed, 20 May 2009, Dmitrijs Ledkovs wrote:

> >>Bibletime?
> >
> > Is very close to 2.0 rc1, so by the time our SWORD 1.6.0 packaging is done
> > we may have a BT 2.0.  I'm not sure we should put 2.0beta2 into Debian
> > unstable, although we could if necessary/appropriate.
> >
>
> I'm a little bit uneasy about betas in unstable. They do automaticly
> migrate to testing.... ~70% of Debian users run testing....
>

I'm of course partial, but I want to get the latest BT there as soon as
possible. First, BT has had stable releases for a while. But even when
we haven't released it with critical bugs, people have found new ones
after releasing. Therefore I suspect it will never be in perfect state
(and it doesn't differ from any other software in that). There
will remain smaller known bugs even in the 2.0 final.

Second, every software needs testers. If BT is not in repositories, it
won't be tested so much. But we still need to release new releases - we
can't just wait infinitely. If you release the beta packages to the
larger public, they will be tested and the 2.0 final will possibly be
better. But if you won't, the 2.0 final will be released by the
development team anyways but the real quality may be like another beta.
I have personally been very strict about the versioning. Actually our
alphas have been more stable than betas in many other projects. There
are many beta packages in Debian repos anyways. It depends on the
particular project whether it's reasonable to package alphas/betas. I
really recommend putting BT in. The 2.0 final will follow soon anyways,
so nobody will be hurt even if a beta or RC will stay in the repos for
couple of days or weeks. I hoped to have the RC there for some time
before releasing the final, just to find possible crashes or other very
critical bugs. But how much time you actually need to get the packages
to unstable? I already asked Jonathan about that, but I thought we were
talking about unstable, not about experimental or even "private" repos.

Lest you get a wrong picture, I want to emphasize that BibleTime has
been in a good shape for a while and we are conservative in versioning.
My statements above which may sound negative against the quality of
BibleTime are due to my general high quality standards and don't mean
that BibleTime 2.0 final would be worse than any other application - on
the contrary.

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