[bt-devel] Development after 1.7
eekaikko at mail.student.oulu.fi
Wed Feb 11 09:19:51 MST 2009
Quoting Gary Holmlund <gary.holmlund at gmail.com>:
> Martin Gruner wrote:
>> 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!
I can't disagree with that :)
>> 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.
It's a good principle. It would be very nice if we could give
something new in the UI with each release, whether it be a better
layout or a perceivable speed improvement.
>> 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
We have used this already with success, but lately it wasn't updated
often. It's a good tool, we just need to use it in some predescribed
>> 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.
Sounds good enough. We just have to learn how to use svn more
efficiently. I have not abandoned the idea of distributed version
control, but the time is not yet right for changing that. If we get
more developers this may be topical within one or two years.
Meanwhile, read e.g.
>> This is (the attempt to realize) the approach of "agile software
>> development". See
>> if you want to know more about it.
Agile development is a hot topic in industry. It may be very useful.
>> 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.
Removing KHTML is ok for me.
As for my own part - I have thought about the instmgr. Concurrent
install has some usability problems with the current UI. If there are
installs from several sources it's very natural to do them
concurrently, but that means leaving some of them out of sight in the
dialog because the exact order can't be predicted (because the
download time can't be predicted). I believe the current engine
implementation works reliably even though it could be technically
better. It would be more useful to change some things in the sword
engine than to do complicated things in our code. But I don't want to
do that, at least atm.
Would it be better to wait for feedback from users and get back to it
later? Concurrent install would be great for hardcore users but I
don't see it as a core feature. We have gained a huge usability
improvement from threads in form of non-blocking gui and I'm quite
satisfied with the situation.
Instead, I could use my time for KDE->Qt port. I think we all want
eagerly have something for Windows/Mac as soon as possible.
>> 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.
I'm for minor bugfix releases in case the changes have to be fast. I
don't care so much about the technical implementation, as long as it
doesn't dictate and hinder the development. BTW, I would like to use
1.7.1/2... for feature versions and if there are plain bugfix releases
they could be 1.7.1.x. But it's a matter of taste, I think.
>> What do you think?
>> Best regards,
>> bt-devel mailing list
>> bt-devel at crosswire.org
> I welcome a release often policy and that the code should be in a
> near-releasable state at all times. This is our policy where I work. At
> the same time I can appreciated that this would not work well for the
> past port from kde3 to kde4/qt.
I agree - it wouldn't have worked well in the porting phase. We are in
a better situation now.
> I was expecting to remove the KHTML when we feel ready. I have the
> CPrinter changes ready to check in.
> The remaining kde4 code relates to:
> 1. command line options
I think this is related to kapp <-> qapp. And IIRC we can't give kapp
away before other parts have been ported.
> 2. bug report dialog
I would prefer a Help menu "Online" with submenus "Report bugs (opens
a browser)" etc. They would just open a page in a system browser, in
this case the sourceforge bugs page.
> 3. actions,menus, toolbars, etc. (the biggest job)
...And there are some items in
http://devel.bibletime.info/wiki/BibleTime1Refactoring (which is an
orphaned page, BTW, after the Main Page edit - it should be fixed).
Let's use and edit that.
> We can make the decision about branching for a 1.7 bug fix versus using
> the trunk when the time comes. I would hope the trunk is stable enough
> we could just release from it.
More information about the bt-devel