next release and release pace in general

[Jaroslaw Staniek]

On 10 February 2013 11:45, Cyrille Berger Skott <cberger at cberger.net> wrote:
> Hi,
>
> Here is my opinion on release schedule. First, we have to go back and think
> about why we do release ? And more important, to whom we do release ? For me,
> it is obvious that we primarly release to bring improvements to our users,
> everything else is and should be a side effect.
>
> == Targeting users
>
> Then we have to know our users, and the following is based uniquely on my
> experience with talking with other people, technical, and non-technical, young
> or older, if someone had a study on the subject, I would be very interested to
> read it, but anyway, I would say there are two categories of users, those who
> don't want any changes at all in the software they use and those who like to
> see improvements. Personnaly, I think that when we release, we can safely
> ignore the first group of users, there is no law that say that a user have to
> upgrade, hence that group of users is well served by a fast or a slow release
> cycle.
>
> For the second group of users, it seems to me, that they appreciate
> improvements, weather features or bug fixing, and would strongly dislike
> disruptive changes (major UI overhaul and regressions). But to be honest, that
> would be true for any release schedule length. To be honest, based on that, I
> would even be suggesting monthly release, continuously bringing features and
> bug fixing, but that would be a QA nightmare.
>
> == The competition
>
> This assumptions about users appreciating continuous non-disruptive
> improvements, that have led Google to release Chrome every six weeks, Firefox
> is also now following that schedule. The Linux Kernel get a major release
> every four weeks. If you look at web site and web applications, they get
> continuous improvements that are silently rolled to users. This is the current
> trend in the industry, release early and release often.
>
> == Splash
>
> I don't think release should be used for making a "splash", I fail to see the
> benefit for our users, also, we would have to define what is a "splash", same
> with defining important features: what is an important feature for someone is
> completely unimportant for someone else, also, developers tend to vastly
> overestimate the time it will take to complete a feature, which is the problem
> with goal-oriented features, they keep dragging on, waiting for some features
> to be finished.
>
> So yes, our releases announcement looks like they don't contain so much. My
> suggestion would be that once a year we write (rather collect) a small leaflet
> with all the new features and improvements that have happen during the last
> year, pretty much like Krita's leaflet (http://krita.org/aboutkrita26.pdf).
> And then we send that to the press, along with a presskit, and I am rather
> convinced that it will be much more efficient at attracting attention than
> waiting for having sufficient features to do a release.
>
> == Reaching users
>
> Fedora and Ubuntu are on a six months schedule with freeze early March and
> early September. OpenSuse is on a 8 months schedule. However, rolling
> distributions are getting increasingly popular, with Gentoo and ArchLinux,
> Debian has started discussing it, Ubuntu is rumured to introduce it soon. Also
> most distributions offers backport of the latest software.

Cyrille,
I like many thoughts you have presented here.
What I'd like to see is release often, perhaps as often as web projects do.

So that means every day. How would they manage that? Before someone
disagrees, I'd like to note we've switched to a
git-style-of-development and there are feature branches. Integration
branch is possible too and is especially useful when any addition may
be interfering with other areas of Calligra.

I understand that we have many features and fixes shared between apps
but also a number of them that are application-specific. By sharing
all the releases among all the apps/libs, I believe every time we
limit ourselves by picking the largest common delay or something like
that. More apps, the bigger the delay may happen. And Calligra has
many apps.

Furthermore, as soon as we support (more) no-arch plugins, e.g.
JavaScript-based, we'll no longer be able to set release dates. User
will start escaping from the traditional deployment channel, which I
believe fits best to the  cathedral/waterfall approach, not our
situation when (by design) available resources (manpower for
development, testing, deployment) change on daily basis.

There are some possibilities how to make continuous releases possible
and I'd like to continue this discussion.
In particular, I mean replace message/doc freezes with alternative and
take full control of translation and documentation deployment.

Make it "Deployment 2.0".

> And that is only Linux, but the hard truth is that if Calligra become
> successful, most of its users will be Windows user, where we are not dependent
> on distributions release schedule.

Yeah, I am repeating myself here that Windows (and maybe Mac) are the
only deployments we can have under reasonable control.

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt Certified Specialist | http://qt-project.org
 http://www.linkedin.com/in/jstaniek