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

[Jaroslaw Staniek]

On 24 November 2014 at 10:02, Friedrich W. H. Kossebau <kossebau at kde.org> wrote:
> Am Montag, 24. November 2014, 00:50:18 schrieb Jaroslaw Staniek:
>> How about keeping the "master always stable" motto and porting in a branch?
>> Cherry picking the results once they are stable?
>
> "Master always stable" is a good point, and I subscribe to that.
>
> But: I would argue that with the port to a new platform (which I consider
> qt5/kf5) there is an exception. Because "master" rules. Any new stuff usually
> has to make sure it does not break stuff in "master", not the other way
> around. But the port is not just a new feature, which simply has to be
> improved until it is regression free. The port is the new "master". And all
> other code has to make sure it integrates with that.
>
> Any commits to master while the port is going on will only complicate things,
> because they have to be integrated into the ported code as well, which will be
> more work due to all the changed code lines in the port.
>
> So to get the port done as quickly and clean as possible, I would vote for a
> complete freeze of master, until the port is done (which would be roughly a
> month I hope). And if master is frozen anyway, the port could also be directly
> done there.

I see what you mean. There's a small misunderstanding: I propose to
work in a qt5-port branches, and squash-rebase commits into reasonable
chunks, then cherry pick only working patchsets.
Initially it will be a large number of cherry picks (or a merge if
history is clean enough) - I called it "cherry picking the results
once they are stable" in my previous post.
Then, after large changes, cherry-picks would become more individual,
often per-app or lib.

During this time, master is frozen, that means it reflects the state
before branching off 2.9.
In fact during this time master would be outdated compared to
calligra/2.9 but enyone can ignore any announcements, grab it and
build, as usual.

I'd like to avoid "more work", "even more work" type of commit logs
landing directly in master.


-- 
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