On Mon, Jul 25, 2016 at 01:35:24PM +0100, Alex Valavanis wrote:

Hi Krzysztof,

This is beautiful music to my ears. A hard switch to Gtk+ 3 and C++11 will be a real step forward for us.

To confirm, now that the branch has been made, are we good to push ahead immediately with the migrations in trunk? If so, I'm happy to take care of killing Gtk+ 2 support.

If not, when shall we do this?

Right, at last month's meeting we discussed this. Splitting out the branch allows us to get this severe blocker resolved, so the release can move forward. We've got a handful of bugs remaining but only two high priority ones and both of those have plans sketched in for getting them done.

We're figuring with as many breaking changes as we've queued up pending the 0.92 release, that we should probably allow the 0.93 development cycle to just be a heavy development cycle. Likely, the earlier this can start, the sooner 0.93 can be done.

I would love to see more developer attention on the remaining blocking bugs, but at this stage keeping work from progressing on trunk probably doesn't buy us much. If anyone has a dissenting view here, I'd love to hear.

As I see it, the advantages of avoiding intensive work on trunk would be, first, avoiding developer distraction, and second, making fixes easier to backport. As to the first point, frankly I think opening trunk may actually end up stimulating more developer involvement and thus potentially more bug fixes; as to the second, work done for Gtk3 is unlikely to be backportable anyway, and besides we're a bit far into the release for the cost-benefit of backporting to pay off more than dribs and drabs anyway. The C++11 conversion would be the main thing that could inhibit fix backports, so might be worth prioritizing the Gtk3 switch; but in my experience syntax translations tend to be pretty easily reversable, so probably isn't worth much worry.

All this said, it would be really wise to invest a portion of your available time into looking at bugs for the 0.92 branch. With all the potential breakages happening for 0.93, our users may be needing to fall back to 0.92 as a solid stable release, even after 0.93 is out the door. So time invested in 0.92 bugs right now could pay off for everyone for quite some time to come.

https://bugs.launchpad.net/inkscape/+bugs?field.tag=blocker

The other thing I would ask is that you put out an announcement of intent for removing Gtk2 in trunk before doing so, to minimize surprise for folks about potential disruption. Directions for checking out the 0.92 release branch might be helpful there too.

Bryce

AV

On 25 July 2016 at 06:47, Krzysztof Kosiński <tweenk.pl@...400...> wrote:

...

Hello everyone,

I made a branch for the 0.92 release under lp:inkscape/0.92.x. Currently the only change in this branch is the reversion of the SPCanvas widget changes that were causing performance regressions on some platforms.

After 0.92, the following large changes are expected:

• C++11 mode will be enabled. C++98 compilers will no longer be supported.
• Autotools and btool build systems will be removed in favor of CMake.
• Inkscape will be based on GTK3. GTK2 support will be removed.
• At some point, code will be migrated to GitHub, to take advantage of

automatic continuous integration with TravisCI. The bug tracker and answer tracker is expected to remain on Launchpad for the foreseeable future.

Best regards, Krzysztof

---

What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel