On 23 November 2014 at 22:14, Friedrich W. H. Kossebau <kosse...@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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
