Retrospective on 0.92 release

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Retrospective on 0.92 release

Bryce Harrington-3
With 0.92.0 now in the rear-view mirror (amazingly!) it's a good time to
look at places we could improve.

Overall I think it went quite well.  Switching build systems was a big
change, and getting two year's worth of feature work stabilized is quite
an achievement.

Based on the feedback I'm seeing, it looks like we made a very good
choice to retire our OSX packaging.  I admit I was a little worried, but
suv's judgment was 100% right, and as anticipated our deliberately *not*
providing it is stimulating others to step in and fill the void.  With
0.93 on Gtk3 it sounds like we'll have opportunities for even better OSX
packages.

Release management often is a tough trade-off between staying on
schedule vs. delaying to allow pulling in last minute improvements.  We
did a fair bit of the latter, which looks like it is paying off nicely,
but it did result in a quite long release cycle.  I feel bad at having
to say 'no' so much these last few weeks, I hope no hard feelings!  But
I suspect to achieve faster releases we're going to need to be more
rigorous here.  I would love to hear good ideas on how we could achieve
that.

Part of the delay was that the CMake conversion took rather longer than
I had anticipated.  I suppose that's the nature of volunteer projects,
and is going to hold true for most big changes we need to undertake.
Something we'll need to keep in mind when updating the roadmap.  All
that said, cmake does seem to be working out for the most part.  I
figure we'll need to revisit this again later (I'm starting to see some
strong buzz about a build system called Meson), but should stick with
cmake for the time being.  We've got other big infrastructural changes
pending which now need are full attention.

Another big part of the delay was blocker bugs.  I found this very hard
to get my hands around; the issues are legitimately troublesome problems
that should be resolved, but finding people able and available to work
on them was tough.  Unfortunately bugs are inevitable, and I worry the
shift to Gtk3, C++11, and so on are destined to give rise to more.  Does
anyone have ideas on how we can handle things better so there are fewer
blockers?  Or ways to get the blockers resolved more quickly?

Compared with the above two issues, the actual technical mechanics of
rolling out a release are trivial, however there is significant room for
improvement.  Compared with other projects I do release management for,
Inkscape's process is a bit too manual and has a number of extraneous
steps.  There are some opportunities for automation once we move to git,
and simply dropping autotools/btool/etc. will eliminate having to
manually edit a bunch of different files to set version numbers.  In the
future where there are files that require setting version numbers or
whatnot, instead of adding manual steps to the release process, what I
want people to do is add a configure_file() function call to our 'dist'
logic that substitutes the new release version number.  (I'm looking at
you, .snapcraft.yml.)

By now, we've done so many releases we have the release process down to
a bit of a science, and we have ample checklists and todo lists.  We
know quite precisely what needs to be done and when.  But where we ran
ran into trouble was getting those tasks assigned out and completed on
schedule.  Thankfully, everything ended up getting done - kudos to
everyone that stepped up and pitched in!  But far too often they got
done only after deadlines had passed; in some cases this caused schedule
targets to get postponed, in other cases it caused impacts elsewhere
such as translation.  Mainly I blame myself - ultimately these are all
failures in performing good release management.  But some how or other
we need to tighten all of this up if we are going to get releases out in
a more timely fashion.  Does anyone have suggestions or observations
that could help us improve this?

Finally let me say, "Great work!"  Because at the end of the day we've
done it - put out a solid release with some awesome features and a good
deal of attention to QA.  A common theme I'm seeing in comments is the
huge positive impact Inkscape has made in people's lives and careers,
and the 0.92 release you've created is going to enable a lot of people
to do some really great things.

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
|

Re: Retrospective on 0.92 release

Bryce Harrington-3
On Thu, Jan 05, 2017 at 12:22:45AM -0800, Bryce Harrington wrote:

> With 0.92.0 now in the rear-view mirror (amazingly!) it's a good time to
> look at places we could improve.
>
> By now, we've done so many releases we have the release process down to
> a bit of a science, and we have ample checklists and todo lists.  We
> know quite precisely what needs to be done and when.  But where we ran
> ran into trouble was getting those tasks assigned out and completed on
> schedule.  Thankfully, everything ended up getting done - kudos to
> everyone that stepped up and pitched in!  But far too often they got
> done only after deadlines had passed; in some cases this caused schedule
> targets to get postponed, in other cases it caused impacts elsewhere
> such as translation.  Mainly I blame myself - ultimately these are all
> failures in performing good release management.  But some how or other
> we need to tighten all of this up if we are going to get releases out in
> a more timely fashion.  Does anyone have suggestions or observations
> that could help us improve this?

Oops, despite the wall of text I forgot to mention an important part:

Somehow we forgot to write the release announcement.  I ended up
throwing something together last minute (post-release).  I think it was
pretty good but honestly it should have been written weeks ago.  As it
was, we were left with inadequate time to get it translated, and it's
been impacting website updates.  Again - mainly my own fault for letting
it slip through!  But going forward I think we really need to ensure we
assemble a team of writers to draft the various announcement texts we
need ahead of time, to ensure translators and web maintainers have
adequate time to process.

Maren also pointed out that the final part of the release schedule ended
seemed rather nebulous.  It can be hard to nail down exact times and
dates for a release when changes are still coming in at the last minute,
but the final steps of the release need to happen swiftly and so need to
be coordinated so they can happen in good synchronicity, and that
requires a clearly defined schedule and a commitment to get each bit
done predictably and on time.  Definitely an area to improve on next
time.  Accept my apologies if the suddenness of the release caused
problems for you; I will try and make it be less surprising next time
through.

> Finally let me say, "Great work!"  Because at the end of the day we've
> done it - put out a solid release with some awesome features and a good
> deal of attention to QA.  A common theme I'm seeing in comments is the
> huge positive impact Inkscape has made in people's lives and careers,
> and the 0.92 release you've created is going to enable a lot of people
> to do some really great things.
>
> 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
|

Re: Retrospective on 0.92 release

Martin Owens-2
In reply to this post by Bryce Harrington-3
Firstly,

Three cheers for Bryce, without whom we would have no release at all.

Let me add some thoughts to your postpartum below...

> Overall I think it went quite well.  Switching build systems was a
> big change, and getting two year's worth of feature work stabilized
> is quite an achievement.

Yes, it's quite the achievement. Each release build is a way for us a
programmers to say "Users matter and this is a thing we think users
should have" and it shows the project is not just a collection of self
interested coders, but also selfless volunteers that can get a lot of
these tasks done even if we don't benefit in a direct way.

Releases are perhaps the most primary target for paid work, where the
money comes from users. Especially given it's laborious, managerial
(pointy haired boss eh bryce ;-)) and could do with more attention.

Perhaps we could have a fund raising just for the next release, we'd be
setting ourselves some harder deadlines and if successful, we'd have
the money to pay for say a person or two to work on bugs and management
aspects.

> Based on the feedback I'm seeing, it looks like we made a very good
> choice to retire our OSX packaging.  I admit I was a little worried,
> but suv's judgment was 100% right, and as anticipated our
> deliberately *not* providing it is stimulating others to step in and
> fill the void.  With 0.93 on Gtk3 it sounds like we'll have
> opportunities for even better OSX packages.

We made a good call there. It's hard to say no to an entire platform,
but we really couldn't support it reasonably and people that use MacOSX
have the worst opinion of Inkscape imaginable. Look at some of the
comments about the release.

> Another big part of the delay was blocker bugs.  I found this very
> hard
> to get my hands around; the issues are legitimately troublesome
> problems
> that should be resolved, but finding people able and available to
> work
> on them was tough.  Unfortunately bugs are inevitable, and I worry
> the
> shift to Gtk3, C++11, and so on are destined to give rise to
> more.  Does
> anyone have ideas on how we can handle things better so there are
> fewer
> blockers?  Or ways to get the blockers resolved more quickly?

I see tackling bugs to be a big part of the problem. We may have to
have a talk about what it means to be an "Inkscape Developer" capital
I, capital D. Our requirements right now are two commits to trunk ever
in the past. There's no long term plan for members to retire and no bug
fixing requirement to keep an active Developer status.

We don't even specify in the about screen which members were active in
the last ten years of development. Anyone ever is in that list. Which
is good for voting, things like the board voting should be open to all
alumni. But for the kinds of attribution that is rewarding to see, we
don't really pay much attention and can't offer anything to bug fixers.

> a more timely fashion.  Does anyone have suggestions or observations
> that could help us improve this?

A service that does timed and shared task management might be an
improvement. I noticed there was a lot of manual work with regard to
task management.

> huge positive impact Inkscape has made in people's lives and careers,
> and the 0.92 release you've created is going to enable a lot of
> people to do some really great things.

Inkscape is one of those things in the world that provides millions of
dollars worth of economic and social value but which takes very little
money. Something Open Source projects can always be proud of.

But there's space to think about having our different user groups (cnc,
artists, animators, web designers, tracers etc etc) involved in sorting
out the major issues they have with their respective workflows. I
noticed that while a laser cutter problem is critical to workshops and
school use of inkscape, it was wishlist or low priority for the project
as a whole. That presents us with a problem where Inkscape is great for
90% of the work, but has critical failures for 90% of workflows at the
same time.

I'll keep thinking about this and I'd be happy to talk on IRC at our
next meeting.

Thanks again Bryce!

Best Regards, Martin Owens

------------------------------------------------------------------------------
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
|

Re: Retrospective on 0.92 release

Lyndsy Simon



> Based on the feedback I'm seeing, it looks like we made a very good
> choice to retire our OSX packaging.  I admit I was a little worried,
> but suv's judgment was 100% right, and as anticipated our
> deliberately *not* providing it is stimulating others to step in and
> fill the void.  With 0.93 on Gtk3 it sounds like we'll have
> opportunities for even better OSX packages.


> We made a good call there. It's hard to say no to an entire platform,
> but we really couldn't support it reasonably and people that use MacOSX
> have the worst opinion of Inkscape imaginable. Look at some of the
> comments about the release.


I also think it was a good call, but not because macOS users "have the worst opinion of Inkscape imaginable". You're seeing a very small segment of that community; most Inkscape users on macOS aren't going to engage in a flamewar because a new version doesn't have a download link for their platform on the day of its release.

If the existing dev team can't support the platform (which seems to be the case), then dropping it was absolutely the right move. If there is enough demand out there to justify packaging it in the future, let the people who want it to happen supply the resources to make it happen.

On Thu, Jan 5, 2017 at 9:48 AM Martin Owens <[hidden email]> wrote:
Firstly,

Three cheers for Bryce, without whom we would have no release at all.

Let me add some thoughts to your postpartum below...

> Overall I think it went quite well.  Switching build systems was a
> big change, and getting two year's worth of feature work stabilized
> is quite an achievement.

Yes, it's quite the achievement. Each release build is a way for us a
programmers to say "Users matter and this is a thing we think users
should have" and it shows the project is not just a collection of self
interested coders, but also selfless volunteers that can get a lot of
these tasks done even if we don't benefit in a direct way.

Releases are perhaps the most primary target for paid work, where the
money comes from users. Especially given it's laborious, managerial
(pointy haired boss eh bryce ;-)) and could do with more attention.

Perhaps we could have a fund raising just for the next release, we'd be
setting ourselves some harder deadlines and if successful, we'd have
the money to pay for say a person or two to work on bugs and management
aspects.

> Based on the feedback I'm seeing, it looks like we made a very good
> choice to retire our OSX packaging.  I admit I was a little worried,
> but suv's judgment was 100% right, and as anticipated our
> deliberately *not* providing it is stimulating others to step in and
> fill the void.  With 0.93 on Gtk3 it sounds like we'll have
> opportunities for even better OSX packages.

We made a good call there. It's hard to say no to an entire platform,
but we really couldn't support it reasonably and people that use MacOSX
have the worst opinion of Inkscape imaginable. Look at some of the
comments about the release.

> Another big part of the delay was blocker bugs.  I found this very
> hard
> to get my hands around; the issues are legitimately troublesome
> problems
> that should be resolved, but finding people able and available to
> work
> on them was tough.  Unfortunately bugs are inevitable, and I worry
> the
> shift to Gtk3, C++11, and so on are destined to give rise to
> more.  Does
> anyone have ideas on how we can handle things better so there are
> fewer
> blockers?  Or ways to get the blockers resolved more quickly?

I see tackling bugs to be a big part of the problem. We may have to
have a talk about what it means to be an "Inkscape Developer" capital
I, capital D. Our requirements right now are two commits to trunk ever
in the past. There's no long term plan for members to retire and no bug
fixing requirement to keep an active Developer status.

We don't even specify in the about screen which members were active in
the last ten years of development. Anyone ever is in that list. Which
is good for voting, things like the board voting should be open to all
alumni. But for the kinds of attribution that is rewarding to see, we
don't really pay much attention and can't offer anything to bug fixers.

> a more timely fashion.  Does anyone have suggestions or observations
> that could help us improve this?

A service that does timed and shared task management might be an
improvement. I noticed there was a lot of manual work with regard to
task management.

> huge positive impact Inkscape has made in people's lives and careers,
> and the 0.92 release you've created is going to enable a lot of
> people to do some really great things.

Inkscape is one of those things in the world that provides millions of
dollars worth of economic and social value but which takes very little
money. Something Open Source projects can always be proud of.

But there's space to think about having our different user groups (cnc,
artists, animators, web designers, tracers etc etc) involved in sorting
out the major issues they have with their respective workflows. I
noticed that while a laser cutter problem is critical to workshops and
school use of inkscape, it was wishlist or low priority for the project
as a whole. That presents us with a problem where Inkscape is great for
90% of the work, but has critical failures for 90% of workflows at the
same time.

I'll keep thinking about this and I'd be happy to talk on IRC at our
next meeting.

Thanks again Bryce!

Best Regards, Martin Owens

------------------------------------------------------------------------------
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
|

Re: Retrospective on 0.92 release

Ted Gould
In reply to this post by Bryce Harrington-3
On Thu, 2017-01-05 at 00:40 -0800, Bryce Harrington wrote:
Maren also pointed out that the final part of the release schedule ended
seemed rather nebulous.  It can be hard to nail down exact times and
dates for a release when changes are still coming in at the last minute,
but the final steps of the release need to happen swiftly and so need to
be coordinated so they can happen in good synchronicity, and that
requires a clearly defined schedule and a commitment to get each bit
done predictably and on time.  Definitely an area to improve on next
time.  Accept my apologies if the suddenness of the release caused
problems for you; I will try and make it be less surprising next time
through.

For me the surprise was that we didn't have an e-mail and small delay between the tarball and the announcement. I know that you were trying to reduce that time, but I think it makes sense to have it be at least a day.

Thanks Bryce!
Ted

------------------------------------------------------------------------------
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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Retrospective on 0.92 release

mathog
In reply to this post by Lyndsy Simon
On 05-Jan-2017 09:25, Lyndsy Simon wrote:
>> Based on the feedback I'm seeing, it looks like we made a very good
>> choice to retire our OSX packaging.  I admit I was a little worried,
>> but suv's judgment was 100% right, and as anticipated our
>> deliberately *not* providing it is stimulating others to step in and
>> fill the void.  With 0.93 on Gtk3 it sounds like we'll have
>> opportunities for even better OSX packages.

That and OS X is notoriously difficult to support - a binary built for
one version may or may not be upward compatible, and may or may not work
on the same release with different hardware.  This isn't just an open
source issue, it bites programs from commercial software providers as
well.  For instance, there is currently a problem in some software with
Retina Display machines running 10.12.x mangling dialogs, where that
same software works fine on older nonRetina Macs running the same OS
versions and on Retina Macs running 10.11.x.

Conversely, Windows upwards compatibility has usually been very solid.  
Binaries for software which run on Windows XP typically run just fine on
7, 8, or 10, and 32 bit apps work on 64 bit OS variants.  Of course
backwards compatibility isn't guaranteed and a 64 bit app is useless on
a 32 bit OS variant.

All that said, it would be a good thing if there was at least an
unofficial and unsupported source for Mac binaries of Inkscape.  Mind
share is important for the long term health of open source projects, and
a lot of graphics types prefer Macs to Windows or Linux.  These tend not
to be the sort of people who are going to be setting up virtual machines
on their OS X boxes in order to run another OS to access a single
application.

Regards,

David Mathog
[hidden email]
Manager, Sequence Analysis Facility, Biology Division, Caltech

------------------------------------------------------------------------------
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
|

Re: Retrospective on 0.92 release

Bryce Harrington-3
In reply to this post by Ted Gould
On Thu, Jan 05, 2017 at 11:35:56AM -0600, Ted Gould wrote:

> On Thu, 2017-01-05 at 00:40 -0800, Bryce Harrington wrote:
> > Maren also pointed out that the final part of the release schedule
> > ended
> > seemed rather nebulous.  It can be hard to nail down exact times and
> > dates for a release when changes are still coming in at the last
> > minute,
> > but the final steps of the release need to happen swiftly and so need
> > to
> > be coordinated so they can happen in good synchronicity, and that
> > requires a clearly defined schedule and a commitment to get each bit
> > done predictably and on time.  Definitely an area to improve on next
> > time.  Accept my apologies if the suddenness of the release caused
> > problems for you; I will try and make it be less surprising next time
> > through.
> For me the surprise was that we didn't have an e-mail and small delay
> between the tarball and the announcement. I know that you were trying
> to reduce that time, but I think it makes sense to have it be at least
> a day.
> Thanks Bryce!
> Ted

Yeah, my worry was that a public email about it would be too much of a
tip off to news outlets and our PR would get scooped, thus the radio
silence.  But you're right there needs to be a mechanism to ensure folks
that need to know like you get the notification when the source tarball
has been posted.  The new release system should hopefully address these
needs.

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
|

Re: Retrospective on 0.92 release

Bryce Harrington-3
In reply to this post by Martin Owens-2
On Thu, Jan 05, 2017 at 02:39:52PM +0000, Martin Owens wrote:

> Firstly,
>
> Three cheers for Bryce, without whom we would have no release at all.
>
> Let me add some thoughts to your postpartum below...
>
> > Overall I think it went quite well.  Switching build systems was a
> > big change, and getting two year's worth of feature work stabilized
> > is quite an achievement.
>
> Yes, it's quite the achievement. Each release build is a way for us a
> programmers to say "Users matter and this is a thing we think users
> should have" and it shows the project is not just a collection of self
> interested coders, but also selfless volunteers that can get a lot of
> these tasks done even if we don't benefit in a direct way.
>
> Releases are perhaps the most primary target for paid work, where the
> money comes from users. Especially given it's laborious, managerial
> (pointy haired boss eh bryce ;-)) and could do with more attention.
>
> Perhaps we could have a fund raising just for the next release, we'd be
> setting ourselves some harder deadlines and if successful, we'd have
> the money to pay for say a person or two to work on bugs and management
> aspects.

There's a lot of things we could do if we could get stronger fundraising
efforts going.  Our limiting factor is (as usual) manpower.

> I see tackling bugs to be a big part of the problem. We may have to
> have a talk about what it means to be an "Inkscape Developer" capital
> I, capital D. Our requirements right now are two commits to trunk ever
> in the past. There's no long term plan for members to retire and no bug
> fixing requirement to keep an active Developer status.
>
> We don't even specify in the about screen which members were active in
> the last ten years of development. Anyone ever is in that list. Which
> is good for voting, things like the board voting should be open to all
> alumni. But for the kinds of attribution that is rewarding to see, we
> don't really pay much attention and can't offer anything to bug fixers.

Improving incentivization for doing bug fixing work is a very good
idea.  That and patch review are the most direct impacts on the
software's quality.

Structuring membership better is an interesting thought, and potentially
something worth revisiting as part of the migration to git.  I'd be
hesistant about adding bug fixing as an actual requirement, as that
could have unintended consequences that we don't want.  But an
expectation that some minimum level of activity be maintained in order
to retain membership status doesn't seem unreasonable; the board has
requirements like that regarding voting, and the X.org foundation
actually forces all members to re-register each year.

> > a more timely fashion.  Does anyone have suggestions or observations
> > that could help us improve this?
>
> A service that does timed and shared task management might be an
> improvement. I noticed there was a lot of manual work with regard to
> task management.

Yes, it's a bit overwhelming how many little tasks there are in getting
a release out the door.  Tracking tools might help, though my hope is a
lot can be automated away, or process changes can make them unnecessary.
Of course, achieving both those things requires... tasks.

So yeah, there could potentially be some needs that a shared task
management tool could help address.  The crux of the problem is less
about keeping track of the tasks themselves, but rather in locating
people willing to do them.  Maybe that's what we actually need here, a
"contributor tracker" tool.

> > huge positive impact Inkscape has made in people's lives and careers,
> > and the 0.92 release you've created is going to enable a lot of
> > people to do some really great things.
>
> Inkscape is one of those things in the world that provides millions of
> dollars worth of economic and social value but which takes very little
> money. Something Open Source projects can always be proud of.
>
> But there's space to think about having our different user groups (cnc,
> artists, animators, web designers, tracers etc etc) involved in sorting
> out the major issues they have with their respective workflows. I
> noticed that while a laser cutter problem is critical to workshops and
> school use of inkscape, it was wishlist or low priority for the project
> as a whole. That presents us with a problem where Inkscape is great for
> 90% of the work, but has critical failures for 90% of workflows at the
> same time.

Very good points.  I've also wondered about if Inkscape's GUI could be
better structured along workflow lines, as a means to maybe declutter
the interface and/or enable performance optimizations.  For instance,
freehand drawing art isn't going to care much about snapping or grids
and disabling them could have rendering performance benefits.  Whereas
with drafting and CNC snapping can be crucial and rendering performance
tends not to be so much of an issue.

Done well, this could directly address the UX complaints that are
cropping up.  We've squeezed in a lot of amazing functionality into
Inkscape over the years, but every new button or widget adds to the
overall "weight" of the UI, making the tool more powerful but also
incrementing the effort needed to learn it.
 
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
|

Re: Retrospective on 0.92 release

Bryce Harrington-3
In reply to this post by Lyndsy Simon
On Thu, Jan 05, 2017 at 05:25:46PM +0000, Lyndsy Simon wrote:

> > We made a good call there. It's hard to say no to an entire platform,
> > but we really couldn't support it reasonably and people that use MacOSX
> > have the worst opinion of Inkscape imaginable. Look at some of the
> > comments about the release.
>
> I also think it was a good call, but not because macOS users "have the
> worst opinion of Inkscape imaginable". You're seeing a very small segment
> of that community; most Inkscape users on macOS aren't going to engage in a
> flamewar because a new version doesn't have a download link for their
> platform on the day of its release.
>
> If the existing dev team can't support the platform (which seems to be the
> case), then dropping it was absolutely the right move. If there is enough
> demand out there to justify packaging it in the future, let the people who
> want it to happen supply the resources to make it happen.

Precisely.  I do have to remain cognizant that "just send a patch" may
not have the same resonance with the prototypical Mac user that it might
for Linux, and so you're right to use the word 'resources' rather than
'coding'.  The Mac userbase may well have abilities and other resources
beyond coding that would hugely help Inkscape elsewhere.  Figuring ways
to enable more diverse ranges of participation would certainly pay off
in spades.

But near term, there doesn't seem to be a lot of options easily on hand
for this particular task, and we'll just need to hope for a hero or
heroine to muscle through it.  And actually, based on experience with
past porting, it's unlikely to be a one person job, but more of a relay
race, with each person documenting their findings and failures to give
the next person a head start to carry it forward.

suv says 0.93 with gtk3 will be significantly easier to package for osx,
and she's usually right so I remain optimistic.

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
|

Re: Retrospective on 0.92 release

Joshua Facemyer
In reply to this post by Bryce Harrington-3
This does make me sad, as at my day job I have no choice but to use osx. And I prefer Inkscape to the Adobe options, though I have ready access to them.

I do understand both sides of this debate, though. The x11 or Quartz version leaves a lot to be desired as compared to native GTK on *nix. The osxmenu project version was great...

But if there is a dearth of developers for this work, understood. It would be better to focus on what can be done on the supported platforms. FLOSS supporters on osx know we have to give up many preferred apps that just aren't available.

I wish I could help out here, but apart from a guided compile, I couldn't really contribute to packaging.

Maybe it's finally time to run a virtual xubuntu on osx to get the tools I miss...


JF

------ Original message------
From: Lyndsy Simon
Date: Thu, Jan 5, 2017 12:27 PM
To: Martin Owens;Bryce Harrington[hidden email];
Cc:
Subject:Re: [Inkscape-devel] Retrospective on 0.92 release




> Based on the feedback I'm seeing, it looks like we made a very good
> choice to retire our OSX packaging.  I admit I was a little worried,
> but suv's judgment was 100% right, and as anticipated our
> deliberately *not* providing it is stimulating others to step in and
> fill the void.  With 0.93 on Gtk3 it sounds like we'll have
> opportunities for even better OSX packages.


> We made a good call there. It's hard to say no to an entire platform,
> but we really couldn't support it reasonably and people that use MacOSX
> have the worst opinion of Inkscape imaginable. Look at some of the
> comments about the release.


I also think it was a good call, but not because macOS users "have the worst opinion of Inkscape imaginable". You're seeing a very small segment of that community; most Inkscape users on macOS aren't going to engage in a flamewar because a new version doesn't have a download link for their platform on the day of its release.

If the existing dev team can't support the platform (which seems to be the case), then dropping it was absolutely the right move. If there is enough demand out there to justify packaging it in the future, let the people who want it to happen supply the resources to make it happen.

On Thu, Jan 5, 2017 at 9:48 AM Martin Owens <[hidden email]> wrote:
Firstly,

Three cheers for Bryce, without whom we would have no release at all.

Let me add some thoughts to your postpartum below...

> Overall I think it went quite well.  Switching build systems was a
> big change, and getting two year's worth of feature work stabilized
> is quite an achievement.

Yes, it's quite the achievement. Each release build is a way for us a
programmers to say "Users matter and this is a thing we think users
should have" and it shows the project is not just a collection of self
interested coders, but also selfless volunteers that can get a lot of
these tasks done even if we don't benefit in a direct way.

Releases are perhaps the most primary target for paid work, where the
money comes from users. Especially given it's laborious, managerial
(pointy haired boss eh bryce ;-)) and could do with more attention.

Perhaps we could have a fund raising just for the next release, we'd be
setting ourselves some harder deadlines and if successful, we'd have
the money to pay for say a person or two to work on bugs and management
aspects.

> Based on the feedback I'm seeing, it looks like we made a very good
> choice to retire our OSX packaging.  I admit I was a little worried,
> but suv's judgment was 100% right, and as anticipated our
> deliberately *not* providing it is stimulating others to step in and
> fill the void.  With 0.93 on Gtk3 it sounds like we'll have
> opportunities for even better OSX packages.

We made a good call there. It's hard to say no to an entire platform,
but we really couldn't support it reasonably and people that use MacOSX
have the worst opinion of Inkscape imaginable. Look at some of the
comments about the release.

> Another big part of the delay was blocker bugs.  I found this very
> hard
> to get my hands around; the issues are legitimately troublesome
> problems
> that should be resolved, but finding people able and available to
> work
> on them was tough.  Unfortunately bugs are inevitable, and I worry
> the
> shift to Gtk3, C++11, and so on are destined to give rise to
> more.  Does
> anyone have ideas on how we can handle things better so there are
> fewer
> blockers?  Or ways to get the blockers resolved more quickly?

I see tackling bugs to be a big part of the problem. We may have to
have a talk about what it means to be an "Inkscape Developer" capital
I, capital D. Our requirements right now are two commits to trunk ever
in the past. There's no long term plan for members to retire and no bug
fixing requirement to keep an active Developer status.

We don't even specify in the about screen which members were active in
the last ten years of development. Anyone ever is in that list. Which
is good for voting, things like the board voting should be open to all
alumni. But for the kinds of attribution that is rewarding to see, we
don't really pay much attention and can't offer anything to bug fixers.

> a more timely fashion.  Does anyone have suggestions or observations
> that could help us improve this?

A service that does timed and shared task management might be an
improvement. I noticed there was a lot of manual work with regard to
task management.

> huge positive impact Inkscape has made in people's lives and careers,
> and the 0.92 release you've created is going to enable a lot of
> people to do some really great things.

Inkscape is one of those things in the world that provides millions of
dollars worth of economic and social value but which takes very little
money. Something Open Source projects can always be proud of.

But there's space to think about having our different user groups (cnc,
artists, animators, web designers, tracers etc etc) involved in sorting
out the major issues they have with their respective workflows. I
noticed that while a laser cutter problem is critical to workshops and
school use of inkscape, it was wishlist or low priority for the project
as a whole. That presents us with a problem where Inkscape is great for
90% of the work, but has critical failures for 90% of workflows at the
same time.

I'll keep thinking about this and I'd be happy to talk on IRC at our
next meeting.

Thanks again Bryce!

Best Regards, Martin Owens

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Retrospective on 0.92 release

Sebastian Zartner
In reply to this post by Bryce Harrington-3
On 5 January 2017 at 09:22, Bryce Harrington <[hidden email]> wrote:
> Release management often is a tough trade-off between staying on
> schedule vs. delaying to allow pulling in last minute improvements.  We
> did a fair bit of the latter, which looks like it is paying off nicely,
> but it did result in a quite long release cycle.  I feel bad at having
> to say 'no' so much these last few weeks, I hope no hard feelings!  But
> I suspect to achieve faster releases we're going to need to be more
> rigorous here.  I would love to hear good ideas on how we could achieve
> that.

As we already discussed earlier[1], one point is to create feature
branches. This allows to keep the master branch stable (and by that
releasable) and goes hand in hand with the GitHub and GitLab workflow
of creating pull/merge requests. Another point, which you already
mentioned, is to be more rigorous about last minute improvements. Let
the team pick a few bigger features/changes and put them on the
roadmap for the next release. There may be more features and changes,
but they shouldn't block the release. Big changes like GTK3 or C++11
may stretch over several releases. Everything that comes too late for
a release, simply needs to wait for the next one. And with a faster
release cycle e.g. every few months, a feature that missed a release
doesn't have to wait too long to get public.

Sebastian

[1] https://sourceforge.net/p/inkscape/mailman/inkscape-devel/thread/CAERejNYTv3MdfRe-O0LLoYJHjLbi0dzHVk15k9n5gq8%3DTh0JTA%40mail.gmail.com/#msg32145816

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel