9:20 p.m.
Hello All,
It's great that we're moving forward with 0.91, but I still think
there's merit in pushing a quick bugfix release. There are a lot of
high-importance bugs fixed in the 0.48.x branch [1] including a number
of build-failures on current linux distros and OS X. There are
currently only six backport proposals remaining [2]. Are there any
other known issues preventing us from pushing the release?
AV
[1] https://launchpad.net/inkscape/+milestone/0.48.5
[2] https://bugs.launchpad.net/inkscape/+bugs?field.tag=backport-proposed
10:24 p.m.
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
9:15 p.m.
OK, these sound quite promising. I don't (yet) have a build
environment for libc++ so I can't test the last one.
Just a quick note that Ubuntu 14.04 (LTS) is hitting feature-freeze on
20 Feb, so if there are no objections we should try to get the 0.48.5
release ready in time for that date... 14.04 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!
AV
On 13 January 2014 13:24, Nicolas Dufour <nicoduf@...48...> wrote:
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
9:55 p.m.
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,
1:03 a.m.
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.
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!
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.
AV
11:22 a.m.
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
3360
days inactive
3362
days old
inkscape-devel@lists.inkscape.org
5 comments
4 participants
participants (4)
-
Alex Valavanis -
Bryce Harrington -
Martin Owens -
Nicolas Dufour