Thanks everyone that's been working hard on making a solid 0.92.1. I'd like to gather current status on some of the tasks we've identified as desired for this release. Please update with any info I'm missing.
1. √ Tutorials and other .svg files we ship have the dpi scaling issue, and need updated for 0.92.1
--> JazzyNico landed fixes right after the 0.92.0 release. I presume this task has been completed with no remaining follow on work. I'd appreciate if someone could do a quick doublecheck just in case.
2. suv mentioned an extension to provide users a workaround to some line spacing issues, iirc.
--> Bunch of work has been done on this, see below.
3. A mechanism to backup / reset prefs settings
--> I'm unclear on status of this, but it appears not to have landed. Still a very good idea, but unfortunately probably too late for inclusion in 0.92.1.
The motivation for this feature was anticipation that bug triagers would be needing to ask people to clear their prefs to work around bugs. Now that the release is out in the wild, are we indeed seeing cases of this? If we aren't, then that might lessen the priority on this.
4. √ Fixes to some strings that were found post-string freeze
--> These have all landed, I believe.
5. A gpl3 widget needs removed (or relicensed)
--> IIRC gimpspinscale.c is the widget in question. The file is still present both in trunk and 0.92.x so this task still needs done. The motivation for this is that technically until it is removed or rewritten, the distributed Inkscape is effectively GPLv3 only, when we want it to actually be distributable as GPLv2.
Note also that the boilerplate text for ruler.cpp suggests it too is GPLv3. I think kk had obtained permission to distribute under GPLv2 but regardless, the licensing should be stated more unambiguously.
I'll add a 6th item:
6. Other priority bugs?
--> Could someone do a scan through the bug tracker to see if there have been bugs reported since 0.92.0 that would be a) quick/easy to fix, b) welcome improvements, and c) affecting many users? Especially bugs that already have patches or suggested fixes that could be landed with modest efforts.
For the line spacing issue, Mc wrote a more detailed TODO list for us:
(*1*) we need to apply, by default, the legacytext-fix ( https://gitlab.com/su-v/inx-legacytext/ ) to all pre-.92 files on open, or an aequivalent (internal) solution;
--> Work has been done towards an internal solution, although I'm unclear if it applies by default. Presuming that work still needs additional attention? I also wonder if there is still value in including this extension with 0.92.1 (the python script looks well written and maybe has a broader range of applicability than other solutions?)
(*2*) The import dialog is very unclear on what users should do, might not cover all cases (I tried to draft a diagram of possible cases and ended up with the nightmarish http://imgur.com/h6uEOHm but I'd like Tav's input on when to do what, and what to advise people doing by default), and does not gives hints on what to choose;
--> Mc authored a patch based on moini's UX design work, here: https://launchpadlibrarian.net/304202635/dialog.diff I'd like to see a few changes, but the overall implementation looks pretty solid:
a. Since we're going to be asking much of translators to get the dialog converted, I want to make sure our text is _solid_. (And since this is a highly visible dialog, good translations of it are important.) Offhand I can spot a couple grammar errors, and Brynn's made some good review comments on the text that I agree with. The verbage needs at least one more editorial go-around before I'll feel comfortable landing the dialog changes.
b. This patch merges in the refactoring changes from (*6) below, which while themselves absolutely fine, make it difficult to distinguish the actual code changes. I'd like to see these split up into (at least) two patches (e.g. one for the code moves, second to replace the dialog).
c. This also includes addition of a command line option for specifying a dpi-update-method which overrides the dialog. This can (and should) be landed independently. See (*4*) below.
(*3*) we need to bump the export-xdpi prefs setting and others (once only[which means add a versionning mechanism into the prefs: "if prefs are older than inkscape, do it"], if possible (others : bitmap copy resolution,bitmap import resolution));
(*4*) we need a commandline way to bump files from .91 to .92;
The review feedback on 0.92.0 makes me think this is probably the most important piece. One of the biggest use cases impacted by the dpi change is large collections of legacy documents, and converting them manually would be extremely inefficient, some scriptable method is needed.
People won't want to update their scripts once they're done, thus we should be doubly sure to get it the way we want it now so we don't have a need to change it in the future.
"--do-not-fix-pre-92" is already available on 0.92.x. Unfortunately this is not a good name for an option, as it doesn't indicate what the option actually *does*, and expressing it as a negative feels awkward. The help text, "Prevents automatic fix of pre-92 files on opening them" is unclear (what exactly is it fixing?) The change is not in trunk, but for aforementioned reasons I think we do need to plan on carrying the change at least through to 1.0.0.
I'm undecided on if this should be referencing a release number. It's certainly become clear we need to plan for mechanisms to allow us to detect and handle old file compatibility conversions, so the style we adopt here might be precident setting. (E.g. "0_92" might be more future-proof than "92".)
"--dpi-update-method" is added by the patch mentioned in (*2*) above. I think "convert" might be a better term than "update" since the former sounds more like a one-time change, whereas "update" sounds like something you might want to rerun periodically.
Since both --do-not-fix-pre-92 and --dpi-update-method relate to the same underlying issue, I bet they could be sensibly combined into a single commandline option.
A man page entry needs added for the commandline option.
(*5*) Add prefs for (2), similar to the embed/link choices, so that users don't have to specify several times when working with sets of similar files
--> What's the status on this? If work's not done on it, I'd still consider it for 0.92.2.
(*6*) port all that to trunk and clean involved code (for instance, move all that updating code to a separate file-update.cpp instead of file.cpp)
--> As mentioned in (*2*) I would prefer if the refactoring to move things about could be done in a distinct patch. Such a patch would have no functional changes so would be trivial to review.
And I totally agree with getting the code landed on trunk. There is always a danger when landing something on the stable tree but not on trunk, that updating trunk will get overlooked and result in a user regression in 0.93. (I understand why priority was getting it onto 0.92.x asap, but good practice is to always implement on trunk and backport, rather than vice versa.)
I believe we're still roughly on schedule for getting pre1 out Monday and entering string freeze. Despite the number of items outlined above, we still have 2 days until pre1, and 2 weeks until release. I know a lot of our main developers are tied up right now, but much of the above is straightforward coding and so hopefully there are others who can lend a hand at getting the work squared away.
A 0.92.2 seems very worthwhile at this point, as I suspect some chunk of the above won't be achievable within our timeframe. So I'll plan on doing a subsequent .2 release in 1-2 months.
Bryce
On Thu, Jan 05, 2017 at 06:44:30PM -0800, Bryce Harrington wrote:
The 0.92.x stable branch is reopened for changes. Consider it as under feature freeze but not string freeze.
Bugfixes are welcome to be added. Please continue to check with me before landing things, but for the next few weeks I expect to be in rubber stamp mode and approve most anything that looks sensible. We do need to be cautious about not introducing regressions at this point. Write good changelog messages explaining the fixes in good detail please.
Translation updates (and entirely new translations) are fine to land directly, no need to check with me. There are already a handful on the branch already that unfortunately came in just after I had cut the tarball.
Extension updates and new extensions are probably low enough regression risk that I'll try to be liberal in approving them. The ones we have to be cautious about are the highly used extensions, since we risk breaking people's workflow.
A few specifics I'm aware of, that sound worth including:
- Tutorials and other .svg files we ship have the dpi scaling issue, and need updated for 0.92.1
- suv mentioned an extension to provide users a workaround to some line spacing issues, iirc.
- A mechanism to backup / reset prefs settings
- Fixes to some strings that were found post-string freeze
- A gpl3 widget needs removed (or relicensed)
I'd like to avoid maintaining a bugs-needing-fixed list, but rather focus time more on patch review and testing. I figure the important thing is to get 0.92.1 out in a timely manner, and if there's still bugs needing attention we can always do a 0.92.2 some time later on.
Proposed Timing:
Mon Jan 2 Feature Freeze0.92.1pre0 Mon Jan 23 Hard Freeze 0.92.1pre1 Mon Jan 30 String Freeze 0.92.1pre2 Mon Feb 6 Release Candidate 0.92.1 Fri Feb 10 Cut Release Mon Feb 13 Announcement
I know we've not got a strong history of staying to schedule, but I'm going to try hard to hit these dates at least within a day or so. That means we'll have to be strict about string changes after String Freeze, and strict about any changes after the Release Candidate. This schedule allows the weekend of Feb 11-12 for prepping website changes, finalizing packages, and so on.
Anything you can think of missing from this plan?
Bryce
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel