[SAC] Access to GDAL Trac database

Committees SAC mailing list
1

Hi,

Recently, Even asked [1] on gdal-dev ml about switch to Git
with GitHub as one of the three options proposed.
Although the feedback is modest so far and any silence means
agreement, GitHub is the preferred choice now.

I offered my help [2] in moving GDAL to GitHub.
I'd like to start prototyping the workflow to leave time to discuss
and resolve any issues. Mind you, I have never done such migration.

I'd like to request to grant me read-only access to GDAL Trac database.

I will use it to perform test migrations to sample repo on github.com/mloskot.
For the trial migrations, I'm not going to use github.com/OSGeo.

How can I get access to the database?

[1] https://lists.osgeo.org/pipermail/gdal-dev/2017-September/047060.html
[2] https://lists.osgeo.org/pipermail/gdal-dev/2017-September/047060.html

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

2

If it would help, I have the workflow we used for GeoServer to move to Atlassian.

Harrison

On Sep 24, 2017, at 11:04 AM, Mateusz Loskot <mateusz@loskot.net> wrote:

Hi,

Recently, Even asked [1] on gdal-dev ml about switch to Git
with GitHub as one of the three options proposed.
Although the feedback is modest so far and any silence means
agreement, GitHub is the preferred choice now.

I offered my help [2] in moving GDAL to GitHub.
I'd like to start prototyping the workflow to leave time to discuss
and resolve any issues. Mind you, I have never done such migration.

I'd like to request to grant me read-only access to GDAL Trac database.

I will use it to perform test migrations to sample repo on github.com/mloskot.
For the trial migrations, I'm not going to use github.com/OSGeo.

How can I get access to the database?

[1] https://lists.osgeo.org/pipermail/gdal-dev/2017-September/047060.html
[2] https://lists.osgeo.org/pipermail/gdal-dev/2017-September/047060.html

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

3

I don’t know much about Atlassian or how it
Is different to GitHub, but any ideas that
worked for similar to the planned migration
may be useful.

So please share.

Thanks,
Mateusz

···

On 24 Sep 2017 22:07, “Harrison Grundy” <harrison.grundy@astrodoggroup.com> wrote:

If it would help, I have the workflow we used for GeoServer to move to Atlassian.

4

Mateusz,

I see that GDAL's trac is backed by a postgres database instance:

database = postgres://postgres@/trac_gdal

Would it be reasonable for me to prepare a database dump of that? I'm
not sure if it is open to direct connects from outside the machine.

I can also tar up the "trac" tree which includes attachment files.

I was amused by:

"Although the feedback is modest so far and any silence means
agreement, GitHub is the preferred choice now."

While I'm not exactly a fan of GDAL tickets moving to github, I am
ironically in the position of fighting to use github at my current
employer (over some internally hosted git thingy) because "developers
already know github". So I suppose I can't really be hater. :slight_smile:

Best regards,
Frank

On Sun, Sep 24, 2017 at 1:18 PM, Mateusz Loskot <mateusz@loskot.net> wrote:

On 24 Sep 2017 22:07, "Harrison Grundy" <harrison.grundy@astrodoggroup.com>
wrote:

If it would help, I have the workflow we used for GeoServer to move to
Atlassian.

I don't know much about Atlassian or how it
Is different to GitHub, but any ideas that
worked for similar to the planned migration
may be useful.

So please share.

Thanks,
Mateusz

_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows |
and watch the world go round - Rush | Geospatial Software Developer

5

Frank,

First, I'd like to clarify the amusing part.

Six people responded so far and here are pro-GitHub counts:

+1 Dmitry, Even, Kurt, Tamas, Mateusz
  0 Daniel (not sure hot to interpret Daniel's voice though)

So, I assumed that those who did not respond are either
indifferent or will agree with any of the three proposed choices.
That is what I called silence == agreement.

Nobody has offered help in migration to any of the two other choices
proposed by Even.
If someone offers help to migrate to OSGeo gig/gogs, and if GDAL team
decides to go for it,
or if anyone from GDAL team asks me specifically to not to work on the
migration,
I'll be happy to fade away.

Even asked for help and, as incurable one who compulsively has to dunk
a hand in something, I thought I may **try** to help.

I don't advocate for GitHub.
I just like to use GitHub for pragmatic reasons.

I do not offer myself to help migrating to OSGeo git/gogs though.

Moving back to the topic:

The dump file will certainly work.
I can import it to local database and use for prototyping
Once the thing works, we can run it based on the original database, I guess.

I assume the attachment files are important part and have to be moved
along the tickets,
so yes, please pack it up all together.

Regards,
Mateusz

On 24 September 2017 at 22:43, Frank Warmerdam <warmerdam@pobox.com> wrote:

Mateusz,

I see that GDAL's trac is backed by a postgres database instance:

database = postgres://postgres@/trac_gdal

Would it be reasonable for me to prepare a database dump of that? I'm
not sure if it is open to direct connects from outside the machine.

I can also tar up the "trac" tree which includes attachment files.

I was amused by:

"Although the feedback is modest so far and any silence means
agreement, GitHub is the preferred choice now."

While I'm not exactly a fan of GDAL tickets moving to github, I am
ironically in the position of fighting to use github at my current
employer (over some internally hosted git thingy) because "developers
already know github". So I suppose I can't really be hater. :slight_smile:

Best regards,
Frank

On Sun, Sep 24, 2017 at 1:18 PM, Mateusz Loskot <mateusz@loskot.net> wrote:

On 24 Sep 2017 22:07, "Harrison Grundy" <harrison.grundy@astrodoggroup.com>
wrote:

If it would help, I have the workflow we used for GeoServer to move to
Atlassian.

I don't know much about Atlassian or how it
Is different to GitHub, but any ideas that
worked for similar to the planned migration
may be useful.

So please share.

Thanks,
Mateusz

_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows |
and watch the world go round - Rush | Geospatial Software Developer
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

--
Mateusz Loskot, http://mateusz.loskot.net

6

On Sun, Sep 24, 2017 at 11:37:57PM +0200, Mateusz Loskot wrote:

If someone offers help to migrate to OSGeo gig/gogs, and if GDAL team
decides to go for it,

For OSGeo Gogs there's not much to migrate as the tickets can remain
on trac and just the code could move (trac would still be able to
browse it). Anyway, I'm not volunteering to do it.

--strk;

7

On Sun, Sep 24, 2017 at 01:43:37PM -0700, Frank Warmerdam wrote:

Would it be reasonable for me to prepare a database dump of that? I'm
not sure if it is open to direct connects from outside the machine.

I can also tar up the "trac" tree which includes attachment files.

trac-admin hotcopy should create a directory including a database
dump, if I recall correcly.

--strk;

8

Strk,

I have provided Mateusz a "hotcopy" tree to work with. Thanks for the
suggestion.

Best regards,
Frank

On Sun, Sep 24, 2017 at 3:03 PM, Sandro Santilli <strk@kbt.io> wrote:

On Sun, Sep 24, 2017 at 01:43:37PM -0700, Frank Warmerdam wrote:

Would it be reasonable for me to prepare a database dump of that? I'm
not sure if it is open to direct connects from outside the machine.

I can also tar up the "trac" tree which includes attachment files.

trac-admin hotcopy should create a directory including a database
dump, if I recall correcly.

--strk;
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows |
and watch the world go round - Rush | Geospatial Software Developer

9

Our experience on the geoserver data was that aligning the Database schema itself was fairly difficult, because of things like attached files but that the APIs presented on each end made for a much easier target.

We used Ruby with Nokogiri and Mechanize, to call up a ticket on the source, grab attributes, then generate the new ticket at the destination. I'd say the biggest problem we ran into was not comprehensively mapping the attributes first, which caused a few false starts.

So, the workflow I'd suggest is mapping the fields first, working on a map of email addresses and accounts then working to create the tickets from there. Keep in mind that you won't have a 1:1 mapping of submitters and GH accounts, so some attribution will be lost in the transfer.

Harrison

On Sep 24, 2017, at 4:37 PM, Mateusz Loskot <mateusz@loskot.net> wrote:

Frank,

First, I'd like to clarify the amusing part.

Six people responded so far and here are pro-GitHub counts:

+1 Dmitry, Even, Kurt, Tamas, Mateusz
0 Daniel (not sure hot to interpret Daniel's voice though)

So, I assumed that those who did not respond are either
indifferent or will agree with any of the three proposed choices.
That is what I called silence == agreement.

Nobody has offered help in migration to any of the two other choices
proposed by Even.
If someone offers help to migrate to OSGeo gig/gogs, and if GDAL team
decides to go for it,
or if anyone from GDAL team asks me specifically to not to work on the
migration,
I'll be happy to fade away.

Even asked for help and, as incurable one who compulsively has to dunk
a hand in something, I thought I may **try** to help.

I don't advocate for GitHub.
I just like to use GitHub for pragmatic reasons.

I do not offer myself to help migrating to OSGeo git/gogs though.

Moving back to the topic:

The dump file will certainly work.
I can import it to local database and use for prototyping
Once the thing works, we can run it based on the original database, I guess.

I assume the attachment files are important part and have to be moved
along the tickets,
so yes, please pack it up all together.

Regards,
Mateusz

On 24 September 2017 at 22:43, Frank Warmerdam <warmerdam@pobox.com> wrote:
Mateusz,

I see that GDAL's trac is backed by a postgres database instance:

database = postgres://postgres@/trac_gdal

Would it be reasonable for me to prepare a database dump of that? I'm
not sure if it is open to direct connects from outside the machine.

I can also tar up the "trac" tree which includes attachment files.

I was amused by:

"Although the feedback is modest so far and any silence means
agreement, GitHub is the preferred choice now."

While I'm not exactly a fan of GDAL tickets moving to github, I am
ironically in the position of fighting to use github at my current
employer (over some internally hosted git thingy) because "developers
already know github". So I suppose I can't really be hater. :slight_smile:

Best regards,
Frank

On Sun, Sep 24, 2017 at 1:18 PM, Mateusz Loskot <mateusz@loskot.net> wrote:

On 24 Sep 2017 22:07, "Harrison Grundy" <harrison.grundy@astrodoggroup.com>
wrote:

If it would help, I have the workflow we used for GeoServer to move to
Atlassian.

I don't know much about Atlassian or how it
Is different to GitHub, but any ideas that
worked for similar to the planned migration
may be useful.

So please share.

Thanks,
Mateusz

_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows |
and watch the world go round - Rush | Geospatial Software Developer
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

--
Mateusz Loskot, http://mateusz.loskot.net
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

10

If Even and rest of GDAL are willing to try gitea/gogs, I’d be willing to do the work of the port.

Sandro has already done a proof of concept. I would like to see this work.

I think what we have at stake here is something bigger than GDAL moving.

It’s our trust in the very foundation of SAC and to a larger extent OSGeo and it’s usefulness to help with infrastructure support and manage that support.

I’d like to help in restoring that trust. We’ve got things like maling lists, OSGeo support, and project websites that need a strong SAC. Also tons I’d like to see that could be possible with a stronger SAC.

Thanks,

Regina

---------- Forwarded message ----------
From: Mateusz Loskot <mateusz@loskot.net>
Date: Sun, Sep 24, 2017 at 5:37 PM
Subject: Re: [SAC] Access to GDAL Trac database
To: System Administration Committee Discussion/OSGeo <sac@lists.osgeo.org>

Frank,

First, I’d like to clarify the amusing part.

Six people responded so far and here are pro-GitHub counts:

+1 Dmitry, Even, Kurt, Tamas, Mateusz
0 Daniel (not sure hot to interpret Daniel’s voice though)

So, I assumed that those who did not respond are either
indifferent or will agree with any of the three proposed choices.
That is what I called silence == agreement.

Nobody has offered help in migration to any of the two other choices
proposed by Even.
If someone offers help to migrate to OSGeo gig/gogs, and if GDAL team
decides to go for it,
or if anyone from GDAL team asks me specifically to not to work on the
migration,
I’ll be happy to fade away.

Even asked for help and, as incurable one who compulsively has to dunk
a hand in something, I thought I may try to help.

I don’t advocate for GitHub.
I just like to use GitHub for pragmatic reasons.

I do not offer myself to help migrating to OSGeo git/gogs though.

Moving back to the topic:

The dump file will certainly work.
I can import it to local database and use for prototyping
Once the thing works, we can run it based on the original database, I guess.

I assume the attachment files are important part and have to be moved
along the tickets,
so yes, please pack it up all together.

Regards,
Mateusz

On 24 September 2017 at 22:43, Frank Warmerdam <warmerdam@pobox.com> wrote:

Mateusz,

I see that GDAL’s trac is backed by a postgres database instance:

database = postgres://postgres@/trac_gdal

Would it be reasonable for me to prepare a database dump of that? I’m
not sure if it is open to direct connects from outside the machine.

I can also tar up the “trac” tree which includes attachment files.

I was amused by:

“Although the feedback is modest so far and any silence means
agreement, GitHub is the preferred choice now.”

While I’m not exactly a fan of GDAL tickets moving to github, I am
ironically in the position of fighting to use github at my current
employer (over some internally hosted git thingy) because “developers
already know github”. So I suppose I can’t really be hater. :slight_smile:

Best regards,
Frank

On Sun, Sep 24, 2017 at 1:18 PM, Mateusz Loskot <mateusz@loskot.net> wrote:

On 24 Sep 2017 22:07, “Harrison Grundy” <harrison.grundy@astrodoggroup.com>
wrote:

If it would help, I have the workflow we used for GeoServer to move to
Atlassian.

I don’t know much about Atlassian or how it
Is different to GitHub, but any ideas that
worked for similar to the planned migration
may be useful.

So please share.

Thanks,
Mateusz

Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

–
---------------------------------------±-------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows |
and watch the world go round - Rush | Geospatial Software Developer

Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

–
Mateusz Loskot, http://mateusz.loskot.net

Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

11

Harrison,

Thanks for the hints, very much appreciated.

Mateusz

On 25 September 2017 at 00:25, Harrison Grundy
<harrison.grundy@astrodoggroup.com> wrote:

Our experience on the geoserver data was that aligning the Database schema itself was fairly difficult, because of things like attached files but that the APIs presented on each end made for a much easier target.

We used Ruby with Nokogiri and Mechanize, to call up a ticket on the source, grab attributes, then generate the new ticket at the destination. I'd say the biggest problem we ran into was not comprehensively mapping the attributes first, which caused a few false starts.

So, the workflow I'd suggest is mapping the fields first, working on a map of email addresses and accounts then working to create the tickets from there. Keep in mind that you won't have a 1:1 mapping of submitters and GH accounts, so some attribution will be lost in the transfer.

Harrison

On Sep 24, 2017, at 4:37 PM, Mateusz Loskot <mateusz@loskot.net> wrote:

Frank,

First, I'd like to clarify the amusing part.

Six people responded so far and here are pro-GitHub counts:

+1 Dmitry, Even, Kurt, Tamas, Mateusz
0 Daniel (not sure hot to interpret Daniel's voice though)

So, I assumed that those who did not respond are either
indifferent or will agree with any of the three proposed choices.
That is what I called silence == agreement.

Nobody has offered help in migration to any of the two other choices
proposed by Even.
If someone offers help to migrate to OSGeo gig/gogs, and if GDAL team
decides to go for it,
or if anyone from GDAL team asks me specifically to not to work on the
migration,
I'll be happy to fade away.

Even asked for help and, as incurable one who compulsively has to dunk
a hand in something, I thought I may **try** to help.

I don't advocate for GitHub.
I just like to use GitHub for pragmatic reasons.

I do not offer myself to help migrating to OSGeo git/gogs though.

Moving back to the topic:

The dump file will certainly work.
I can import it to local database and use for prototyping
Once the thing works, we can run it based on the original database, I guess.

I assume the attachment files are important part and have to be moved
along the tickets,
so yes, please pack it up all together.

Regards,
Mateusz

On 24 September 2017 at 22:43, Frank Warmerdam <warmerdam@pobox.com> wrote:
Mateusz,

I see that GDAL's trac is backed by a postgres database instance:

database = postgres://postgres@/trac_gdal

Would it be reasonable for me to prepare a database dump of that? I'm
not sure if it is open to direct connects from outside the machine.

I can also tar up the "trac" tree which includes attachment files.

I was amused by:

"Although the feedback is modest so far and any silence means
agreement, GitHub is the preferred choice now."

While I'm not exactly a fan of GDAL tickets moving to github, I am
ironically in the position of fighting to use github at my current
employer (over some internally hosted git thingy) because "developers
already know github". So I suppose I can't really be hater. :slight_smile:

Best regards,
Frank

On Sun, Sep 24, 2017 at 1:18 PM, Mateusz Loskot <mateusz@loskot.net> wrote:

On 24 Sep 2017 22:07, "Harrison Grundy" <harrison.grundy@astrodoggroup.com>
wrote:

If it would help, I have the workflow we used for GeoServer to move to
Atlassian.

I don't know much about Atlassian or how it
Is different to GitHub, but any ideas that
worked for similar to the planned migration
may be useful.

So please share.

Thanks,
Mateusz

_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows |
and watch the world go round - Rush | Geospatial Software Developer
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

--
Mateusz Loskot, http://mateusz.loskot.net
_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

_______________________________________________
Sac mailing list
Sac@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/sac

--
Mateusz Loskot, http://mateusz.loskot.net

12

On Sep 25, 2017, at 3:28 AM, Regina Obe <lr@pcorp.us> wrote:

If Even and rest of GDAL are willing to try gitea/gogs, I'd be willing to do the work of the port.

                Sandro has already done a proof of concept. I would like to see this work.

                I think what we have at stake here is something bigger than GDAL moving.
                It's our trust in the very foundation of SAC and to a larger extent OSGeo and it's usefulness to help with infrastructure support and manage that support.

Ten years ago when OSGeo forming, support from SAC was a differentiator to member projects. Projects needed infrastructure and the cost to maintaining that yourself was quite high. Infrastructure cost is now cheap (free beer!) and SAC as a differentiator is diminished.

In fact, SAC-supported infrastructure now often lag what projects can individually acquire for free due to volunteer resources being limited, etc. The challenges that SAC has as a volunteer endeavor are not unique. PyPI from Python, for example, suffers from a lack of volunteers willing to sign up for pager duty for no pay.

Projects that choose GitHub are not merely doing so in relation to feature-for-feature comparisons to control-your-own-fate Free (tm) solutions. They're doing so because of the network effects of GitHub are now so strong that doing your own thing has a significant opportunity cost.

Take for example the OSGeo login. The barrier to getting that is now so high that one-time casual contribution to a low frequency project is simply not done. One can argue it's necessary too, given the manpower realities of the OSGeo organization. Outsourcing that problem to specialists like GitHub means that spammers and DoS and all that other operational reality of running a service like that is shared and the cost is hidden.

                I'd like to help in restoring that trust. We've got things like maling lists, OSGeo support, and project websites that need a strong SAC. Also tons I'd like to see that could be possible with a stronger SAC.

OSGeo should collect resources and pay specialists to provide needed services to member projects who cannot afford it themselves. When the inevitable day that GitHub goes non-Free (beer), that could mean OSGeo paying those costs. Right now, OSGeo endeavors to be specialists themselves, but it does not have the manpower to sustain them indefinitely on a volunteer basis. Each new crisis prompts a renewal of contribution, but it lasts and dithers until the next crisis kicks off the cycle again.

I think I've migrated GDAL through two generations of project infrastructure (CVS/Bugzilla, Trac/SVN). In my opinion, the continuity of historical artifacts being available on-demand online (instead of in an archive for someone to dig around) is not as important as the convenience and velocity in which the infrastructure enables contribution. Trac/SVN was more convenient and easier to use than self-hosted CVS/Bugzilla. A self-hosted GitHub clone could have feature parity, but it will still be missing key important elements due to GitHub's network effects. If we value enabling the easiest and the most contribution possible, we should ask whether or not rolling our own actually achieves those goals.

Some OSGeo members value free software ideals, and their projects' infrastructure reflects them. Not every OSGeo project needs live those ideals, and it should be up to each project to chose what works best for it.

Howard

13

Ten years ago when OSGeo forming, support from SAC was a differentiator to member projects. Projects needed infrastructure and the cost to maintaining that yourself was quite high. Infrastructure cost is now cheap (free beer!) and SAC as a differentiator is diminished.

In fact, SAC-supported infrastructure now often lag what projects can individually acquire for free due to volunteer resources being limited, etc. The challenges that SAC has as a volunteer endeavor are not unique. PyPI from Python, for example, suffers from a lack of volunteers willing to sign up for pager duty for no pay.

Projects that choose GitHub are not merely doing so in relation to feature-for-feature comparisons to control-your-own-fate Free (tm) solutions. They're doing so because of the network effects of GitHub are now so strong that doing your own thing has a significant opportunity cost.

Take for example the OSGeo login. The barrier to getting that is now so high that one-time casual contribution to a low frequency project is simply not done. One can argue it's necessary too, given the manpower realities of the OSGeo organization. Outsourcing that problem to specialists like GitHub means that spammers and DoS and all that other operational reality of running a service like that is shared and the cost is hidden.

               I'd like to help in restoring that trust. We've got things like maling lists, OSGeo support, and project websites that need a strong SAC. Also tons I'd like to see that could be possible with a stronger SAC.

OSGeo should collect resources and pay specialists to provide needed services to member projects who cannot afford it themselves. When the inevitable day that GitHub goes non-Free (beer), that could mean OSGeo paying those costs. Right now, OSGeo endeavors to be specialists themselves, but it does not have the manpower to sustain them indefinitely on a volunteer basis. Each new crisis prompts a renewal of contribution, but it lasts and dithers until the next crisis kicks off the cycle again.

I think I've migrated GDAL through two generations of project infrastructure (CVS/Bugzilla, Trac/SVN). In my opinion, the continuity of historical artifacts being available on-demand online (instead of in an archive for someone to dig around) is not as important as the convenience and velocity in which the infrastructure enables contribution. Trac/SVN was more convenient and easier to use than self-hosted CVS/Bugzilla. A self-hosted GitHub clone could have feature parity, but it will still be missing key important elements due to GitHub's network effects. If we value enabling the easiest and the most contribution possible, we should ask whether or not rolling our own actually achieves those goals.

Some OSGeo members value free software ideals, and their projects' infrastructure reflects them. Not every OSGeo project needs live those ideals, and it should be up to each project to chose what works best

I think SAC can be a significant asset for the member projects by mitigating the risk in things like GitHub. If we were to develop an automated way to clone things like the projects' GH repos, issues, etc. it would allow the member projects to take advantage of these services, knowing that they cannot end up stuck in a dead end simply because someone else's business model didn't pan out.

One of the biggest things I've noticed with SAC that tends to consume a great deal of time is how much manual work is required to get from one point to another. From the time we have to spend making LDAP accounts, to managing our infrastructure on the various VM hosts... the vast majority of SAC's time is spent performing tasks that largely tread water. (strk, you're repeatedly saving our bacon with these, thanks!)

I think it's worth sitting down and figuring out which services can we offer to member projects that are difficult to handle themselves (Automated builds for various platforms comes to mind) but that don't require constant intervention by SAC to keep running.

At the same time, we need to take a close look at the services we're offering and figure out what needs to be done to reduce their administrative footprint. We don't do the member projects any good by overcommitting ourselves to things we don't have time to do well. (Something I'm incredibly guilty of myself.)

Let's set up a time to discuss this and what everyone sees SAC's role as being in the future, along with what we need to accomplish that.

Harrison

14

I think SAC can be a significant asset for the member projects by mitigating

the risk in things like GitHub. If we were to develop an automated way to

clone things like the projects’ GH repos, issues, etc. it would allow the

member projects to take advantage of these services, knowing that they

cannot end up stuck in a dead end simply because someone else’s business

model didn’t pan out.

There are tools you can use to do that

https://github.com/josegonzalez/python-github-backup

See https://lists.osgeo.org/pipermail/gdal-dev/2017-September/047060.html for more details

Mostly you need to setup a cron job invoking the tool to do ingestion of new GH tickets and pull requests (backuping up the code itself is probably not even needed given how git works). With normal rate of activity, it should run in a few seconds in incremental mode, once you’ve done the initial import.

It would be my intent to set up one on my PC if/once we have migrated to GH, but would indeed makes sense to run on a OSGeo server for several projects that have already gone through the full GH way (thinking to mapserver, proj.4, openlayers, etc…)

I also found that GitLab has a functionnality to migrate from GitHub

https://docs.gitlab.com/ce/user/project/import/github.html

which could be used as an exit road if/when things turn bad.

Even

–

Spatialys - Geospatial professional services

http://www.spatialys.com

15

On Mon, Sep 25, 2017 at 11:50:09AM -0500, Howard Butler wrote:

When the inevitable day that GitHub goes non-Free (beer), that could
mean OSGeo paying those costs.

Isn't that the exact definition of vendor lock-in ?
With this future in mind it would make more sense to be on gitlab.com,
at least that day it will be possible to deploy back to own infra.

should be up to each project to chose what works best for it.

Agreed.

--strk;

16

On Mon, Sep 25, 2017 at 01:19:47PM -0500, Harrison Grundy wrote:

If we were to develop an automated way to clone things like the
projects' GH repos, issues, etc. it would allow the member projects to
take advantage of these services, knowing that they cannot end up stuck
in a dead end simply because someone else's business model didn't pan out.

Both the current experimental Gogs and GitLab deploys already support
mirroring the code (by polling, periodically).

Tickets cloning/sync is not available out-of-the-box, but I'm not sure
how it would work (tickets would need to be read-only).

We don't do the member projects any good by overcommitting ourselves
to things we don't have time to do well. (Something I'm incredibly guilty
of myself.)

Eh, I'm glad you recognize that. I was putting lots of hope in
your taking charge of Wiki/LDAP integration...

Let's set up a time to discuss this and what everyone sees SAC's role
as being in the future, along with what we need to accomplish that.

I've called for a meeting in September 2016 [1] but that call
remained unanswered. Should we try again ? Please start a new
thread calling for a meeting, I'll do my best to be there.

[1] https://lists.osgeo.org/pipermail/sac/2016-September/007419.html

--strk;