[gdal-dev] GDAL 2.0 release plans

[Dmitry Baryshnikov]

Hi Even,

It's strange as I create patch with same command (svn diff --force > 
~/md_reader.patch) as previous one.
I add changes for metadata readers directly to svn trunk copy on my PC.
I can create pull request for github GDAL trunk, but it takes some time 
to do, or I can just commit to svn trunk (preferable).
If something will be wrong, it can be easily roll back.

So, I decide to commit my changes to trunk.

Best regards,
     Dmitry

03.05.2015 12:11, Even Rouault пишет:
> Dmitry,
>
> I didn't manage to apply the patch (due to the binary files)
>
> $ patch -p0 < /tmp/md_reader.patch
> patching file autotest/gcore/data/md_dg.IMD
> patching file autotest/gcore/data/md_dg.RPB
> patching file autotest/gcore/data/md_dg.tif
> patch: **** malformed patch at line 187: \ No newline at end of file
>
> Is there some branch somewhere where it can be tested ?
>
> That said, I have no further remarks on this updated patch which looks good to
> me.
>
> Even
>
> Le dimanche 03 mai 2015 01:34:04, Dmitry Baryshnikov a écrit :
>> Hi everybody,
>>
>> Let me introduce the patch to the current GDAL v.2 trunk. This patch
>> change the way how imagery (satellite or aerial) metadata read. I create
>> some base classes and several metadata readers: DigitalGlobe, GeoEye,
>> OrbView (change existed code to use metadata readers), add Landsat,
>> Pleiades, Resurs-DK1 (plan to add about 6 new satellites). Also I added
>> new metadata domain: IMAGERY to hold some common imagery metadata:
>> satellite, cloud cover, acquisition date/time. The cloud cover transform
>> to values from 0 to 100 or 999 for n/a, and date/time to UTC.
>>
>> Additional code review and testing are welcome. Also let me know, if I
>> can commit this changes to trunk.
>>
>> P.S. Even review the code of previous patch. I fix all errors reported
>> by Even.
>>
>> Best regards,
>>       Dmitry
>>
>> 29.04.2015 21:40, Even Rouault пишет:
>>> Hi,
>>>
>>> I wanted to have an update from other developers to know where there are
>>> with respect to their planned schedule.
>>> I had noted that :
>>> - Dmitriy wanted to integrate his work on metadata support for various
>>> satellite imagery. I have reviewed a preliminary version of it.
>>> - Ari has ongoing work on Perl. I've seen a few commits passed.
>>> - Pirmin intended to add curve support in Interlis. Haven't seen yet any
>>> commit.
>>>
>>> Are you still in track to finalize those works in the following days ?
>>> Would adding the week-end help to have that in Beta1 ? I especially
>>> think to Dmitriy's work who is quite substantial, and perhaps Perl
>>> changes if there are still breaking change to come. Interlis specfic
>>> changes might arrive after Beta1 I think.
>>>
>>> Even
>>>
>>>> Hi,
>>>>
>>>> Some time ago, I mentionned my proposal of issuing a first GDAL 2.0 beta
>>>> version for the end of this month (April 30th). Are there objections to
>>>> sticking with that plan ? Does someone need a bit more time to finish an
>>>> ongoing work ?
>>>>
>>>> And if things go well with this beta (and potentially other beta(s)
>>>> needed), we could try a release candidate for end of May. One month of
>>>> beta phase might seem a bit short, but I'm not sure extending the beta
>>>> testing period more will bring significant additional feedback (and
>>>> things tend to slip, so better aim for a tight schedule). Thoughts ?
>>>> Anyone using GDAL intensively and/or interesting in 2.0 should already
>>>> track trunk closely ;-)
>>>>
>>>> I can wear the hat of 2.0 release manager, but I'm happy to let it to
>>>> any other volunteer.
>>>>
>>>> Best regards,
>>>>
>>>> Even