Hi,

Alex Valavanis <valavanisalex@...400...> a écrit :

There are currently only six backport proposals remaining [2]. Are there any other known issues preventing us from pushing the release? [2] https://bugs.launchpad.net/inkscape/+bugs?field.tag=backport-proposed

#950781 There is no disk in drive error when opening Inkscape in Windows 7 #513083 no disk exception when opening SVG file on XP/AMD64 #1163241 inkscape crashed with SIGSEGV in Inkscape::Preferences::_getNode()

Fixed very recently in the trunk. I'm very confident they can be backported with no risk (note that #950781 and #513083 are fixed by the same patch).

#1022543 Ctrl+C increments the documents count

IIRC the patch can't be applied without some changes. I'll try to take a look.

#805238 Crash when setting empty font family

The patch introduced a regression in the branch and had to be reverted. I've removed it from the backport-proposed list, but don't hesitate to add the tag again if you can work on a new patch.

#1232474 FreeBSD, clang, libc++, inkscape 0.48.x rev9969: calling a private constructor of class (iterator)

Marked "incomplete". Markus?

Regards. -- Nicolas

On Tue, 2014-01-14 at 12:15 +0000, Alex Valavanis wrote:

has a five-year desktop support term from Canonical, so any bugs in their Inkscape package will potentially haunt us for a very long time!

A sensible FreeDesktop deployment is for app upstreams like us to be removed from the archive and for them to support upstream publishing. But that's an ongoing issue for all upstreams.

For now though; we could ask Ubuntu to support Inkscape's eventual update to the next version much like Firefox updates to next versions within a cycle. Or ask for a trunk version to go in until we get the next version ready for stable. Thoughts?

Should we not have a fixed support time period where we can say to downstreams: Inkscape 0.48.x will be supported until 2015 or some such? We shouldn't have to burn resources supporting very-old deployments just because a distro is still shipping it. Although maybe I'm in the minority, what does everyone else think?

Martin,

On Tue, Jan 14, 2014 at 04:03:04PM +0000, Alex Valavanis wrote:

On 14 January 2014 12:55, Martin Owens <doctormo@...400...> wrote:

...

For now though; we could ask Ubuntu to support Inkscape's eventual update to the next version much like Firefox updates to next versions within a cycle. Or ask for a trunk version to go in until we get the next version ready for stable. Thoughts?

I'm not convinced that they'd support stable-release updates for non-core packages. They're normally pretty good about bug-fix backports though.

I'd like to get 0.91 out in time for the Ubuntu LTS release, although admittedly it may be tight to get it done by Feb. We should be able to get it in via the backports repository though.

In spite of that, I do think a 0.48.5 release is a good idea.

Since 0.48.5 would be a stable (bugfix-only) update, it would be acceptable for inclusion in Ubuntu past feature freeze, so it could go in as late as March. If it includes features as well as bugfixes, it can still go in, but we'd need a Feature Freeze Exception (FFE).

Post-release, individual fixes can be uploaded via the Stable Release Update (SRU) process, but you need paperwork and testing for each individual fix, so it's quite a bit of work.

Packages like Firefox have been granted Micro Release Exceptions (MREs). We could apply for an MRE for Inkscape, and I bet we'd stand a fair chance of getting it, however I'm not sure our rate of point releases would make that worthwhile.

The backports process probably makes the most sense for us to do post-release updates. The backports repository is now enabled by default for all users, and backports aren't limited to bugfix only. In my experience the process is also faster and requires less paperwork.

...

Should we not have a fixed support time period where we can say to downstreams: Inkscape 0.48.x will be supported until 2015 or some such?

Potentially, although I think that pre-planned support deadlines need to be accompanied by time-based releases!

Since our support is 100% community provided at this point, I'd just leave it organic. I.e. we'll continue supporting 0.48.x until volunteers stop being interested in supporting it.

...

We shouldn't have to burn resources supporting very-old deployments just because a distro is still shipping it. Although maybe I'm in the minority, what does everyone else think?

Agreed in principle, although in this instance we already have a bugfix release virtually ready to roll so we're not really having to do much! Given that Ubuntu LTS is such a large user-base for us, my thoughts are that we'll have less hassle supporting a 0.48.5 downstream package than we will with 0.48.4. Naturally, I'd prefer to see a 0.91 package downstream, but it won't be ready in time for the next Ubuntu LTS.

Bryce