[gdal-dev] Misc. subjects : OSGeo Vienna code sprint, release plans, GDAL 2.0

[Kyle Shannon]

Even, thanks for the notes.

On Sat, Feb 15, 2014 at 11:57 AM, Even Rouault
<even.rouault at mines-paris.org> wrote:
> Thanks for your thoughs Kyle. I expect more developers and PSC members to
> express theirs too.
>
>>
>> How long would the stable branches be maintained?  Would we handle as
>> we do now, with one stable branch and one development branch, or would
>> we backport bug fixes to n branches (3.1, 2.4, etc)?  Would this
>> require maintaining 3 branches?  stable, trunk, and api_break?  Any
>> thoughts?
>
> What would be the api_break branch, as opposed to trunk I mean ?
> Maintaining 2 branches in addition to the development branch seems to be a bit
> too much work. Well, backporting is not that difficult generally, but releasing
> a version is an effort that takes some energy and time, so we would have likely
> difficulty in making the necessary releases. But anyone wanting to maintain a
> branch can do it, so there's no need to set that policy in stone.
>

Sorry, I chose poor wording, but you answered my question in regard to
two branches.  I agree with your assessment.

>>
>> > An alternative would be to prepare the API for new features even if they
>> > are not implemented, but that's a difficult exercise and there's a risk
>> > that at implementation time, the API doesn't fit.
>> > Any thoughts ?
>> >
>> > Currently we have no such breakage in trunk so it could qualify as GDAL
>> > 1.11. Perhaps we should just release it as such for now before the
>> > bigger changes ?
>>
>> Maybe release 1.11 soon, and take a crack at 2.0 changes before the
>> next release?  This would probably require a concerted effort from
>> developers or funders, as Even mentioned in regard to the sprint.
>>
>> > Somes topics I can see for GDAL 2.0 that impact API/ABI :
>> > - well, the mythological unification of OGR driver model with GDAL driver
>> > model.
>> > - XYZM support
>> > - Curve geometries
>> > - 64 bit integer support
>>
>> The 64-bit integer changes seem fairly straight forward.  I see XYZM
>> support up for GSoC again, maybe it'll get picked up.  I have no idea
>> what curve support would entail.
>
> Well, new geometry types and enhancements in drivers that would support them
> (PostGIS, ...). And also likely adapt all existing drivers that have write
> support so they can deal with the new geometry types : ignore them, or take
> them into account.
>
>>
>> > Other possible structural changes :
>> > - Change of master version control system: switch to git / GitHub ?
>> > - New build system : cmake ?
>>
>> What are the benefits here?  > Is travis integration easier?
>
> Well, I put that on the table since it is sometimes mentionned by developers,
> but the effort vs benefit ratio is not completely obvious for existing GDAL svn
> commiters.
> git transition would be mainly to keep up with what developers are of will
> soon be familiar with. Someone pointed me recently that GitHub also exposed
> git repositories as subversion repositories (which I experimented a bit), so
> that could satisfy most developers. git has the benefit of easing porting
> patches between branches, and making contributions from casual developers
> easier. Since the git mirror already exists, the transition to github would
> essentially require porting the Trac database to Github tickets (we could
> benefit from MapServer experience that has done that move before)

I have no preference as to which scm is used, although if it allows
more people to use or contribute, I'm all for it.  This is probably
not realistic, but it also may be a chance to purge some older/invalid
tickets from the trac database.  I imagine there is no way of really
doing this without a human checking for validity though.

>
>> I believe
>> someone has a cmake port floating around on github, any comments
>> there?
>
> The effort seems to have stalled. The benefit here would be the unification of
> the Unix and Windows makefiles, but the complexity of GDAL dependencies makes
> the porting effort rather repelling...

I can imagine...

>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html

Thanks.

-- 
Kyle