[bt-devel] Development after 1.7

Martin Gruner mg.pub at gmx.net
Mon Feb 9 11:35:51 MST 2009


Hi BibleTime team.


Now it is time to think about how we should continue to work together in this 
project. Let me share my - personal - thoughts, and let us then discuss.


First of all, we need to CHANGE our development policy radically. Two years to 
create a new version of a software is by far too much!
RELEASE OFTEN must be our guiding principle. With a quick release cycle it is 
also easier to iron out mistakes that should have crept into a release.
IMO we should have a release per one or two months, ideally, more often is 
possible if there are many contributions. That means that each release does 
not have a "brand new" version of BibleTime, but some new features and some 
bugfixes. The rest of my thoughts flow from this principle, and I'd like to hear 
if you can accept this new approach. It is the most important point for me.

Planning should take place in 
http://devel.bibletime.info/wiki/Development_Plan. We create a feature and bug 
stack, and decide which items will be tackled for the next release. Others 
will be postponed to the next or a later version.

Our source code repository (SVN TRUNK) should *ALWAYS* be in a near-
releaseable state. That means that everything checked in has to compile and 
not break the application to be unusable.
Larger changes can be done in a development branch (for cooperation) or a 
local checkout of a developer and have to be merged back to TRUNK if they are 
ready to be tested. That is the responsibility of the developer(s) working on 
these changes.

This is (the attempt to realize) the approach of "agile software development". 
See http://www.pragprog.com/titles/pad/practices-of-an-agile-developer if you 
want to know more about it.


Now I'd like to hear what you think about these more general ideas. Is that ok 
for us to work from?


Regarding the current situation:

I'm open to switch to QtWebKit if the implementation is ready. But I'd favor 
to change the default, have people test and then quickly remove the old KHTML 
based implementation. I just enabled WebKit but couldn't tell the difference. 
;) I guess that is a good sign! If the replacement works as expected, we  have 
no reason to compile and link against KHTML any more. Btw, does it also do the 
print rendering yet?
It would probably be good if you, Gary, could continue the KDE->QT port for 
the different remaining parts of the application after the HTML rendering 
transition. But please in an atomic way that leaves a working application most 
of the time, as you did very well in the past. That way we can always release, 
no matter how far you got.

Eeli, similar thoughts would apply to you. You should (I guess that is your 
priority now) develop the Qt based FTP transport locally or in a branch, and 
then submit it to TRUNK as a thread-safe replacement of the existing 
transport.


All the changes we make bring us further away from the initial 1.7 release 
state. In case of important bugfixes we will have to decide if we should rather 
releae TRUNK as 1.7.1, which would be ideal, or if we want to branch the 1.7 
state (it has a tag, as all releases) and implement the bugfix in BOTH the 
branch and TRUNK. Then we could release the branch as 1.7.1 and continue to 
work in a not-yet-releaseable TRUNK.


What do you think?

Best regards,

mg



More information about the bt-devel mailing list