2.4 Release Plan

[Tomas Mecir]

As a disclaimer, I'm not active in Calligra development currently, so
my opinion may not be entirely relevant, but hopefully it will be
useful anyway.

Wouldn't it be better to (at least for the initial release) use a
different development scheme with an alpha/beta version being released
every month or so, with no feature freeze in place? It could be more
work to manage it, but by maintaining a relatively constant stream of
pre-releases that each contains actual improvements (not only bug
fixes), you'd keep the general awareness of the project, while at the
same time having enough time to polish the applications to be end-user
ready for the first final version (2.4 or 3.0 or however you're going
to call it).

/ Tomas

2011/1/13 Inge Wallin <inge at lysator.liu.se>:
> On Thursday, January 13, 2011 10:57:10 Cyrille Berger Skott wrote:
>> On Thursday 13 January 2011, Inge Wallin wrote:
>> > Now, if we instead prolong the initial release phase to, say, 7 months
>> > and by  doing that make sure that the release is in fact good enough
>> > then the user gets a usable Calligra in 7 months.
>>
>> Really, you think one extra month will be enough ? If that is the case,
>> then I agree. But I am very skeptical. But ok since we are aiming at a
>> release around May - June. I suggest people to fill the feature plan [1],
>> with the mention "URRF - 3 weeks" (User Readiness Required Feature) if you
>> think that is a feature that needs to be finished for the application to
>> be user ready, and that you would need 3 weeks to complete it, and by 3
>> weeks I mean real time, meaning that if it is a feature that require 30h
>> of work, and you can work 10h per week-end on calligra, it translates to 3
>> weeks.
>
> I have no idea what will be required.  As I wrote, I think we should go the
> other way around and ask the maintainers.  And when you write "we aim at a
> release around May - June", I have to question it.  "We" in this case is you.
>
> Of course, I don't question that a quick release is better than a slow one.
> But I think it has to be given a lower priority than getting a usable suite.
> So that should be our starting point rather than the calendar time.
>
> Some may read this that I want a perfect suite at the release.  That's not the
> case, I know very well that perfect is the enemy of good. So if we can find
> the lowest common denominator that would make each application good enough,
> then I'm all for it.  Note though, that I think usability issues are just as
> important as missing actual features here.
>
> Your approach sketched out above seems a good one.  Can we enhance it with
> using the same keyword for bugs in bugs.kde.org?
>
>> So fill [1] as soon as possible, I would set the deadline for February, 2nd
>> (which would be equivalent to a soft-freeze, meaning that afterwards
>> development, in master, should be focused on the content of the features
>> plan).
>>
>> And then we can see if we need 3, 4, or 8 month of features development.
>
> Yep.
>
>> [1] http://community.kde.org/Calligra/Schedules/2.4/Feature_Plan
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>