On Fri, Jan 20, 2017 at 11:55:30PM -0500, Martin Owens wrote:
Developers,
As someone how changed the line-height code prior to release, I feel somewhat responsible for the issue in 0.92. I really didn't have enough time to focus on bugs before the release, but should have spent more time on things I'd changed. I'm really sorry Inkscape.
This thread isn't for figuring out how we're going to solve the issue though. I'll let the 0.91.1 discussion cover that.
What I'd like to pick apart is our bug management and how a release blocker like this line-height issue didn't put an all stop on our release schedule while we figured it out.
There's a couple of possibilities:
1. The bug wasn't discovered in time 2. The bug wasn't reported in time 3. The reported bug wasn't triaged in time 4. The bug wasn't prioritised as important 5. There wasn't a way to communicate a major issue to the release manager. 6. We just didn't have the resources to do the release properly and let things slide.
What information can Mc and su_v add about the issue? What can we fix to make the process better?
This particular issue is of a class caused by re-engineering of the codebase. Ultimately this traces back to the dpi switch that we knew we needed to do in order to match the CSS standard. I think we may have even postponed it a release or two due to fear it would disrupt users.
Flipping the y-coordinate system is probably another change of this class. Multi-page support might be another. I'm sure there's tons more I'm just not thinking of. Even the gtk3 switch (which ideally shouldn't affect documents just usability) has some potential for similar scale disruptions.
The fundamental change for these kind of efforts is often relatively small, but they can often necessitate widespread changes throughout the codebase. Sometimes those places aren't obvious and are found only with intense testing. Because of this invasiveness, doing the change in a branch can be quite challenging - first, because as trunk's code evolves in parallel the branch has to keep getting rebased (or sometimes even rewritten) to follow suit; second, because branches tend to get little to no attention from the regular userbase. For both these reasons, there is a very strong motivation to land the changes in trunk as early as possible.
Unfortunately, a consequence is that you have to be *extremely* thorough in testing and stabilizing the change before release. Sometimes the required changes are beyond the scope of the original programmer - e.g. adjustments needed for platform specific needs, or measures required to ensure backwards compatibility or interoperability. Predicting these ahead of time may be next to impossible; finding someone with time and the right set of skills to fill in the remaining work can likewise be prohibitively challenging in a volunteer project like ours.
I know that users don't understand or care about any of these internal development details, many will just see it as wanton disregard for compatibility.
I don't have better ideas on how to handle these, that doesn't risk these (as someone said) "soul-crushing reviews" like that peppercarrot one. Traditionally we've just avoided making releases, sometimes for years at a time, until we're 100% sure every last glitch is ironed out, but that has numerous severe drawbacks and I more favor the opposite approach of very frequent releases.
However, fast releases don't give much time for thorough testing before release, relying instead on the "many eyeballs make bugs shallow" social-contract of open source. I know this may be expecting more than some of our current userbase is willing to tolerate, but in some ways a smaller but more actively involved userbase would be healthier for the project's longer term prospects as a community resource.
Bryce