[Live-demo] [live-demo] Kick-starting OSGeoLive 7.5

[Alex Mandel]

On 12/10/2013 01:37 PM, Ivan Minčík wrote:
> My proposal here is to split the project (since it grew too big):
> 
>> - OSGeoLive ppa (UbuntuGIS or perhaps other)
>> - OSGeoLive apt repository (for packages not fitting under the Launchpad
>> rules, eg. Java binary packages)
>> - OSGeoLive docs and translations (should be maintained separately and
>> create a deb file periodically e.g. for every new commit)
>> - OSGeoLive data (also should be packaged in a deb file)
>> - OSGeoLive build scripts (for anything not in a deb file, e.g. the actual
>> build files)
>>
>> +1, splitting is a good idea.
> 
> 
>> This would also simplify things:
>> All projects must provide deb packages, else they are not included in the
>> 8.0 release. So 7.9 will be a transition release...
>>
>>
>>
>>> 2. As such our critical mass for turning over a release requires more
>>> effort than before.
>>>
>>
>> If we manage to have everything as a deb file, actually this will be MUCH
>> easier, plus we can upgrade between releases...
>>
>>
> I would like to note a few things.
> Creating and maintaining DEBs for all apps can be a huge task.
> Theoretically, if it would be done, it needs to be re-maintained every time
> when a new release is done (or does it make a sense to release without
> updating apps ?). Updating packages at every OSGeoLive release means also
> that it needs separate repository. This means another Debian GIS repository
> fragmentation (Debian GIS, UbuntuGIS, QGIS Debian repo, others ...) and
> less cooperation between projects. I think it is really important to join
> forces of all Debian and Ubuntu GIS groups together [1] and make agreement
> on rather less frequent but high quality common repositories.
> 
> Here is one of my proposals about UbuntuGIS packaging infrastructure [2],
> but there are much more ideas. Personally, I think that maintaining high
> quality repository (which means regular patching of security and other
> important problems) is possible only for LTS releases.
> 
> Lot of Open Source GIS software is mature enough and it doesn't depend so
> much on little bit updated version. This software (lets call it core group
> of software) could be installed from common DEB repository. Newer or less
> mature software could be still installed from sources.
> 
> 1 - http://linuxminded.nl/tmp/pkg-grass-website/policy.html
> 2- http://lists.osgeo.org/pipermail/ubuntu/2013-November/000937.html
> 
> Ivan
> 
> 

We should not be maintaining our own repo/ppa for anything that isn't
specifically osgeo-live. That means only build scripts, documentation
and data extractions are candidates. All 3 of these can happily live in
the same repo/ppa. Software should always come from already existing
sources as much as possible.

I agree that we need to stick to every 6 months. It's things like QGIS,
Geoserver, Leaflet, OpenLayers, geos, gdal, etc that are constantly
changing and people always want the latest version (Note Geoserver is
doing timed 6 mo releases). Long time stable software (I'm not going to
call it Core because that will only lead to confusion) is already simply
pulled from Ubuntu directly where it comes from Debian to begin with (ie
GMT).

As for Java packages, geonode/geoserver have demonstrated there is a way
to still use ppa's even if the java source doesn't make it quite there
at this time. We should not maintain our own debian style repo, thats
way too much extra work when launchpad does it for us.

I think Angelos was thinking Docs/Translations needed to be split into
it's own VCS. This is partly driven by wanting to use Transifex. The
biggest downside is maintaining multiple versioning systems, which also
could cause the docs/translation to be out of sync with the the actual
releases unless we're careful to tag/branch specific to a release cycle
and only pull the docs for that release.

Just to be clear, the conversation appears to be conflating a package
repository and version control repository.

Thanks,
Alex