Retrospective on 0.92 release
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
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 Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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
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
… …
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 <doctormo@...400...> 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 Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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 mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
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
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
On 5 January 2017 at 09:22, Bryce Harrington <bryce@...961...> 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/CAERejNYTv3...
participants (6)
-
Bryce Harrington -
Lyndsy Simon -
Martin Owens -
mathog -
Sebastian Zartner -
Ted Gould