When to branch off 2.9 (was: Re: 2.8.7 and 2.9 release plan)

[Jaroslaw Staniek]

On 23 November 2014 at 22:14, Friedrich W. H. Kossebau <kossebau at kde.org> wrote:
> Am Donnerstag, 20. November 2014, 17:34:59 schrieb Cyrille Berger:

>> I have updated the wiki page with tentative schedules for 2.8.7 and 2.9:
>>
>> https://community.kde.org/Calligra/Schedules/2.9/Release_Plan
>> https://community.kde.org/Calligra/Schedules/2.8/Release_Plan
>
> Question: does it makes sense to branch off calligra/2.9 already for Beta 1?
>
> I propose to actually branch off 2.9 only on the actual release, perhaps even
> on the last patch release 2.9.x right before the start of the Qt5 port. And
> spent all time till the port on polishing 2.9.
>
> Reasoning:
>
> The very next thing after 2.9 to happen on master is the port to Qt5. Which is
> currently planned to happen like this:
> "
> In early January, we'll lock down the repo, send everyone on vacation while
> the porting scripts run. When every script has ran, and everything builds
> again, we'll start properly porting Calligra
> "
>         from https://dot.kde.org/2014/07/27/2014-calligra-sprint-deventer
>
> Adding new stuff to master that possibly is only half done in the time window
> between 2.9 branch and the port might only add trouble to the port, as it
> might not be clear if errors are due to the port or because the feature was
> broken before.
>
> There are a lot of new things in 2.9, which might need some more polishing
> anyway. Having master and 2.9 on the same branch prevents any backward/forward
> porting needs.
>
> Having master being 2.9 also means more dogfooding of 2.9 by the developers.
>
> Is anyone having/planning any feature branches/patches to merge after the
> release of 2.9 and before the porting of Qt5 happens?
>
> I am not sure that would makes much sense, instead everyone should be invited
> to spent those weeks on first polishing 2.9 some more and then getting the
> port to Qt5/KF5 done as quickly and well as possible. Thankfully Calligra is
> very modular, so multiple people can work in parallel, once the initial
> script-based porting has been done.
>
> (I have a patch drafted to support the port temporarily in the product system,
> where all unported products will be tagged by "UNPORTED" and thus properly
> disabled in the build, no need to uncomment lots of things in CMakeLists.txt
> files, e.g.
>         calligra_define_product(LIB_MSO "libmso"  UNPORTED REQUIRES LIB_CALLIGRA)
> upcoming in reviewboard in the next days to be available when needed)
>
> I see that for Krita there is at least one feature planned for 3.0, next to
> the port: "Parallel: work on the animation plugin"
>         from https://forum.kde.org/viewtopic.php?f=137&t=123658&hilit=2014+roadmap
> That would happen in a branch anyway, so no need for branching off 2.9 early.
>
> So, anyone opposing delaying the branching until the port will start?

Honestly, I think technical means wouldn't stop everyone from working
of features instead of porting. Global agreement to the plan would
make the trick. So I would be in favour of branching as usual. Unless
I misunderstood something.

Example to show things are not simply linear: My feature branch is
kind of splitted already, part of the code is in the predicate repo. A
few other smaller repos will follow. Developing/adopting predicate is
a part of the porting process. Basically calligradb won't be
Qt5-ported, instead, predicate will be ported to Qt5 and then Kexi
will be ported to it. That saves unnecessary Qt5-port of kexidb.

Details: https://community.kde.org/Kexi/Porting_to_Qt%26KF_5

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek