Hey All,
Just moving an off-list discussion to the devel list. It seems like setting a goal date for 0.48.1 is a good idea to move forward with it. So, what are people's thoughts on this and the state of things in that branch?
Cheers, Josh
On Thu, 2010-09-16 at 00:28 +0200, ~suv wrote:
On 15/9/10 23:07, Nicolas Dufour wrote:
De : Alexandre Prokoudine <alexandre.prokoudine@...400...> Nicolas, su-v, is there a considerable amount of bugs fixed already or at least some important ones?
Two crashers, and some minor issues fixes (https://edge.launchpad.net/inkscape/+milestone/0.48.1). And maybe some backports pending.
a) 2 patches with pending code review:
- Unicode/encoding related crash
I'd like to see the patch attached in Bug #369861 “Unable to open previously imported pdf file”: https://bugs.launchpad.net/inkscape/+bug/369861 get reviewed and backported for 0.48.1 if it is ok'ed.
Actually the patch seems to address the issue reported as Bug #605872 “pdf to svg fails with characters from Unicode Plane 1 (SMP)”: https://bugs.launchpad.net/inkscape/+bug/605872 which fails when using certain characters from the XITS math font. It also fixes (at least on osx) Bug #625927 “Inkscape crash when importing PDF file”: https://bugs.launchpad.net/inkscape/+bug/625927
The patch in bug #369861 was provided by the font developer who made the XITS fonts (OpenType MATH enhanced STIX fonts), see http://www.khaledhosny.org/node/143 http://typophile.com/node/71171
I still haven't had the chance to test other encoding/Unicode related crashes which might possibly be fixed by this patch too (in my understanding there are several similar ones to bug #369861).
- Import dialog enhancement
Another one with a patch pending review, nice to have in 0.48.1: Bug #203070 “Import Dialog doesn't handle multiple files”: https://bugs.launchpad.net/inkscape/+bug/203070
- ...
b) Regressions/crashes (no fix yet) I'd like to nominate for 0.48.1:
- crash loading system monitor profile
Bug #623640 “inkscape 0.48 crashes on startup in colorprofile_get_system_profile_handle()”: https://bugs.launchpad.net/inkscape/+bug/623640 Same issue reported on windows: Bug #608229 “Inkscape crashes on startup”: https://bugs.launchpad.net/inkscape/+bug/608229
- ...
c) and of course I'd prefer to wait with 0.48.1 until
Bug #482993 “Inkscape extensions do not work on MacOS X 10.6 (Snow Leopard)”: https://bugs.launchpad.net/inkscape/+bug/482993 is either fixed or we know one or two viable, confirmed workarounds that can be recommended to users on Snow Leopard until the issue is solved and Inkscape is bundled with updated python modules for all architectures.
d) ... ?
~suv
On Wed, Sep 15, 2010 at 8:37 PM, Joshua A. Andler <scislac@...400...> wrote:
Hey All,
Just moving an off-list discussion to the devel list. It seems like setting a goal date for 0.48.1 is a good idea to move forward with it. So, what are people's thoughts on this and the state of things in that branch?
I'd also like to propose to revert the change to the new Input Devices dialog, unless Jon (or anyone else - is there anyone willing to work on that?) makes some real improvements to its understandability and workability.
On 9/16/10, bulia byak wrote:
Just moving an off-list discussion to the devel list. It seems like setting a goal date for 0.48.1 is a good idea to move forward with it. So, what are people's thoughts on this and the state of things in that branch?
I'd also like to propose to revert the change to the new Input Devices dialog, unless Jon (or anyone else - is there anyone willing to work on that?) makes some real improvements to its understandability and workability.
Yes, I was too rather interested what Jon's response would be. Reverting that change would introduce strings freeze break which we sort of agreed not to do. OTOH it's a relatively small change in return for an obvious benefit, and if we give translators enough time, things would be safe enough, even though breaking policies is not something to break so easily :)
For the future we need to prepare for XInput2 anyway. GIMP 2.7.x already has first steps towards that and a new configuration dialog. Could we possibly be interested to have a look for ideas and co-operation?
Alexandre Prokoudine http://libregraphicsworld.org
On Sep 15, 2010, at 5:04 PM, Alexandre Prokoudine wrote:
For the future we need to prepare for XInput2 anyway. GIMP 2.7.x already has first steps towards that and a new configuration dialog. Could we possibly be interested to have a look for ideas and co-operation?
I've talked with the GIMP people a few times, and they are just not interested.
Also since they are sticking with plain C code and we're using C++ and GtkMM, there is not really any code we could share or collaborate on.
On 9/19/10, Jon Cruz wrote:
For the future we need to prepare for XInput2 anyway. GIMP 2.7.x already has first steps towards that and a new configuration dialog. Could we possibly be interested to have a look for ideas and co-operation?
I've talked with the GIMP people a few times, and they are just not interested.
Also since they are sticking with plain C code and we're using C++ and GtkMM, there is not really any code we could share or collaborate on.
As a matter of fact I was referring to user interface which doesn't really mean sharing code. As such.
Alexandre Prokoudine http://libregraphicsworld.org
On Wed, 2010-09-15 at 16:37 -0700, Joshua A. Andler wrote:
Hey All,
Just moving an off-list discussion to the devel list. It seems like setting a goal date for 0.48.1 is a good idea to move forward with it. So, what are people's thoughts on this and the state of things in that branch?
Yes, it would be good to have a goal date, not too far in the future but also not too quick so we have time to address crashes. I've noticed that 0.48 is not as stable as 0.47. I also have seen one major regression with text that I want to address but won't have time to get to it for a few weeks.
Tav
On Thu, 2010-09-16 at 10:14 +0200, Tavmjong Bah wrote:
On Wed, 2010-09-15 at 16:37 -0700, Joshua A. Andler wrote:
Hey All,
Just moving an off-list discussion to the devel list. It seems like setting a goal date for 0.48.1 is a good idea to move forward with it. So, what are people's thoughts on this and the state of things in that branch?
Yes, it would be good to have a goal date, not too far in the future but also not too quick so we have time to address crashes. I've noticed that 0.48 is not as stable as 0.47. I also have seen one major regression with text that I want to address but won't have time to get to it for a few weeks.
October 12 is my next surgery date. I expect that it will be a week or so before I am back online, like last time. Does something like shooting for October 25th sound good for giving people bug fixing time (as in when we fully freeze and hand off to packagers)?
Cheers, Josh
On Thu, 2010-09-16 at 02:16 -0700, Joshua A. Andler wrote:
On Thu, 2010-09-16 at 10:14 +0200, Tavmjong Bah wrote:
On Wed, 2010-09-15 at 16:37 -0700, Joshua A. Andler wrote:
Hey All,
Just moving an off-list discussion to the devel list. It seems like setting a goal date for 0.48.1 is a good idea to move forward with it. So, what are people's thoughts on this and the state of things in that branch?
Yes, it would be good to have a goal date, not too far in the future but also not too quick so we have time to address crashes. I've noticed that 0.48 is not as stable as 0.47. I also have seen one major regression with text that I want to address but won't have time to get to it for a few weeks.
October 12 is my next surgery date. I expect that it will be a week or so before I am back online, like last time. Does something like shooting for October 25th sound good for giving people bug fixing time (as in when we fully freeze and hand off to packagers)?
Sounds reasonable to me.
Tav
2010/9/16 Joshua A. Andler <scislac@...400...>:
Does something like shooting for October 25th sound good for giving people bug fixing time (as in when we fully freeze and hand off to packagers)?
Cheers, Josh
I think this should be enough time to fix the problems that don't need invasive changes.
Some extra notes to everyone: 1. Since the Launchpad move, EVERY Inkscape developer can commit to the 0.48 branch. Just check out lp:inkscape/0.48.x and commit there. 2. If you made some non-invasive bugfixes on the trunk, apply them to the 0.48 branch as well. You can use the bzr "merge" command for cherrypicking. To cherry pick revision 1234 from the trunk to the branch, go to the 0.48.x directory and say: bzr merge -r 1233..1234 ../trunk To cherry pick more than one revision, adjust the number range to include more changes. It makes more sense when you think of changes as happening between revisions, and of revisions as tags for specific states of the tree. Therefore the command merges changes that happened between 1233 and 1234 in ../trunk into the current branch. If you need to cherry pick several changes in one commit, all merges after the first one need to use the extra parameter --force. 3. This is a stability release, so don't backport new features or refactoring work into 0.48, only bugfixes.
Regards, Krzysztof
participants (6)
-
Alexandre Prokoudine -
bulia byak -
Jon Cruz -
Joshua A. Andler -
Krzysztof Kosiński -
Tavmjong Bah