Quantcast

0.92.1 plan

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

0.92.1 plan

Bryce Harrington-3
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 Freeze
  0.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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 0.92.1 plan

Marc Jeanmougin
Hi all,

>From my perspective (mainly bug reports and IRC support, but also a
lengthy irc discussion with deevad [from
http://www.peppercarrot.com/en/article396/new-inkscape-0-92-breaks-your-previous-works-done-with-inkscape
]), the main noticeable thing about .92 was the line height breakage
problem. I really think that it would be a good thing to include su_v's
extension (or port it to a cpp internal function) and automatically
apply it when opening files made with previous versions, and release the
.91.1RC just after that (as soon as possible, even possibly before your
proposed timing).

Ideally, we could also change the file import dialog to include
instructions so that user would know what they should choose. Something
along the lines of "If your file dimensions are based on pixels (you're
not planning to use a cnc or print directly from inkscape), choose
"ignore"; else choose "set viewBox", except if you know what you're
doing." [might not be compatible with the "RC asap" because of the
strings to translate]

In the terms of the pre-0.92 to 0.92 file update, we identified with
su_v, by decreasing importance, the following items:
(*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 equivalent (internal) solution;
(*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;
(*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;
(*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
(*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 )

--
Marc

On 01/06/2017 03:44 AM, 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 Freeze
>   0.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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 0.92.1 plan

Maren Hachmann
Am 21.01.2017 um 02:19 schrieb Marc Jeanmougin:

> Hi all,
>
>>From my perspective (mainly bug reports and IRC support, but also a
> lengthy irc discussion with deevad [from
> http://www.peppercarrot.com/en/article396/new-inkscape-0-92-breaks-your-previous-works-done-with-inkscape
> ]), the main noticeable thing about .92 was the line height breakage
> problem. I really think that it would be a good thing to include su_v's
> extension (or port it to a cpp internal function) and automatically
> apply it when opening files made with previous versions, and release the
> .91.1RC just after that (as soon as possible, even possibly before your
> proposed timing).
>
> Ideally, we could also change the file import dialog to include
> instructions so that user would know what they should choose. Something
> along the lines of "If your file dimensions are based on pixels (you're
> not planning to use a cnc or print directly from inkscape), choose
> "ignore"; else choose "set viewBox", except if you know what you're
> doing." [might not be compatible with the "RC asap" because of the
> strings to translate]
>
> In the terms of the pre-0.92 to 0.92 file update, we identified with
> su_v, by decreasing importance, the following items:
> (*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 equivalent (internal) solution;
> (*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;
> (*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;
> (*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
> (*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 )
>

- Just wanted to express my support for this and say 'thank you', Marc
(and Deevad) for bringing it up!

(can't help much beyond giving feedback on string understandibility and
translation, and later help populate the website contents).

Somewhat related: The broken default setting retrieval for line-height
if em, %, ex or unitless is also causing confusion among users
(https://bugs.launchpad.net/inkscape/+bug/1645016).

Maren

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 0.92.1 plan

Bryce Harrington-3
In reply to this post by Bryce Harrington-3
Just a reminder that today's hard freeze.  If you have bugfix patches
please ping me or get them to me ASAP.  I'll be cutting the pre0 release
this evening (you have at least 8 hours to go...)

String freeze is next Monday.

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 Freeze
>   0.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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 0.92.1 plan

Miguel Lopez
For this part, I'm guessing one should be able to transfer preferences
between computers regardless of OSes, and Inkscape version above .92?
It's a little too much work to offer this to earlier version of Inkscape
though, but I guess one can volunteer to try that, but people should
really stick to the latest for the most part. I don't have any other
questions.


On 1/23/2017 1:50 PM, Bryce Harrington wrote:
>>    + A mechanism to backup / reset prefs settings
>>    


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 0.92.1 plan

Bryce Harrington-3
On Tue, Jan 24, 2017 at 03:00:10AM +0000, Miguel Lopez wrote:
> For this part, I'm guessing one should be able to transfer preferences
> between computers regardless of OSes, and Inkscape version above .92?
> It's a little too much work to offer this to earlier version of Inkscape
> though, but I guess one can volunteer to try that, but people should
> really stick to the latest for the most part. I don't have any other
> questions.

That would be an interesting capability, but the specific functionality
that was proposed simply permits copying the current prefs to a .bak and
then resetting prefs to defaults (or something approximating the
equivalent).

Perhaps it would be worthwhile to consider storing the Inkscape version
number in the preferences.xml file.  I think that would be needed for
transferring prefs between computers where the Inkscape version might
differ.

Bryce

> On 1/23/2017 1:50 PM, Bryce Harrington wrote:
> >>    + A mechanism to backup / reset prefs settings
> >>    
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 0.92.1 plan

Bryce Harrington-3
In reply to this post by Bryce Harrington-3
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 Freeze
>   0.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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Loading...