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

[Alex Mandel]

On 09/26/2013 01:32 AM, Angelos Tzotsos wrote:
> 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.

I recall previous work on this. If the formatting has been worked out so
that it's comes from the same sphinx source, great.

> 
>>> - 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.
>

It's really easy for someone to do dev on the disk, grab a copy, do a
new svn checkout and work from there. I do it all the time. The vagrant
box discussion should handle this too.

>>
>>
>>> 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....
> 

I see potential for the Docs to possibly be in git, if there's someone
handling those particular pull requests. This is also the part of the
repo most likely to be forked and variants produced. Easy enough to git
clone or git pull the latest Docs and build them.

For the main code I'm also fine a git-svn bridge to github if people
want it for forking, but plan to make it a one way, ie we don't take
code back from github.

We barely use branches and I don't see much need either. Single
definitive copy has been working quite well. Cherry picking commits
seems hard since we often don't know when they depend on each other.
We've also been pretty liberal about permissions to commit.

My experience has been many projects are indeed using it, but with a
greater mental toll to manage it. This project benefits from a single
strong central repo. Most changes are to a few files at a time, so
branching is generally not necessary. Version numbering in order greatly
helps us track where we are. Almost no one builds a vm locally, so
offline commits doesn't seem important either.

>>
>> 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.

That introduces complexity and single point of failure. We have 80+
committers and it's working. I see no need for this extra step.

> 
>> -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.
>>

OSGeo has been ready and willing to host git for years. What's missing,
a volunteer on SAC to implement. We have an idle clone of the trac VM
sitting waiting for someone to do the trac upgrade on it to recent
versions that supports git and multi-repo projects.

> 
> 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?
>

Yes we prefer reuse when possible.

>>
>>
>> thanks,
>> Hamish
>>
>>
> 
> Best,
> Angelos
> 

Thanks,
Alex