[bt-devel] Development after 1.7

[Gary Holmlund]

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!
> 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
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel
>   


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 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
  2. bug report dialog
  3. actions,menus, toolbars, etc.  (the biggest job)

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.

Gary