Re: osgEarth 2.5
On Tue, Feb 25, 2014 at 12:36:29AM +0100, Sebastiaan Couwenberg wrote:
> I'd like to keep supporting the exotic architectures as long as
> possible, but when this becomes too burdensome I'm not likely to object
> to limiting the supported architectures.
>
> Once OpenSceneGraph is fixed on hurd-i386, osgEarth will likely FTBFS
> because the pthread fallback is insufficient there. It will likely
> require a Hurd specific systemcall to get the thread ID. And once we've
> fixed osgEarth I suspect Murphy will have a nice Hurd FTBFS of qgis for
> us too. I had opted to make osgEarth linux-any because of the thread ID
> problem on kFreeBSD and no upstream support for FreeBSd in general, but
> in the fix was not very hard with some help from the porters. So
> considering limiting the supported architectures is a good thing to
> think about, but I also think we should try to support them all also
> long as possible.
>
Ok just consider that thing as a good possility to short the release
cycle and allow faster backportings.
> With the current Debian and QGIS release planning, we should be able to
> get QGIS 2.4 into testing. The five months between its release on
> 2014-06-20 and the Debian freeze in November should be sufficient. The
> planned release of QGIS 2.6 on 2014-10-24 is most probably too late, but
> we can choose to maintain it in experimental for those of us running sid
> or focus on backporting 2.6 changes to 2.4.
>
IMHO the supported qgis at the time of the stable release will be at least
a couple of release back upstream. They could be used by desktop gis newbies,
but I suspect that most of the users will just use upstream binaries.
On those regards we should maybe consider a better coordination with
upstream (mainly jef for debian binaries) in order to merge policy changes
as fast as possible in the upstream tree too and viceversa. That could
be very productive, because in the past I found that too often reconciliating
changes was a PITA (with git on both sides it should be better, but having
some common best practices on those regards could help us and upstream).
--
Francesco P. Lovergine
Reply to: