[Live-demo] Another OSGeo-Live BoF at FOSS4G today after OSGeo AGM

[Angelos Tzotsos]

Hi Hamish, thanks for the comments.


On 09/26/2013 03:37 AM, Hamish wrote:
> Angelos wrote:
>
>>   - PDF creation was discussed in order to provide our docs to
>> students as a handbook.
> it's a nice idea. Did Luca already start on that?

Yes, I think Luca has already done some tests on this.

>> - Find a way to update and build docs within the Live disk (eg by
>> not deleting the svn files)
> keeping the .svn/ files doubles the space needed for them on the disc.
> In the past we used 'svn checkout' during development to make that easy,
> and then 'svn export' at the last moment for the disc space.
> we could do that again.

The point was to be able to do development in the disk. My answer was 
that we don't have the disk space to handle the full svn repo. Your 
proposal seems good, lets try it.

>
>
>> 3. Code:
>>       - LOTS of people on the meeting want the project to move on git
>> (preferably on an OSGeo infrastructure). I would like to hear them on
>> the mailing list too. I am long ago in favor of that switch. It seems I
>> am not alone anymore...
> I remain generally against the idea, as I don't see it adding very much
> benefit to a project where we're all pulling towards the same single
> release goal, with focus on the final master iso.

One other issue about moving to git, would be easier transifex 
integration in order to handle translations.
Frank, since you have done this for GeoServer can you please share your 
experience here?

I understand that moving to git would create some overhead at first, and 
would complicate things a bit too, but I see a great benefit in the 
future. Of course, moving to git would mean splitting code in smaller 
pieces eg. one repo for installation scripts, one for docs/translations etc.

> AFAIK Angelos is the
> only one forking with experiments, so I feel for that.

Thanks :)

> I also feel for
> those that would like to work offline a bit more, but in the install
> scripts we seem to have a lot of peer review and back and forth small
> changes, so lone-coder bulk commits when they are back online could be
> less workable and less efficient.

Branching/merging is far more efficient in git so we would just issue a 
commit strategy:
master(trunk) would be only open for core maintainers to merge things 
into it. Anyone else would commit only in branches with feature names 
(eg mapserver_6.4) or ticket names (eg #124) and then someone from the 
maintainers  can cherry pick the stable commits to master. One other 
alternative would be to have a "dev" branch and sync to master when we 
feel it is working fine. Or we could branch a new release at beta stage 
and merge bug fix commits only to it.
I have seen all the above working flawlessly in other projects.

The above strategy would let us actually never freeze git (as we do in 
svn close to release) since unstable commits would never reach master 
until we say so. But contributors WILL be able to commit during that period.

I can go on and on with examples....

>
> a couple other points:
> -I don't want a model where I have to pull and merge in others changes,
> the time doesn't exist.

I am willing to take up this extra work.

> -git version numbers are not easily human parsable. In this regard I
> really miss CVS. :)

Yes this is true.

> -I am solidly against moving the HEAD/master of our dev efforts off of
> osgeo servers, so until such time as that exists I think it's premature
> to consider it- I don't think "we can redirect there once it does become
> available" is a good strategy.

Yes, I would like us to have a git repository in OSGeo servers too, I 
brought it up in the BOF meeting.
The same happens with QGIS, they host their git on their OSGeo VM and 
clone on GitHub to make easier for new users to contribute.

>
> I'm not saying git is bad, just that I'm not sure it is right for this
> particular project. just my 2c.
>

Well, git is suitable for large dev teams and we already have more that 
70 contributors...

Anyway, I don't want anyone to feel forced to this, it would be nice to 
hear more opinions/thoughts, especially from people planning to 
contribute more in the future.

>> 4. Data:
>>       - For 7.5 we should ask all projects to use only common data sets.
>> This is a big thing, similar to the Java cleanup we did for 6.0...
> it is not always practical, since some software needs a special format.
> (e.g. OpenCPN) We are getting there with software that loads geotiffs
> and shapefiles though. Some LANDSAT-8 data is a big todo. (see thread
> on the geodata list)

I agree, but projects that already use shapefiles and geotiffs should 
converge, right?

>
>
> thanks,
> Hamish
>
>

Best,
Angelos

-- 
Angelos Tzotsos
Remote Sensing Laboratory
National Technical University of Athens
http://users.ntua.gr/tzotsos