On Wed, Apr 02, 2008 at 09:17:13PM -0500, Aaron Spike wrote:

rygle wrote:

...

I'm also thinking about a list of new features, and whether we should get them out for 0.46.1 or 0.47?

Traditionally only bug fixes have been backported from trunk to point releases. Features wait until the next full release.

Correct; there are a number of reasons for this, one of which is that we stand a better chance of getting the whole package accepted into Linux distros if we can show it to be a pure bug fix release, with all changes carefully tracked and documented.

From a Windows standpoint, there are a LOT of IT depts that will be

evaluating whether to accept the Windows version of Inkscape based on the quality of our .1 releases, and they also will prefer to see releases that are strictly carefully selected bug fixes. (I've also heard this from companies and one government, with interest in deploying Inkscape, that had this as a criterion).

A case in point - after the 0.45.1 release I worked to try to get it included into Ubuntu Feisty, but because we hadn't been sufficiently careful in tracking and itemizing the bug fixes, it didn't make it in.

The expectation I'm seeing from the above types of organizations is that only important bug fixes are included, and that for each fix:

* It solves a 'high-impact bug', such as any one of these: + Causes a security vulnerability + Severe regression from prior release + Can cause loss of user data + Causes failure to build on some platform + Causes segfault, crash, lockup, freeze, etc.

* Steps to reproduce the bug in the current inkscape release are given

* A patch is provided for review (svn revisions are okay... but a tangible patch is better)

* Discuss regression potentials. I.e., what is the risk level for causing side effects or breakage for other users? (For instance, if it fixes an OSX problem, is there risk of breaking on Windows?)

Some of the types of things that got kicked back in 0.45.1 were patches that were mostly code cleanups, "theoretical crashers" without steps to reproduce, cosmetic issues, feature tweaks/enhancements, etc. These may seem important to us, but distros and deployers may reject the update if there's too many of them.

Translation updates are a special category. They don't count as a 'high impact bug', however they have such low regression risk that they wouldn't count against adoption of a point release.

Bryce

On Wed, Apr 02, 2008 at 07:24:18PM -0700, rygle wrote:

By the way, this is not to push anyone to do this too quickly, but to suggest that we chip away at this as we move towards a loosely agreed time frame.

If any platform wants/needs to release stuff before then, it can possibly be 0.46-x, like the Mac releases.

Perhaps the logical place to start would be the Windows patches, since they've been so much the focus of late already.

So the task would be for each patch to review them with an eye towards how necessary and safe they are for other platforms. Windows-specific patches which are completely #ifdef WIN32'd are going to be safe, and while obviously not *necessary* on other platforms would at least be harmless, so I guess as long as they're well marked and documented should be ok. Patches which have changes that are also applicable for other platforms are probably good but will need ample review and testing. In each case, itemize and document it as I described in my previous post, then apply to the 0.46.x tree.

Bryce