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

[Boudewijn Rempt]

On Thu, 27 Aug 2015, Friedrich W. H. Kossebau wrote:

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

Well, sure. But postponing it until we get some sort of consensus might not
work either, because it's awfully quiet. What sort of future development plan
is there for words, sheets, stage, plan, kexi? Yue has said he wanted to redo
flow based on Karbon, which is always an option, of course, but that needs
activity. Well, everything needs activity to happen.

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

That's something I wanted to start investigating next week.

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

That would be great.

> * Aug 29th/tagging of 2.9.7: last merge of 2.9 into master

I can do that.

> * after that:
>  2.9 only bugfixes, no more features
>  master unfrozen, so open for features and porting from kdelibs4support

I also would like to cleanup the coding style, still...

> 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
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel