Re: libspatialite3 deps
On Fri, Mar 14, 2014 at 09:49:30AM +0100, Andreas Tille wrote:
> Hi Bas,
>
> On Thu, Mar 13, 2014 at 07:42:15PM +0100, Sebastiaan Couwenberg wrote:
> > On 03/13/2014 12:24 PM, Francesco P. Lovergine wrote:
> > > Hi Bas, isn't that the case to push spatialite & friends? Waiting RMs ok
> > > in this phase of the release workflow is quite pointless.
> >
> > To speedup the process of getting the new versions in unstable it's an
> > option. I'm not happy with the time it takes to get the go ahead, but I
> > also don't want to do an uncoordinated transition, at least not make
> > that decision. I'm tempted to put it up for a vote, if the majority of
> > the team thinks it's a good idea, we should go ahead anyway and leave
> > the transition for unstable to testing only.
>
> I could imagine that release team members ar busy with other things and
> in principle do not disagree at these times long in advance before the
> release. May be we ping again and announce something like "If we do
> not hear back from you until x+7days we assume that you do not intend
> to veto the planed transition."
>
> > As someone dependent on sponsors to get packages uploaded to the
> > archive, I'm not looking forward to the lectures that will follow my
> > RFSes for the uncoordinated transition.
>
> Perfectly understood. It might be a good idea if Francesco who is
> somehow the accepted leader of Debian GIS would write the mails above
> and would go on with one or two package uploads. I'd also promise
> that I do my best to get your packages sponsored as quick as possible
> to guarant a short transition method.
>
Being defensive in upgrading is generally a good practice, but it is
specifically required only when we are near to freezing time or not sure
about technical quality of the new version. Waiting too long
could be counterproductive on those regards.
Specifically spatialite is now in good state in experimental and the
4.x version is around since a long time. So waiting is pointless.
Also, current approach for Sandro F. and other GIS upstream is
suggesting the use a current version. The 3.x one is simply too old
and most of its problems are solved in 4.x series.
Also, about API/ABI status, Sandro is now smart enough to manage
properly updates of SONAME and so on, so we are not at risk on that,
just for notice.
> I also would like to (repeatedly) point out: Users of *unstable* should
> be aware that their system behaves like the name says: unstable.
>
> > Following the proper procedure in Debian takes time, we're notorious for
> > that. But I take comfort in the text of my favorite Debian t-shirt:
> > "Good things come to those who wait". I'm willing to spent the time to
> > follow proper procedure even though it's a bit inconvenient. I'd rather
> > do things correctly than quickly.
>
> That's for sure the correct attitude. However, in our current case I
> simply suspect a manpower bottleneck which leads to slow response. If
> I'm correct we should try to circumvent a bottleneck which has no real
> technical background.
>
+1
In the case of GDAL - with a good deal of changes within the 1.10 series -
I waited for a very reasonable time and annouced the plans in advance.
Then I procedeed with the transition when the package had become ready enough.
> > Because the packages are ready for the transition, Ubuntu has synced
> > them from experimental.
>
> I think this is an unfortunate result of beeing forced to sit and wait.
>
> > Debian testing and unstable remain the sole
> > distributions with SpatiaLite 3.x. To get the updated packages in the
> > hands of users it's arguably a good idea to not wait much longer to
> > upload them to unstable.
>
> +1
>
> > With the osgEarth 2.4 and QGIS 2.2 upgrade in the pipeline, I want to
> > focus on completing that first. The armhf buildd finally got around to
> > building QGIS 2.2, but failed again while generating the API docs. So I
> > need to fix that first. I definitely don't want to do the uncoordinated
> > SpatiaLite transition with QGIS 2.2 still in experimental. Uploading
> > QGIS 2.2 to unstable as part of the uncoordinated transition has my
> > preference if we chose to go that route.
> >
> > Despite my reservations, performing the uncoordinated SpatiaLite
> > transition in unstable may be in the best interest of our users.
>
> +1
>
> Kind regards
>
> Andreas.
>
--
Francesco P. Lovergine
Reply to: