[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [DebianGIS] present state



On Sat, Feb 24, 2007 at 10:38:37AM +0100, Paolo Cavallini wrote:
> Could some DD please let us know what is the current state of etch? It
> is in freezing since very long, and the number of RC bugs has not
> systematically decreased in the last two months.
> In the meantime, most of our crucial software (postgis, qgis, grass,
> mapserver, gdal) have released new versions, often with important new
> functions or bug fixed, thus we are now lagging behind.
> Furthermore, several other packages are worth considering for packaging
> (eg udig, saga, terraview/terralib, ossim).
> Therefore, some clarification about where we are heading would be
> useful, or at least very interesting to me.
> Thanking you in advance.

My own opinion now as in the past is that DebianGIS should follow
upstream releases off-main and supporting backports after releases. 
Incidentally, I think currently many developers are freezed as well 
to avoid releasing new packages in sid and compromising the already
slow delay process.

Stopping development because of testing freeze is not optimal. 
Some packages are already up-to-date on svn (for what concerning me 
I'm missing gdal 1.3.4 just now). We have a good deal of new 
packages to be considered for packaging and they could  be
prepared as sooon as possible. We have svn branches, please
use them! The freezing is not an excuse to avoid source level
development.

I asked and obtained a project box (I dunno when it will be
delivered to me, currently) where I will setup a dak instance 
for managing a debian-gis master archive (mirrored on alioth)
and prepare other tools I'm thinking currently to better managing things. 
I found the current debpool-based archive too limited for that and I would 
avoid to increase alioth load.

For what is concerning release time, that's a more general problem
which impacts not only this subproject. You should better ask about that
on d-release to RM folk. For sure RC count is not a true blocker.

-- 
Francesco P. Lovergine



Reply to: