[bt-devel] The next and upcoming releases

[Eeli Kaikkonen]

On Sun, 25 May 2008, Martin Gruner wrote:

> > Drag and Drop seems to be the last problematic area which I would like
> > to fix before the next release, the other things can wait.
>
> Good. Before beta1 or final?

The only important thing is now moving/copying the bookmarks. It's not a
core feature though and d'n'd has some problem there which I can't find.
Maybe it's easier to rewrite the bookmark item classes because they are
so messy.  If you think this is not an important feature it can wait.
(With next release I meant the next release :) whatever it is.)


> I think we should wait with larger refactoring items until after 1.7final.
> They may introduce bugs and break i18n as well. Let's try to push for 1.7 as
> fast as we reasonably can, to make room for further development thereafter.
>
> The only exception I'd like to make is if you say you can do the refactorings
> _now_ in a couple days, so that they can be in beta1, be tested and
> translated.

The reason I want the dialogs be ready before at least the final - or
the first packaged version - is that they affect the visible consistency
of the dialogs with the standard KDE buttons icons and because the
Bookshelf Manager paged dialog looks different from the Config dialog.
They are also quite straightforward to port though especially the config
dialog takes some time because of the KPagedDialog->BtConfigDialog
transition. Actually will I have some free time so I might be able to do
this in couple of days.

Another reason to get them ready before the final is this: the more
porting is left after the final the more bugs there will be then. Also
for UI strings it's better to change them before the final than after
it. This may be a matter of personal preference because the bugs will
come before or after.

>
> Ralph Jahnke asked if we get 1.7final done before Aug 28th, which means it
> could enter the next Ubuntu version. I guess that is realistic, isn't it?

Yes. That would fit well with my scheme, too.

> I think we should not label beta1 as "final". Packagers should create packages
> for people to test more easily, but we should work towards final for
> real "public" usage.

I think that alpha, beta, rc and final get their meaning from the state
of the application, not from the state of publicity. If we give a public
release in couple of weeks it will necessarily be beta because of the
reasons I wrote: it has not been widely tested, it still has some
lacking features, it has some inconsistencies (the beforementioned
dialogs). I would rather read comments like this: "For a beta quality
software this works very well" than this: "This looks more like a beta
than a final release". We give a message to people with the version
number and it should be honest and realistic and tell about our
commitment to quality. Therefore the next release, if released within
couple of days or weeks, should be beta. Still I think it is ready for
the public because it has all the important features and it should be
stable and usable for everyday work.

With a public packaged vs. source-only release we have a chicken-egg
problem: if this is not packaged it will not be widely used and tested,
and if it's not tested people will find bugs only after the public
release and it will be actually beta then. Quite many people would be
ready to use and test software if it would be easily installable, but
compilation is too much asked for many. Most of the large projects (KDE
for example) have beta and even alpha versions packaged, at least
unofficially. As a user I know that it is the best way to get more
testers.

Of course we could tell that even though we want the packagers start
working we don't want the packages in the official distro releases, but
we can host them or link to them for testers to download. Maybe that is
what we both want?


>
> > ====Future plans====
> > Removing the KDE dependencies has continued. Qt WebKit should have the
> > API we need in Qt 4.5 but the schedule is still unknown.
>
> This is post-1.7.

Yes, therefore it's "Future plans", though this sentence is a bit
strange here. I'll move/edit/remove it.

The reason for this section is the curiosity of people: we would like to
know about the future. Future plans draw attention and give a
feeling of continuity and dedication. It may also help packagers or
other parties make some decisions. And make us discuss about our future
plans :)

> 1.7 should only take a few weeks, hopefully.

As I said, I would rather release one or two betas now and the final
after couple of months.

I have already thought about having a roadmap in the wiki. It would have
section for each planned release where there would be list of bugs and
features. After we have come to some conclusion about the versions it
would have for example section "1.7xxx: bug #xxxxxx, bug
this-and-that-in-wiki, porting the config dialog..." and "1.7.yyy: bug
this-and-that, porting something else..."

Right now we have still to discuss about this and select some scheme. We
could of course write "Eeli's vision about the roadmap" and "Martin's
vision about the roadmap", if it helps seeing our opinions better.


> You should add that who wants to help does not have to have all the listed
> skills at once. =) One or two are already good to help with a particular
> item.

I'll work on that.


  Yours,
	Eeli Kaikkonen (Mr.), Oulu, Finland
	e-mail: eekaikko at mailx.studentx.oulux.fix (with no x)