next release and release pace in general

[Jaime]

Hi,

  Probably this is not the right thread to talk about this, but..

  I wanted to install calligra for windows to some Spaniards that still use
windows. Before doing that, I tried the available installer (RC3) on
another windows.

  There is a big bug.... It is only available in English. Therefore I can
not install it to a lot of Spaniards that still want to use windows. I must
install them LibreOffice for windows.

  There are other small bugs that I'll report on bugzilla. For example, in
words the initial rendering is ugly like in the old times, until you apply
on the style font (without changing anything), and then the font rendering
is OK.

Best Regards.


2013/2/12 Boudewijn Rempt <boud at valdyas.org>

> On Sunday 10 February 2013 Feb, Cyrille Berger Skott 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.
>
> If we want to provide users with improvements, we need to have users in
> the first place. That's simply not the case, and in order to get more
> users, we have to be able to tell them what is available. The only moment
> we can do that is in with a release, because only releases get picked up by
> press and news sites.
>
>
> >
> > == 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.
>
> But those projects are not the competition. The competition is LibreOffice
> (just had their 4.0 release with lots of coverage and a very nice special
> website landing page for 4.0), MS Office, GIMP, MyPaint, Photoshop and so
> on. None of these projects are on continuous releases, and they all use
> their releases to generate publicity.
>
> >
> > == 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.
>
>
> This is the point where I disagree most with you: if want to get more
> users and more developers we have to get publicity. And basically, apart
> from bad stuff happening like forks, releases are the only hook news sites
> and press acknowledge for writing about an application.
>
> I think making a splash is actually the most important thing of a release.
> Just look at the amount of interest the 2.6 release has just generated for
> Krita.
>
>
> >
> > == 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.
> >
> > 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.
> >
>
> That is not reaching users: it's making software available. It's perfectly
> possible to make our software available regularly and still reach basically
> no-one.
>
>
> --
> Boudewijn Rempt
> http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20130212/34668ab2/attachment.htm>