Schedule to switch back to master for feature development (was: Re: After 2.9.7)

[Jaroslaw Staniek]

On 27 August 2015 at 16:27, Friedrich W. H. Kossebau <kossebau at kde.org> wrote:
> Am Donnerstag, 27. August 2015, 09:57:32 schrieb Boudewijn Rempt:
>> I'm not really happy writing this mail... But anyway, back to practical
>> issues. I'd like to start taking steps next week already.
>>
>> * split up our git repo whichever we we like
>> * ask sysadmin to put our repos up
>> * update all the build documentation on community.kde.org to talk
>> about kf5 and the new repo locations
>> * update the information on our websites (not forgetting kde.org)
>> * ping David Revoy about updating his build guide
>> * figure out the release process after the split?
>>
>> And then start hacking... Thoughts? Flames?
>
> I fear splitting git repos, unless done brutally, will take some time to be
> well prepared (and also needs an agreement who to do it of all involved). So
> hoping to do that already next week might be ambitious :)
>
> Unless you are talking here about the option of forking off Krita + shared
> libs into a repo of its own, then of course just that Krita subcommunity needs
> to agree.
> Still, not sure how wild the repo history is and how complicated it will be to
> find the correct filter-branch rules, I assume that needs more than a few
> hours, including all the test builds.
> Jarosław, what amount of work do you assume here based on your experience with
> forking out kdb, kreport and kproperty?

I cut off-things one by one. I was acting like a surgeon there :)
By the way I even cleaned up my commit names/emails :)
Final cleanup can be done once commits land in given destination repo,
especially because filters are slow on entire calligra.git.

One note is that renames are the biggest challenge. I personally
wanted entire history for kdb.git; existence of the
kexidb->calligradb->predicate->kdb history means that we had like 5
location of files.

> So we need some volunteers who dig into the needed filter-branch rules (guess
> for Krita Boud is already on that). Myself has no experience and is not really
> motivated yet for it. :(

I can help with that. Good that Kexi was in kexi/ all the time. Same for krita/.
Ping me.

> In the meantime for everyone I would propose to turn Boud's other proposal
> about turning frameworks into master and open it back for development in this
> schedule:
>
> * before Aug 29th/tagging of 2.9.7: merge frameworks into master
>   (volunteers? I could do that, at least help,
>   including updates to kde-build-metadata and requesting CI adaption)
> * Aug 29th/tagging of 2.9.7: last merge of 2.9 into master
> * after that:
>   2.9 only bugfixes, no more features
>   master unfrozen, so open for features and porting from kdelibs4support
>
> Does that work for everyone?
>
> Now, I would also love to see Kexi's framework branch finally finally merged
> back into master.

Green light? I hope to do so before Monday noon.

>  Just, there is still the unsolved problem how to officially
> deal with the no longer by-repo-given atomicity of API changes in libs and
> libconsumers, given that kdb, kreport and kproperty are now external, but
> still developed in sync with their consumers.
> But separate email thread for that please (writing one next), orthogonal
> problem to this schedule IMHO.

Yes, we'd document best practices.

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