[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