Re: Fwd: Schedule information for 211 - Debian GIS BoF
tOn 17-08-15 23:13, Johan Van de Wauw wrote:
> On Mon, Aug 17, 2015 at 8:49 AM, Andreas Tille <andreas@fam-tille.de> wrote:
>> Feel free to suggest items for the agenda.
>
> If I'd be at debconf, my nr 1 thing would be trying to get some move
> in the whole discussion about OGC licensing. OGC has been willing to
> change their license, but got no feedback at all from the FTP-masters.
> This is not really something to discuss, but should be brought to the
> attention of the right people. Any consensus we reach may also be a
> useful example to W3C so this discussion is useful outside our team.
> See eg: http://osgeo-org.1560.x6.nabble.com/OGC-XML-schemas-and-FOSS4G-software-distribution-td5186023.html
Seconded. If I'd been at DebConf I'd have raised this issue in the BoF.
> QGis: we somehow decided to stick to the LTS releases [2]. This is
> something where we will certainly get a difference with
> ubuntugis/osgeolive.
> I think the choice LTS/recent release deserves a discussion. If people
> ask for recent versions of gdal, they could then be pointed towards
> the discussion.
The decision to stick to QGIS 2.8.x LTR for the Debian package has not
clearly been made on the debian-gis list, I have discussed the topic in
various subthreads however:
qgis-developer:
Qt4->Qt5 timeline: Qt4's status and Qt4's webkit removal in Stretch
"
The qgis package in the Debian testing/unstable (from which Ubuntu
syncs) will most likely stick to the LTRs from now on, and skip the
non-LTR releases in between.
Users in need of the latest non-LTR can still get it from QGIS repo.
"
https://lists.osgeo.org/pipermail/qgis-developer/2015-May/037712.html
debian-gis: Backports for jessie
"
For QGIS I'm tempted to create a qgis-ltr source package to track the
QGIS Long Term Releases to benefit stable users mostly.
In testing/unstable we'll still want to track the normal QGIS releases
to get new features sooner than the next LTR (I'm thinking about GRASS
7 support specifically), and to provide fixes for the upstream
packaging to benefit the wider QGIS community who tend to use the
upstream packages (I hope my official backports will reduce the need
for theupstream packages).
On the other hand I'm not to fond of having two qgis packages in the
archive, and I suspect neither is the Release Team. So it may be better
to stick to the LTR releases in Debian and not worry about the upstream
packaging and non-LTR releases. This will mean that it will take a
while before we can move GRASS 7 to unstable.
"
https://lists.debian.org/debian-gis/2015/05/msg00015.html
Debian Bug#795078: 2.10 available upstream
"
We're sticking to the QGIS Long Term Releases in Debian, so we won't
update to QGIS 2.10 nor 2.12. QGS 2.14 should be the next LTR, we'll
stick to QGIS 2.8.x until then.
If you need features in QGIS 2.10 or later you're advised to use the
upstream QGIS packages:
http://qgis.org/en/site/forusers/alldownloads.html#debian-ubuntu
"
http://bugs.debian.org/795078
> How to take such a decision is perhaps one of the most interesting
> things to discuss. This applies equally to eg whether we should switch
> to GRASS7. Without getting too bureaucratic, having a vote like many
> OSGeo projects do may be a good way.
I don't think we need to vote to make decisions in the Debian GIS team,
it's more appropriate for the proposed incubation of UbuntuGIS with a
PSC and all that.
The Debian those who do the work get to make the decisions.
There is generally ample opportunity to voice concerns in the related
thread on the debian-gis list. If there is not, please start such a thread.
I base my decisions on the needs of the users, if they don't speak up I
cannot consider those needs. I happy to reconsider my decisions via
discussions on the debian-gis list preferably.
Regarding the QGIS LTR & GRASS 7 decisions, in a private subthread with
Markus Neteler of the recent 'GRASS and QGIS versions on OSGeo-Live?'
thread that was crossposted to the OSGeo-Live (live-demo) list I wrote
the following. To get this more widely available I'm reposting my
replies as there is nothing particulary private about them, the
subthread was private mostly because it was offtopic for GRASS 7.0.1
call for packaging thread that spawned it. It may be a bit confusing
because of the snipped context I'm replying to.
On 01-08-15 17:30, Sebastiaan Couwenberg wrote:
> You can't drop GRASS 6 without breaking QGIS 2.8.
> For GRASS 7 support you need QGIS >= 2.10.
> The final GRASS 7 changes expected in QGIS 2.12.
> http://www.gissula.eu/qgis-grass-plugin-crowdfunding/>
On 02-08-15 23:22, Sebastiaan Couwenberg wrote:
> In Debian it's not a joke. GRASS 7 is still in experimental because
> it breaks the QGIS plugin. There was strong user demand to not break
> the QGIS GRASS plugin that convinced me to not move it out of
> experimental before the QGIS issue is fixed.
>
> I was a bit disappointed that it required monetary incentive to
> update the QGIS GRASS plugin via the crowdfunding campain. An
> unfortuntate consequence of the user base not possessing the skills
> to contribute the GRASS 7 changes I guess.
On 02-08-15 23:56, Sebastiaan Couwenberg wrote:
> The GRASS user's needs do count, and were part of the tradeoff
> equation with a special place for the GRASS users via the QGIS
> plugin. I can't speak for GRASS users, not being one of them. I just
> maintain the Debian package because its a dependency of packages I do
> use myself and because of its importance to wider geospatial
> community.
>
> The previous maintainers were unable to keep up with the package
> maintainance, and I'm doing my best to fill that gap not to scratch
> my own itch but to contribute something usefull to the community.
>
> One of the solutions considered was to adopt the version specific
> source packages to allow GRASS 6 & 7 to co-exist. Because the Debian
> Release Manangers generally don't approve of multiple versions of a
> package to exist in the same release, and because I don't have the
> time to maintain two versions of the package I ended up choosing to
> stick to GRASS 6 in Debian unstable with GRASS 7 ready in
> experimental. For similar reasons I've not updated the Debian
> packaging for QGIS 2.10 and instead stick to the 2.8 LTRs. It's also
> a much better base for stable backports and so a more appropriate
> choice for Debian.
>
> This does mean that we have to wait for the next LTR (QGIS 2.14)
> before we can switch to GRASS 7 in Debian.
>
> [...]
>
> It's a shame that Ivan's recent work to get the GRASS 7 daily
> packaging into the Debian GIS git repository didn't work out, I was
> looking forward to build upon that to better align the official
> Debian package and the upstream GRASS packages. And work out some of
> the problems described above.
>
> There is still a lot of room for improvement in the collaboration
> between our respective communities, but I'm already quite pleased
> with the helpfull interaction I've had so far.
>
> Maybe we should bring Ivan and Martin into the loop to discuss the
> collaborative GRASS Debian package maintainance in more detail.
On 03-08-15 00:41, Sebastiaan Couwenberg wrote:
> [...]
>
> My initial plan was to upload GRASS 7 to unstable when the final
> release was made and disable the qgis plugin since it looked mostly
> unmaintained. To quote my post in the 'Packaging GRASS 7' thread on
> the debian-gis list:
>
> "
> Since the GRASS plugin is unmaintained according to some comments
> I read in the QGIS Redmine ([1],[2]), I don't think we should worry
> about qgis-plugin-grass too much. We'll just disable the plugin
> until someone from the GRASS community steps up and fixes it.
>
> [1] http://hub.qgis.org/issues/2947#note-14
> [2] http://hub.qgis.org/issues/11906#note-1
> "
>
> http://article.gmane.org/gmane.linux.debian.gis/1564
>
> After finishing the packaging of 7.0.0RC1 I shared my unhappiness
> with the QGIS situation:
>
> "
> I'm not really happy with the qgis-grass-plugin situation. There
> is clear user demand, but its removal is likely because it's not
> maintained well upstream. Hopefully someone will be motivated to
> fix the QGIS plugin after GRASS 7.0.0 is released.
> "
>
> http://article.gmane.org/gmane.linux.debian.gis/1597
>
> It required a crowfunding campain to get the GRASS plugin fixed in
> QGIS, just user demand was not sufficient. I'm not fond of that kind
> of development, I see it in the MapServer project too. If there is
> noone funding something it doesn't get done. Making a living of open
> source projects is still a difficult problem.
>
> [...]
>
> I hope we can get a fruitfull discussion when everyone's available
> again, as I'd like to get GRASS 7 into Debian testing/unstable too.
>
> Because it looks like the GRASS 7 related changes in QGIS 2.10 &
> 2.12 aren't going to be backported to the 2.8 LTR (although some
> were), I'm open to reconsider disabling the QGIS plugin. I can
> redirect user complaints to QGIS upstream that might motivate them to
> fix the plugin in 2.8 too. Having the GRASS 7 changes in the 2.8 LTR
> is my preferred solution to allow the switch to GRASS 7 in Debian.
On 03-08-15 01:53, Sebastiaan Couwenberg wrote:
> [...]Especially for packages I don't actively use myself
> I'm lead by the feedback I get from its users. This feedback is not
> very much, but in the case of the QGIS GRASS plugin it was very
> vocal.
>
> I'm happy to let someone else decide the direction of the GRASS
> package in Debian if they take on actively maintenance of the
> package. Hamish used to do take care of the GRASS package in Debian,
> but's his tendency to dissapear has hindered that for some time now.
>
> [...]
>
> Because of the processing support for GRASS 7 I didn't see much value
> in the qgis native plugin as I wrote in the debian-gis thread. I
> concluded that thread with a message about the availability of
> 7.0.0RC2 packaging, and about our brief encounter at FOSDEM where we
> spoke about the QGIS plugin.
>
> I'm already very happy with the way you contributed to the
> Processing support for GRASS 7, that's more integration work than you
> can expect from an upstream developer. I made the comment about
> someone from the GRASS community stepping up to fix the QGIS plugin
> because the QGIS community showed no will at all to update it for
> GRASS 7, the GRASS community was the obvious next choice to seek some
> motivated enough to fix the QGIS plugin.
>
> [...]
>
> I wish I could hold a referendum amongst the qgis & grass users of
> the Debian package what their preferred solution would be. But I have
> no good way to reach out to them or verify they're actual users or
> just sharing their opinion.
>
> I caved in to pressure from the QGIS users before, maybe it's time
> to cave in to the GRASS upstream pressure and get GRASS 7 into
> unstable. :-)
>
> We still have some time for user consultation, because due to the GCC
> 5 transition that started in Debian this weekend we can't build most
> of our C++ packages until more dependencies have been rebuild with
> GCC 5.
>
> If a good comparision of the native QGIS plugin and the GRASS
> Processing features shows that it's at least a good enough
> alternative, I have an argument to disregard the earlier user
> protest.
>
> [...]
>
> I hope that we'll be able to form a new pkg-grass team to
> collaboratively maintain the Debian packaging for GRASS. It was the
> basis of the Debian GIS team after all (we still use the pkg-grass
> project on Alioth).
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: