[cairo] Plans for release of 1.10.2

[Chris Wilson]

On Fri, 26 Nov 2010 10:40:41 +0100, Andrea Canciani <ranma42 at gmail.com> wrote:
> On Fri, Nov 19, 2010 at 10:35 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > On Fri, 19 Nov 2010 16:16:54 +0200, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote:
> >> On Friday 19 November 2010 14:44:17 M Joonas Pihlaja wrote:
> >> > On Fri, 19 Nov 2010, Kieran McCusker wrote:
> >> > > I know it's pointless but my manager was wondering if there are any
> >> > > approximate timescales for this point release?
> >> >
> >> > Are there any particular bugs you'd like to see fixed in 1.10.2?
> >>
> >> This one looks bad enough to me:
> >> http://cgit.freedesktop.org/cairo/commit/?h=1.10&id=91a6fe64236985d30f5794d760698deafd9e6511
> >>
> >> There are also some other fixes accumulated in 1.10 git branch.
> >
> > Right, we have more than enough important fixes already on the branch to
> > have merited a stable release long ago. It just needs a couple of hours to
> > check if there are no other patches that should also be on the stable
> > branch and then to do some sanity checking of the test results.
> >
> > If there are any candidates for 1.10 now is the time to either push them
> > or nominate them here. And I will make the release on Monday.
> 
> Two fixes for the build system that I think should be in:
> d51ab091422fc64831578bffb3a502c83ec8bdf5
> 6dda9c4465fa229f3fe9927e8318121642b41c14
> 
> and if we want to enable cairo-trace on DragonFly:
> 2b3d9b3a3aedc37481639dff923c97b8ff956c80
> 
> A (minor) fix for path construction that we might want in as well:
> 0655198301ec60b387b581a10b991ee442743374
> 
> Licensing of files we ship (I don't know if we want it in 1.10, but
> it is obvious it would not break anything and it's probably correct
> to state the license for files we release):
> 147fa7a2bea74bfc02059d99df72b998d45eb843

Applied all of the above.
 
> I would like get-path-extents to be fixed as per
> ac7b2a972097f4080ab6e5a29974c830b8b57a4f, but this would
> mean that it will have to be marked as XFAIL unless some major changes
> are made to the path code. Jeff Muizelaar fixed one case in:
> http://cgit.freedesktop.org/cairo/commit/?h=1.10&id=e9bb70d2dee4ef7a54e3971f09a08df30c2b5287
> but this commit is not sufficient to correct all extents computations (as
> pointed out in the "XXX" comments).

Don't have ac7b2a97 locally. get-path-extents reporting an inconsistent
API I can live with for the time being. If the computation is wrong (which
I believe you have already pointed out) then we should endeavour to fix
that.
 
> There have been multiple fixes for experimental backends that we
> might want to merge in master. I would expecially like:
> f20814e07e7032c14f273d712f35e19addfdae80
> b53084b7c530ed0473137ee8ebfab70fdd8e3c23
> because they fix compilation and potentially invalid memory accesses
> (respectively).

Applied, simple compilation cleanups.

> You might want to merge some of the xcb patches Uli Schlachter wrote,
> but I'm confident that you know better than me which one should go
> in 1.10 (maybe crasher bugs/wrong asserts?) and which should not.

I'm less keen on merging complex fixes for the experimental backends,
people using those should be looking towards tracking master (by the very
nature of the backend).
 
> Andrea
> 
> PS: To me it's still not completely clear what should go in 1.10.2.
> I suppose that build fixes and security/stability fixes have priority,
> but is this true both for supported and for experimental backends?

The first rule is that it has to fix a known (or obvious) bug and that
it does not introduce any further regressions. If it is a complex fix and
nobody has reported it, i.e. it has very limited impact, then we could
probably live with the known issue -- just so long as it is fixed in master.
[We have a good test suite, one that we should continue to improve, that
should give us confidence in not introducing regressions.]

As above, we should focus on keeping the stable backends in order. Those
are by definition the ones we have said we will maintain. If someone
invests considerable effort and declares that they will support an
experimental backend, then that is worthy of a new stable release in
itself.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre