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

[Friedrich W. H. Kossebau]

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?

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. :(

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

Cheers
Friedrich