[bt-devel] Development after 1.7

[Eeli Kaikkonen]

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   
>> version.

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  
manner.

>> 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.  
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

>>
>> 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.
>>

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,
>>
>> 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 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.
>
> Gary
>

--Eeli Kaikkonen