KDevelop 3.1 - Release or postpone?

[Alexander Dymo]

Ok, let's look at the problem from the other side.

> The OSS credo of "it's done when it's done" is something I doubt anyone
> would
> apply to KDevelop-3.1 at this point. Not to trivialize the release process
> and the troubles/efforts that goes with it, but the KDE release is as far
> as
> I can tell the _only_ reason we have to go into feature freeze right now.
> Is this a good enough reason? What's the alternative?

Releasing with KDE has several advantages:
- KDE takes care about PR
- KDE takes care about preparing the release
- KDevelop is translated among with other parts of KDE (translators have
time)


> The large recently contributed TrollProject patch made me think about
> this.
> It's apparently an important patch to what is arguably one of the most
> central parts of KDevelop. So much in fact that Amilcar is apparently
> trying
> to squeeze it past coolo right now. Assuming he's unsuccessful, do we
> leave
> it out for another 6-9 months? (Wild speculation on KDevelop-3.2
> timeframe.)

Yes, that's a large improvement but it is not tested yet so I doubt we
should rush it into 3.1.

> What about the other unfinished / semi-unfinished / unpolished stuff?

We can live with that and improve situation each next release. Delaying
3.1 (this gives us another month or two) doesn't mean we will finish all
features and polish all stuff.

> # Embedded KDevDesigner is experimental but has ended up as the default
> handler for .ui files and there is no currently mechanism to configure
> KDevelop otherwise. It also has no way of showing the new splash screen
> (no,
> not important, but the similar images does help to create the feeling of a
> unified development platform - appearance is important. :) )
Splash can be done even now.
Experimental integrated kdevdesigner in any case is better than previous
subclassing approach. I think I solved most grave issues (crashes, etc.).
A setting to turn off integration would be good to have but one still is
able to open external designer and (optionally) use subclassing. We can
still force that setting in 3.1 (I agree to break message freeze for that
case, hope Amilcar too).

> # KNewStuff integration hasn't happened, but it was a large part of why
> the
> appwizard rewrite was done. The appwizard still feels a little flakey, and
> sure is slow.

Is that really important? I doubt.

> I'm pretty sure we could make most of the above happen if we put another
> month
> of development (including akademy) into KDevelop-3.1, but this of course
> depends on if you all think this is a good idea and actually have time to
> turn up and do the work.. ;)

Jens, let's be realistic. We can't put everything in 3.1 release. This can
lead to infinite delay.

> I'm not saying it's not without merit to release a KDevelop-3.1 with
> KDE-3.3,
> but I think it would make sense to release it two months later if it was
> significantly better. Either way we should make a conscious decision to
> release or not release, not just let it "happen" regardless of the state
> of
> the application.

Again, I doubt we can make KDevelop significally better in two months.
If we add two months of development now we will
- loose two months (June and July) we spent in preparing beta and freeze
- loose another month or two in our own (new) freeze

The schedule could look like:
August, September - development
October, November - freeze and translation time


Now it's time to state my reasons (listed in order of importance)
Why I'm against delaying 3.1 release:
1) Our own Berkeley Db copy makes KDevelop stable on all modern
distributions and enables users to use code completion. Linux distributors
usually ship next versions in auttumn and they will surely pick KDE 3.3.
We will loose a lot of users (due to code completion crashes) if we don't
release 3.1 in time (mid August). October/November is too late. That's the
most important reason to release in August.

2) 3.1 fixed many grave crashes (including the problem with documentation
plugin).

3) 3.1 has several new plugins so we can't say we failed to do smth useful
in 3.1. I know I'm biased, but new documentation plugin is a significant
improvement ;) UI enhancements are no less significant. KDevDesigner
integration (even in it's current state) is our strength too.

4) Releasing with KDE has certain advantages (listed above)

5) We risk to loose time and slow down development. There are no
guarantees we can improve KDevelop that much during two extra months.

6) New functionality is great, but it comes continuosly. We can't delay
release infinitely.

7) We should stick to our schedules. Delays (even in OSS world) aren't
accepted well by users. We'd better to concentrate on the next release
during aKademy. The goal of 3.1 release is to solve issues listed in
points 1, 2 and 3. That's a reasonable milestone and the faster we pass it
- imho the better for us. We can schedule quick 3.2 release, for example -
with new trollproject and plugin profiles and concentrate on it during
aKademy.

So, my suggestions:
1) Release KDevelop 3.1 on August 18 (with KDE 3.3)
2) Opt for a quick 3.2 release with following schedule:
October 31 - beta 1
November 15 - beta 2, freeze, translations
December 1 - 3.2 release

Those are the same four months of development (as in the case of 3.1
delay) but with reasonable milestone passed (3.1 bugfix and proof of
concept released in August).

PS: the above schedule can be shifted to one months in both sides.

-- 
Alexander Dymo
ICST department, National University of Shipbuilding, Mykolayiv, Ukraine