Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-19 Thread Paolo Cavallini
Il 18/10/2015 12:34, Angelos Tzotsos ha scritto:

> I see the benefits that Andrea mentioned, and I believe that even if the
> official OSGeoLive copy moves back to OSGeo infrastructure, we will
> probably keep a copy on GitHub for project visibility and for accepting
> pull requests... Lets keep in mind that Linux kernel project is doing
> exactly the same: they host the kernel code under kernel.org and have a
> copy on GitHub as a backup.

This makes sense to me. Looks simmple and effective, not disrupting
workflow for exixting projects.

> It is true that GitHub is not Free Software, so IMO we should not be
> depending on it. I see the ethical issues that arise from using a non
> Free provider

+1

Thanks.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-19 Thread Mateusz Loskot
On 18 October 2015 at 11:53, Paragon Corporation  wrote:
>
> Many of them would prefer OSGEO hosting (and preferably git over svn)
> because why force someone to get a github account just to put in a bug
> report or submit a patch.

Such barrier for ad-hoc contributors, not only on GitHub but our Trac too,
could potentially be removed by allowing a hybrid authentication
(i.e. sign in to Trac w/ your existing account on other social services),
if Trac provides support for that.

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-19 Thread Sandro Santilli
On Sun, Oct 18, 2015 at 03:04:06PM -0700, Jody Garnett wrote:

> Aside: Please make sure your GitHub repository has a CONTRIBUTING.md
>  file or similar if
> you are accepting pull requests from the big bad internet.

Thanks for the suggestion, done (for PostGIS):
 https://trac.osgeo.org/postgis/changeset/14290

--strk;
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-19 Thread Sandro Santilli
On Mon, Oct 19, 2015 at 02:58:26PM +0200, Mateusz Loskot wrote:
> On 18 October 2015 at 11:53, Paragon Corporation  wrote:
> >
> > Many of them would prefer OSGEO hosting (and preferably git over svn)
> > because why force someone to get a github account just to put in a bug
> > report or submit a patch.
> 
> Such barrier for ad-hoc contributors, not only on GitHub but our Trac too,
> could potentially be removed by allowing a hybrid authentication
> (i.e. sign in to Trac w/ your existing account on other social services),
> if Trac provides support for that.

+1, might be an interesting feature to evaluate.
I'd love OpenID support, for example...

I guess then we'll need a way to blacklist accounts if they are found
to be just spam accounts.

--strk;
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-19 Thread Angelos Tzotsos


On 10/18/2015 10:37 PM, Andreas Hocevar wrote:

On 18 Oct 2015, at 12:34, Angelos Tzotsos  wrote:

It is true that GitHub is not Free Software, so IMO we should not be depending 
on it. I see the ethical issues that arise from using a non Free provider and 
it is not the only case in our ecosystem eg. Transifex used to be Free Software 
and it is not anymore:

This is quite an inaccurate statement, and a different story too. You could 
still go to https://github.com/transifex/transifex, clone the repo, set up a 
Transifex instance on your server, or even continue developing it. It's GPL 
licensed after all.

  


OK, let me rephrase that: transifex.com is not Free Software any more...

Best,
Angelos

--
Angelos Tzotsos, PhD
OSGeo Charter Member
http://users.ntua.gr/tzotsos

___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread Andreas Hocevar

> On 18 Oct 2015, at 12:34, Angelos Tzotsos  wrote:
> 
> It is true that GitHub is not Free Software, so IMO we should not be 
> depending on it. I see the ethical issues that arise from using a non Free 
> provider and it is not the only case in our ecosystem eg. Transifex used to 
> be Free Software and it is not anymore:

This is quite an inaccurate statement, and a different story too. You could 
still go to https://github.com/transifex/transifex, clone the repo, set up a 
Transifex instance on your server, or even continue developing it. It's GPL 
licensed after all.

But that's not my point. My point is:

git is free and open source. GitHub "just" adds (tons of) convenience on top of 
it. Github going away is just as (un)likely as OSGeo going away. If that 
happens, with git being a distributed versioning system, developers will still 
be able to push their local clones to some other infrastructure. Doing so is a 
matter of 1 minute.

Andreas. 
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread David Fawcett
One thing to consider in using GitHub is the opportunity for the project to
be discovered by people who are not aware of OSGEO and the geo space.

David.

On Sun, Oct 18, 2015 at 2:37 PM, Andreas Hocevar 
wrote:

>
> > On 18 Oct 2015, at 12:34, Angelos Tzotsos  wrote:
> >
> > It is true that GitHub is not Free Software, so IMO we should not be
> depending on it. I see the ethical issues that arise from using a non Free
> provider and it is not the only case in our ecosystem eg. Transifex used to
> be Free Software and it is not anymore:
>
> This is quite an inaccurate statement, and a different story too. You
> could still go to https://github.com/transifex/transifex, clone the repo,
> set up a Transifex instance on your server, or even continue developing it.
> It's GPL licensed after all.
>
> But that's not my point. My point is:
>
> git is free and open source. GitHub "just" adds (tons of) convenience on
> top of it. Github going away is just as (un)likely as OSGeo going away. If
> that happens, with git being a distributed versioning system, developers
> will still be able to push their local clones to some other infrastructure.
> Doing so is a matter of 1 minute.
>
> Andreas.
> ___
> Discuss mailing list
> Discuss@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread Jody Garnett
That repo-criteria articles is a great read - thanks!

One key advantage OSGeo has as a foundation is we are not "picky" about
where projects work from. This allows our projects to be more responsive
then similar foundations such as Apache and Eclipse. It should be noted
that these organizations require the use of their own for facilities for
reasons other than hosting (Apache wants to have a "kill switch" on
downloads and source code if any legal challenge is issued to mitigate any
damages payed out, Eclipse Foundation quite sensibly wants to have a copy
of the code incase the external forge goes down so the team does not lose
their work).

As for OSGeo we are pretty relaxed - I think the only thing we would be
actively worried about is a project hosted by a corporate CSV or similar
(since we like our projects to be vendor neutral). Before OSGeo was founded
we suffered when Refractions SVN was corrupted.

Personally I would like to ensure "we" have a copy of the code incase a
projects infrastructure goes down (example CodeHaus, Source Forge). Right
now we depend on individual committers to have a copy.

I want to be cautious of asking the board to make decisions affecting the
system admin committee.  I would prefer projects such as PostGIS negotiate
with the SAC directly (as they are in a much better position to determine
requirements/solution). The Board can be told of the plan of course, but we
need to trust our subcommittees and respect our volunteers (Indeed Regina
Obe's email backs up my feelings on this matter).

There is a balance between OSGeo branding (we could purchase GitHub
Enterprise and hook into our LDAP for example) and developer outreach
(allowing developers to work with the github account they already have
setup). I think we should keep an eye on it as GitHub popularity will
change over time just like Source Forge before it. At the time of writing I
would recommend all projects at least have a mirror on GitHub as an
outreach activity.

Aside: Please make sure your GitHub repository has a CONTRIBUTING.md
 file or similar if
you are accepting pull requests from the big bad internet.
--
Jody


--
Jody Garnett

On 18 October 2015 at 00:07, Andreas Hocevar 
wrote:

> Very well said Andrea, and I can back this up with very similar
> experiences from when the OpenLayers project moved to Github.
>
> That said, if OSGeo considers setting up a Git infrastructure, please keep
> an alternative in mind: pay for an OSGeo Github account for projects that
> want to use Git. Will burn some money, but won't burn out volunteers who
> have to keep OSGeo's own infrastructure up and running. See
> https://github.com/locationtech as an example.
>
> Andreas.
>
> On 18 Oct 2015, at 08:41, Andrea Aime 
> wrote:
>
> Hi,
> just wanted to chime in saying that if OSGeo starts setting said
> guidelines,
> it should also have some benefits comparison so that projects can
> see what they might not get by avoiding Github.
>
> In particular, looking at GeoServer experience from the switch, it's rather
> evident we got more people contributing right the moment we did the
> switch, here is the contributors per month diagram, the red line
> is the date we switched from svn to GitHub:
>
> 
>
>
> Most of this is due to two factors:
> - availability of pull requests (which I believe you can get with other
> tools too)
> - critical mass on the platform (which arguably you will not get an a
> OsGeo hosting)
>
> There is however a downside of that, most of these contributions are "one
> time gigs",
> people help addressing the particular pitfall concerning them and then
> they move on:
> github did not change the number of core developers, it just increased a
> lot the
> number of other contributors.
>
> There is another benefit of moving to Github, which is build checks on
> pull requests,
> we now have Travis (Linux, OSX) building all pull requests and running the
> test suite against
> them, so we instantly know if the change breaks tests or not, and we
> planning on adding
> test coverage checks (Coveralls, already used by OpenLayers for example)
> and Windows builds
> (already used by MapServer for example).
>
> This kind of automation is also rather beneficial to filter our bad
> contributions... which is
> the dark side of lower contribution barrier, core devs have to spend quite
> some time evaluating
> pull requests... but ending up with a long queue of them gives a bad
> impression about the project
> openness. So yeah, another bit to consider I guess, is the project ready
> to take on them?
>
> So I'm not saying "everybody move to github" but I believe the above
> should be
> part of the many considerations made when evaluating a move to a different
> version control.
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread Andrea Aime
On Sun, Oct 18, 2015 at 12:08 PM, Sandro Santilli  wrote:

> How does that diagram counts contributors ?
>
> With SVN it's very unlikely that a bot can recognize contributors
> other than the committers, while with GIT it's easier to make the
> actual contributor visible to a machine (being there an "author"
> field in addition to the "committer" field).
>

Indeed, it counts the committers, and it's true that it can be skewed,
but I assure you the overall effect is negligible.

Before pull requests we used to add a "patch by xyz" in the commit
message to give credit to the actual author. I looked at the year right
before the github switch, there are 4 commits like that in total (I searched
for just "by" to make sure not to skip stuff written with slight
differences).

If I look at the last year and ask for a contributor count I get:

> git shortlog -nsu --since "one year ago" | wc -l
84

Github tells me there are 34 developers with direct commit access, but I
checked
who made a commit in the last year. we are down to only 24 people.
Sometimes devs commit from another computer and
they don't have their mail setup, which makes for a two lines in that
statistic,
one with the username, one with the mail
e.g. in that list we have for example Mauro listed twice (and so is mine):
27  Mauro Bartolomeoli
24  mbarto

So that reduces the number of actual unique contributorsq a bit, let's say
down to 75-80...
it's still 50 random people contributing to GeoServer without commit access
in the last year, or, in other words, 10 times more external contributions
compared to before the switch to Github.

The thing is, we still have patches in the bug tracker that are a few years
old, and they will likely never be merged: when they came in they probably
were either dirty, or core devs were too busy, and after a few months
applying them becomes rather challenging, so there they stay: the merge
barrier
was too high, too domanding on the core devs.

With the current pull request mechanism we have a much improved ability
to handle contributions, in part because people are reminded of the
contribution rules the moment they make the pull request, in part because
the build servers inform the submitter about a problem in the pull request
rather quickly,
but also because we can comment in a more social way about the pull
request (before reviewing the patch was a one man job), and also because
they
are always nicely grouped and in front of our eyes at every PSC meeting
(we check the pull request queue like that every two weeks, to see
if there is anything that merits special attention).


>
> I'm not trying to negate the possible benefits in terms of number
> of contributors, but I'd be careful about the correctess of available
> data.
>
> > There is another benefit of moving to Github, which is build checks on
> pull
> > requests,
>
> Yes, this is something we unfortunately lost on OSGeo.
> We used to have buildbot running to that extent, but lack of volunteers
> made that experience come to an end.
>

Mind, here I'm talking about a special integration, not the normal
continuous build for commits that are integrated, but a custom build for the
pull request, which tells you whether or not merging that pull request
will break the build (to clarify, by build I mean both compiling and running
all automated tests save for OGC CITE compliance ones).

The pull request build status, along with an indication if the patch is
mergeable, and possibly an indication
of whether the test coverage went up or down, is a huge time saver.
If a review of the patch is satisfying, the build give us the green, we can
literally
just press the merge button, thank the contributor, and move on with our
work/live,
instead of spending time trying to apply while the code moved, build, go
back and forth
with the committer in a rather inefficient way (and manually run
build/tests every damn time), and so on.

Cheers
Andrea


-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce 

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread Sandro Santilli
On Sat, Oct 17, 2015 at 10:22:10PM +0200, Mateusz Loskot wrote:

> Once Sandro has completed setting up git.osgeo.org infrastructure, who
> is going to maintain it?

Just a note: I'm not going to setup git.osgeo.org infrastructure
against the will of OSGeo board.
So far all I'm doing is feasibility research.

--strk;
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread Sandro Santilli
On Sun, Oct 18, 2015 at 08:41:12AM +0200, Andrea Aime wrote:

> In particular, looking at GeoServer experience from the switch, it's rather
> evident we got more people contributing right the moment we did the
> switch, here is the contributors per month diagram, the red line
> is the date we switched from svn to GitHub:

How does that diagram counts contributors ?

With SVN it's very unlikely that a bot can recognize contributors
other than the committers, while with GIT it's easier to make the
actual contributor visible to a machine (being there an "author"
field in addition to the "committer" field).

I'm not trying to negate the possible benefits in terms of number
of contributors, but I'd be careful about the correctess of available
data.

> There is another benefit of moving to Github, which is build checks on pull
> requests,

Yes, this is something we unfortunately lost on OSGeo.
We used to have buildbot running to that extent, but lack of volunteers
made that experience come to an end.

--strk;
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread Andrea Aime
Hi,
just wanted to chime in saying that if OSGeo starts setting said guidelines,
it should also have some benefits comparison so that projects can
see what they might not get by avoiding Github.

In particular, looking at GeoServer experience from the switch, it's rather
evident we got more people contributing right the moment we did the
switch, here is the contributors per month diagram, the red line
is the date we switched from svn to GitHub:

[image: Inline image 1]


Most of this is due to two factors:
- availability of pull requests (which I believe you can get with other
tools too)
- critical mass on the platform (which arguably you will not get an a OsGeo
hosting)

There is however a downside of that, most of these contributions are "one
time gigs",
people help addressing the particular pitfall concerning them and then they
move on:
github did not change the number of core developers, it just increased a
lot the
number of other contributors.

There is another benefit of moving to Github, which is build checks on pull
requests,
we now have Travis (Linux, OSX) building all pull requests and running the
test suite against
them, so we instantly know if the change breaks tests or not, and we
planning on adding
test coverage checks (Coveralls, already used by OpenLayers for example)
and Windows builds
(already used by MapServer for example).

This kind of automation is also rather beneficial to filter our bad
contributions... which is
the dark side of lower contribution barrier, core devs have to spend quite
some time evaluating
pull requests... but ending up with a long queue of them gives a bad
impression about the project
openness. So yeah, another bit to consider I guess, is the project ready to
take on them?

So I'm not saying "everybody move to github" but I believe the above
should be
part of the many considerations made when evaluating a move to a different
version control.

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

---
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread Paragon Corporation
A lot of what instigated this conversation is what PostGIS should do? stick 
with SVN/Trac, get rid of SVN and just move everything to GitHub, or have an 
OSGeo GIT and a GitHub mirror and still keep trac.

I don't think it makes sense for us to completely ditch github, but then I also 
think there is a downside to having github as our official repo.

 

Right now PostGIS is mirroring our svn repo to GitHub and we get enough pull 
requests from users, sometimes even big patches.  So I think having a mirror on 
GitHub takes care of that. It's a bit extra effort to accept the pulls, but 
that may be a good thing as it forces us to scrutinize more.  So we get the 
benefit of travis testing etc already.

 

However I also care about package maintainers since to me they are the life and 
blood of PostGIS.  They insure that new users have an easy time installing 
postgresql / postgis.

Many of them would prefer OSGEO hosting (and preferably git over svn)  because 
why force someone to get a github account just to put in a bug report or submit 
a patch.  If they should be forced to create an account with a  faceless 
organization, it should be OSGeo :), not github.

 

Relevant notes from Package maintainers:

https://lists.osgeo.org/pipermail/postgis-devel/2015-October/025361.html

 

https://lists.osgeo.org/pipermail/postgis-devel/2015-October/025359.html

 

 

We also have a lot of users who just report bugs.  I'm not so sure they have 
github accounts or care to. Bug reports are more important to me than new 
contributions as every new contribution requires some level of stress testing.

 

Thanks,

Regina Obe

PostGIS PSC member

Windows PostGIS Stackbuilder Maintainer

 

 

From: Discuss [mailto:discuss-boun...@lists.osgeo.org] On Behalf Of Andreas 
Hocevar
Sent: Sunday, October 18, 2015 3:08 AM
To: OSGeo Discussions <discuss@lists.osgeo.org>
Subject: Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

 

Very well said Andrea, and I can back this up with very similar experiences 
from when the OpenLayers project moved to Github.

 

That said, if OSGeo considers setting up a Git infrastructure, please keep an 
alternative in mind: pay for an OSGeo Github account for projects that want to 
use Git. Will burn some money, but won't burn out volunteers who have to keep 
OSGeo's own infrastructure up and running. See https://github.com/locationtech 
as an example.

 

Andreas.

 

On 18 Oct 2015, at 08:41, Andrea Aime <andrea.a...@geo-solutions.it 
<mailto:andrea.a...@geo-solutions.it> > wrote:

 

Hi,

just wanted to chime in saying that if OSGeo starts setting said guidelines,

it should also have some benefits comparison so that projects can

see what they might not get by avoiding Github.

 

In particular, looking at GeoServer experience from the switch, it's rather

evident we got more people contributing right the moment we did the

switch, here is the contributors per month diagram, the red line

is the date we switched from svn to GitHub:

 



 

 

Most of this is due to two factors:

- availability of pull requests (which I believe you can get with other tools 
too)

- critical mass on the platform (which arguably you will not get an a OsGeo 
hosting)

 

There is however a downside of that, most of these contributions are "one time 
gigs",

people help addressing the particular pitfall concerning them and then they 
move on:

github did not change the number of core developers, it just increased a lot the

number of other contributors.

 

There is another benefit of moving to Github, which is build checks on pull 
requests,

we now have Travis (Linux, OSX) building all pull requests and running the test 
suite against

them, so we instantly know if the change breaks tests or not, and we planning 
on adding

test coverage checks (Coveralls, already used by OpenLayers for example) and 
Windows builds 

(already used by MapServer for example).

 

This kind of automation is also rather beneficial to filter our bad 
contributions... which is

the dark side of lower contribution barrier, core devs have to spend quite some 
time evaluating

pull requests... but ending up with a long queue of them gives a bad impression 
about the project

openness. So yeah, another bit to consider I guess, is the project ready to 
take on them?

 

So I'm not saying "everybody move to github" but I believe the above should 
be

part of the many considerations made when evaluating a move to a different 
version control.

 

Cheers

Andrea

 

-- 

==

GeoServer Professional Services from the experts! Visit

http://goo.gl/it488V for more information.

==

 

Ing. Andrea Aime 

@geowolf

Technical Lead

 

GeoSolutions S.A.S.

Via Poggio alle Viti 1187

55054  Massarosa (LU)

Italy

phone: +39 0584 962313 <tel:%2B39%200584%20962313> 

fax: +39 0584 1660272 <tel:%2B39%200584%201660272> 

mob: +39  <tel:%2B39%20%C2%A0339%208844549>  339 8844549

 

http://ww

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread Andreas Hocevar
Very well said Andrea, and I can back this up with very similar experiences 
from when the OpenLayers project moved to Github.

That said, if OSGeo considers setting up a Git infrastructure, please keep an 
alternative in mind: pay for an OSGeo Github account for projects that want to 
use Git. Will burn some money, but won't burn out volunteers who have to keep 
OSGeo's own infrastructure up and running. See https://github.com/locationtech 
as an example.

Andreas.

> On 18 Oct 2015, at 08:41, Andrea Aime  wrote:
> 
> Hi,
> just wanted to chime in saying that if OSGeo starts setting said guidelines,
> it should also have some benefits comparison so that projects can
> see what they might not get by avoiding Github.
> 
> In particular, looking at GeoServer experience from the switch, it's rather
> evident we got more people contributing right the moment we did the
> switch, here is the contributors per month diagram, the red line
> is the date we switched from svn to GitHub:
> 
> 
> 
> 
> Most of this is due to two factors:
> - availability of pull requests (which I believe you can get with other tools 
> too)
> - critical mass on the platform (which arguably you will not get an a OsGeo 
> hosting)
> 
> There is however a downside of that, most of these contributions are "one 
> time gigs",
> people help addressing the particular pitfall concerning them and then they 
> move on:
> github did not change the number of core developers, it just increased a lot 
> the
> number of other contributors.
> 
> There is another benefit of moving to Github, which is build checks on pull 
> requests,
> we now have Travis (Linux, OSX) building all pull requests and running the 
> test suite against
> them, so we instantly know if the change breaks tests or not, and we planning 
> on adding
> test coverage checks (Coveralls, already used by OpenLayers for example) and 
> Windows builds 
> (already used by MapServer for example).
> 
> This kind of automation is also rather beneficial to filter our bad 
> contributions... which is
> the dark side of lower contribution barrier, core devs have to spend quite 
> some time evaluating
> pull requests... but ending up with a long queue of them gives a bad 
> impression about the project
> openness. So yeah, another bit to consider I guess, is the project ready to 
> take on them?
> 
> So I'm not saying "everybody move to github" but I believe the above 
> should be
> part of the many considerations made when evaluating a move to a different 
> version control.
> 
> Cheers
> Andrea
> 
> -- 
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V  for more information.
> ==
> 
> Ing. Andrea Aime 
> @geowolf
> Technical Lead
> 
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313 
> fax: +39 0584 1660272 
> mob: +39  339 8844549 
> 
> http://www.geo-solutions.it 
> http://twitter.com/geosolutions_it 
> 
> AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
> 
> Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i 
> file/s allegato/i sono da considerarsi strettamente riservate. Il loro 
> utilizzo è consentito esclusivamente al destinatario del messaggio, per le 
> finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio 
> senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia 
> via e-mail e di procedere alla distruzione del messaggio stesso, 
> cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo 
> anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per 
> finalità diverse, costituisce comportamento contrario ai principi dettati dal 
> D.Lgs. 196/2003.
> 
>  
> The information in this message and/or attachments, is intended solely for 
> the attention and use of the named addressee(s) and may be confidential or 
> proprietary in nature or covered by the provisions of privacy act 
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection 
> Code).Any use not in accord with its purpose, any disclosure, reproduction, 
> copying, distribution, or either dissemination, either whole or partial, is 
> strictly forbidden except previous formal approval of the named addressee(s). 
> If you are not the intended recipient, please contact immediately the sender 
> by telephone, fax or e-mail and delete the information in this message that 
> has been received in error. The sender does not give any warranty or accept 
> liability as the content, accuracy or completeness of sent messages and 
> accepts no responsibility  for changes made after they were sent or for other 
> risks which arise as a result of e-mail transmission, viruses, etc.
> 
> 
> 

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread Sandro Santilli
On Sun, Oct 18, 2015 at 09:07:52AM +0200, Andreas Hocevar wrote:

> please keep an alternative in mind: pay for an OSGeo Github account for
> projects that want to use Git. Will burn some money, but won't burn out
> volunteers who have to keep OSGeo's own infrastructure up and running. See
> https://github.com/locationtech as an example.

Please keep another alternative in mind: pay OSGeo system administrators.

Will burn some money, but won't burn out volunteers who have to keep
OSGeo's own infrastructure up and running.

Even if I understand that the cost for OSGeo sysadmins might be higher
than the cost for a GitHub account, I can also see that the money
spent on SAC might result in indirect benefit for free software tools
(I'm sure SAC people do file tickets for the tools they use) while
those spent on GitHub could only result in benefit for the proprietary
software used to run that service.

--strk;
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread Michael Smith
I very much like the idea of paying SAC administrators for all the great
work they do. And setting up an OSGeo git infrastructure (git+trac,
gitlab, or ???) is right in line with our mission statement of our
foundation. 

I'm enjoying where this discussion is going. I don't think we have settled
on a consensus yet but the conversion is very enlightening.

Mike


Michael Smith
OSGeo Foundation Treasurer
treasu...@osgeo.org





-Original Message-
From: Discuss <discuss-boun...@lists.osgeo.org> on behalf of Sandro
Santilli <s...@keybit.net>
Date: Sunday, October 18, 2015 at 6:18 AM
To: Andreas Hocevar <andreas.hoce...@gmail.com>
Cc: OSGeo Discussions <discuss@lists.osgeo.org>
Subject: [EXTERNAL] Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?
Resent-From: Michael Smith <michael.sm...@usace.army.mil>

>On Sun, Oct 18, 2015 at 09:07:52AM +0200, Andreas Hocevar wrote:
>
>> please keep an alternative in mind: pay for an OSGeo Github account for
>> projects that want to use Git. Will burn some money, but won't burn out
>> volunteers who have to keep OSGeo's own infrastructure up and running.
>>See
>> BlockedBlockedhttps://github.com/locationtechBlocked as an example.
>
>Please keep another alternative in mind: pay OSGeo system administrators.
>
>Will burn some money, but won't burn out volunteers who have to keep
>OSGeo's own infrastructure up and running.
>
>Even if I understand that the cost for OSGeo sysadmins might be higher
>than the cost for a GitHub account, I can also see that the money
>spent on SAC might result in indirect benefit for free software tools
>(I'm sure SAC people do file tickets for the tools they use) while
>those spent on GitHub could only result in benefit for the proprietary
>software used to run that service.
>
>--strk;
>___
>Discuss mailing list
>Discuss@lists.osgeo.org
>BlockedBlockedhttp://lists.osgeo.org/mailman/listinfo/discussBlocked


___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread Angelos Tzotsos

Hi Andreas,

There is already an OSGeo account on GitHub, managed by SAC members:
https://github.com/OSGeo

This discussion started 6 months ago on IRC, during the OSGeoLive 
transition to Git.
Since there was no git.osgeo.org setup at the time, we decided to 
temporarily host OSGeoLive git repository there, waiting for an official 
OSGeo hosting option. We are still using OSGeo Trac as a ticketing system.


I see the benefits that Andrea mentioned, and I believe that even if the 
official OSGeoLive copy moves back to OSGeo infrastructure, we will 
probably keep a copy on GitHub for project visibility and for accepting 
pull requests... Lets keep in mind that Linux kernel project is doing 
exactly the same: they host the kernel code under kernel.org and have a 
copy on GitHub as a backup. Actually this kept the kernel work going, 
when kernel.org faced some serious downtime 4 years ago:


https://lkml.org/lkml/2011/9/4/92

It is true that GitHub is not Free Software, so IMO we should not be 
depending on it. I see the ethical issues that arise from using a non 
Free provider and it is not the only case in our ecosystem eg. Transifex 
used to be Free Software and it is not anymore:


https://github.com/transifex/transifex/issues/206
https://github.com/tymofij/transifex/pull/1#issuecomment-14206884

Best,
Angelos


On 10/18/2015 10:07 AM, Andreas Hocevar wrote:

Very well said Andrea, and I can back this up with very similar experiences 
from when the OpenLayers project moved to Github.

That said, if OSGeo considers setting up a Git infrastructure, please keep an 
alternative in mind: pay for an OSGeo Github account for projects that want to 
use Git. Will burn some money, but won't burn out volunteers who have to keep 
OSGeo's own infrastructure up and running. See https://github.com/locationtech 
as an example.

Andreas.


On 18 Oct 2015, at 08:41, Andrea Aime  wrote:

Hi,
just wanted to chime in saying that if OSGeo starts setting said guidelines,
it should also have some benefits comparison so that projects can
see what they might not get by avoiding Github.

In particular, looking at GeoServer experience from the switch, it's rather
evident we got more people contributing right the moment we did the
switch, here is the contributors per month diagram, the red line
is the date we switched from svn to GitHub:




Most of this is due to two factors:
- availability of pull requests (which I believe you can get with other tools 
too)
- critical mass on the platform (which arguably you will not get an a OsGeo 
hosting)

There is however a downside of that, most of these contributions are "one time 
gigs",
people help addressing the particular pitfall concerning them and then they 
move on:
github did not change the number of core developers, it just increased a lot the
number of other contributors.

There is another benefit of moving to Github, which is build checks on pull 
requests,
we now have Travis (Linux, OSX) building all pull requests and running the test 
suite against
them, so we instantly know if the change breaks tests or not, and we planning 
on adding
test coverage checks (Coveralls, already used by OpenLayers for example) and 
Windows builds
(already used by MapServer for example).

This kind of automation is also rather beneficial to filter our bad 
contributions... which is
the dark side of lower contribution barrier, core devs have to spend quite some 
time evaluating
pull requests... but ending up with a long queue of them gives a bad impression 
about the project
openness. So yeah, another bit to consider I guess, is the project ready to 
take on them?

So I'm not saying "everybody move to github" but I believe the above should 
be
part of the many considerations made when evaluating a move to a different 
version control.

Cheers
Andrea

--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V  for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313 
fax: +39 0584 1660272 
mob: +39  339 8844549 

http://www.geo-solutions.it 
http://twitter.com/geosolutions_it 

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i 
file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo 
è consentito esclusivamente al destinatario del messaggio, per le finalità 
indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne 
il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di 
procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro 
sistema. Conservare il messaggio stesso, divulgarlo anche in parte, 
distribuirlo ad 

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread Sandro Santilli
On Sun, Oct 18, 2015 at 01:34:57PM +0300, Angelos Tzotsos wrote:

> It is true that GitHub is not Free Software, so IMO we should not be
> depending on it. I see the ethical issues that arise from using a
> non Free provider and it is not the only case in our ecosystem eg.
> Transifex used to be Free Software and it is not anymore:
> 
> https://github.com/transifex/transifex/issues/206
> https://github.com/tymofij/transifex/pull/1#issuecomment-14206884

Thanks for the pointers, Angelos.
I think this shows pretty clearly what the risk is when relying
on external services. Transifex was GPL at the time we decided
to move the code there. I hoped OSGeo would setup a translation
infrastructure back then too (~2012) but nothing came out of it:
https://lists.osgeo.org/pipermail/postgis-devel/2012-October/022234.html

Now the cost of that choice would be that of asking all translators
to create new accounts elsewhere, if we want to move away of
transifex.com:
https://trac.osgeo.org/postgis/ticket/3339

--strk;
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread Markus Neteler
On Sat, Oct 17, 2015 at 12:10 PM, Mateusz Loskot  wrote:
...
> Finally, with Sandro, we brainstormed idea of surveing the Community
> about their hosting needs/preferences.
> Sandro, Martin, Alex, have been putting efforts into setting up Git,
> improving Trac, and overall improvements.
> Those efforts might be wasted, in case projects will move to GitHub.

There are also projects which do not plan at all to move to git/GitHub.
Or those who just use GitHub as a mirror of their SVN repo.

Markus
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-18 Thread Mateusz Loskot
On 18 October 2015 at 08:41, Andrea Aime  wrote:
>
> In particular, looking at GeoServer experience from the switch, it's rather
> evident we got more people contributing right the moment we did the
> switch
> [...]
> There is however a downside of that, most of these contributions are "one 
> time gigs",
> people help addressing the particular pitfall concerning them and then they 
> move on:
> github did not change the number of core developers, it just increased a lot 
> the
> number of other contributors.
>
> This kind of automation is also rather beneficial to filter our bad 
> contributions... which is
> the dark side of lower contribution barrier, core devs have to spend quite 
> some time evaluating
> pull requests... but ending up with a long queue of them gives a bad 
> impression about the project
> openness. So yeah, another bit to consider I guess, is the project ready to 
> take on them?

I can confirm Andrea's observations.
I have observed very similar trends since moving one of OSS projects
from SourceForge to GitHub.
From an ad-hoc contributor POV, the SourceForge infrastructure was
unfriendly, badly designed,
with lack of proper UX approach. Switch to the "awesome UX" platform
like GitHub released
those dormant potential.

The new benefits introduced new costs in peer reviews and maintenance.

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-17 Thread Mateusz Loskot
On 17 October 2015 at 10:22, Sandro Santilli  wrote:
> Given the number of OSGeo projects that are moving their code outside
> of OSGeo infrastructure, Mateusz Loskot on IRC suggested to include
> guidelines about what is or ins't accepted as a code repository
> hosting for OSGeo projects.

To clraify, the suggestion was inspired by this article and
what Eclise Foundation proposed in their FAQ:
http://redmonk.com/sogrady/2013/06/20/eclipse-github/

Typical incubation questionnaire asks something like this:

"If you do not intend to host any portion of this project using the OSGeo
infrastructure, why should you be considered a member project..."

So, perhaps it would be better to clarify hosting
freedoms/requirements in advance.

> Of course the ethical criteria is orthogonal to the strategic
> arguments about having code hosted on or off OSGeo infrastructure.

Also, as the latest discussion about GitHub revealed, there is number of
practical features that make hosting alternatives more attractive.

Finally, with Sandro, we brainstormed idea of surveing the Community
about their hosting needs/preferences.
Sandro, Martin, Alex, have been putting efforts into setting up Git,
improving Trac, and overall improvements.
Those efforts might be wasted, in case projects will move to GitHub.

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

[OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-17 Thread Sandro Santilli
Given the number of OSGeo projects that are moving their code outside
of OSGeo infrastructure, Mateusz Loskot on IRC suggested to include
guidelines about what is or ins't accepted as a code repository
hosting for OSGeo projects.

An example of a similar guideline is the recent document published by
the FSF about the criteria to consider a code hosting repository
acceptable for a GNU project:

 https://www.gnu.org/software/repo-criteria.html

That document identifies different ethical levels,
from acceptable to use to excellent.

The acceptable level focuses on the usability of the hosting site
with only free software tools. I hadn't made the excercise of trying
github against those requirements (as the definition includes
disabling javascript unless it is also free software, which I dubt
is the case with GitHub), but chances are it *might* be considered
acceptable.

Of course the ethical criteria is orthogonal to the strategic
arguments about having code hosted on or off OSGeo infrastructure.

--strk; 
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-17 Thread Sandro Santilli
On Sat, Oct 17, 2015 at 05:06:54PM +0200, Anita Graser wrote:
> On Oct 17, 2015 12:10 PM, "Mateusz Loskot"  wrote:
> > On 17 October 2015 at 10:22, Sandro Santilli  wrote:

> > So, perhaps it would be better to clarify hosting
> > freedoms/requirements in advance.

[...]

> > Sandro, Martin, Alex, have been putting efforts into setting up Git,
> > improving Trac, and overall improvements.
> > Those efforts might be wasted, in case projects will move to GitHub.
> 
> What about the projects which are already on Github?

They hadn't wasted any effort, because no effort existed...

Anyway, the request is to the OSGeo board to clarify requisites of hosting
for OSGeo projects.

As an example, should it be *required* to allow anyone with an OSGeo
account (and no other) to file tickets ? Should be be *required* for
the in-development source code to be downloaded by only using free
software tools ? Those kind of criteria.

--strk;
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-17 Thread Anita Graser
On Sat, Oct 17, 2015 at 7:59 PM, Sandro Santilli  wrote:

> On Sat, Oct 17, 2015 at 05:06:54PM +0200, Anita Graser wrote:
> > On Oct 17, 2015 12:10 PM, "Mateusz Loskot"  wrote:
> > >
> ​
> Finally, with Sandro, we brainstormed idea of surveing the Community

​> > ​
> about their hosting needs/preferences.


​That sounds like a good idea!
​​

> > What about the projects which are already on Github?

They hadn't wasted any effort, because no effort existed...
>

​Projects which moved to Github at some point spent effort to both make the
decision and make the move. Granted, no effort on OSGeo side might have
been wasted.​

Anyway, the request is to the OSGeo board to clarify requisites of hosting
> for OSGeo projects.
>

​I'm trying to understand the direction this discussion is going since I
might not be aware of the full background story. Are you expressing a wish
for stricter hosting guidelines? Or would you simply want clarification,
even if that means OSGeo takes a very "everything goes" position?

Thanks and best wishes,
Anita
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-17 Thread Sandro Santilli
On Sat, Oct 17, 2015 at 09:34:19PM +0200, Anita Graser wrote:

> I'm trying to understand the direction this discussion is going since I
> might not be aware of the full background story. Are you expressing a wish
> for stricter hosting guidelines? Or would you simply want clarification,
> even if that means OSGeo takes a very "everything goes" position?

Well, first of all a clarification.

Of course it makes sense to me that OSGeo code hosting facility is
usable with free software tools, but I don't think any of the existing
OSGeo projects is in a conflicting situation in this reguard.

--strk;
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-17 Thread Mateusz Loskot
On 17 October 2015 at 21:34, Anita Graser  wrote:
> On Sat, Oct 17, 2015 at 7:59 PM, Sandro Santilli  wrote:
>> On Sat, Oct 17, 2015 at 05:06:54PM +0200, Anita Graser wrote:
>> > On Oct 17, 2015 12:10 PM, "Mateusz Loskot"  wrote:
>> >
>> > What about the projects which are already on Github?
>>
>> They hadn't wasted any effort, because no effort existed...
>
> Projects which moved to Github at some point spent effort to both make the
> decision and make the move. Granted, no effort on OSGeo side might have been
> wasted.

Let's imagine, all projects move to GitHub, then it affects OSGeo infrastructure
which becomes obsolete. Also, for some/many, move to GitHub may be
controversial, depending on actual (F)OSS-orientation of the community members.
So, IMO, wider discussion is not that pointless.

>> Anyway, the request is to the OSGeo board to clarify requisites of hosting
>> for OSGeo projects.
>
> I'm trying to understand the direction this discussion is going since I
> might not be aware of the full background story. Are you expressing a wish
> for stricter hosting guidelines? Or would you simply want clarification,
> even if that means OSGeo takes a very "everything goes" position?

I'd like to clarify my part of the discussion, which began as informal
chat on IRC,
since Sandro called my name, here is the story:

1. PostGIS is considering switch to Git, so they started discussing
git.osgeo.org vs GitHub.
2. Sandro prefers the idea of git.osgeo.org, so he started working
with SAC towards
setting up git.osgeo.org hosting, Trac integration, etc.
3. Regardless, PostGIS team is leaning towards GitHub.
4. Some of OSGeo projects have already moved to GitHub.
5. I started asking if Sandro's & SAC efforts to set up git.osgeo.org
make any sense,
if it is not going to be wasted energy - in case OSGeo projects stick
to SVN or move to GitHub.
6. Sandro does not mind and has been pressing on
7. I pointed out, that it is not about wasting energy of an individual
volunteer, there is more to consider,
especially, if all stars on the skyp indicate so far, that just
PostGIS (what is still unsure)
is going to use git.osgeo.org

Once Sandro has completed setting up git.osgeo.org infrastructure, who
is going to maintain it?
If SAC is going to inherit that baby, has SAC agreed to take it over
and invest time on keeping it up
and running? It is going to be one (or more) services extra to keep up
to date, secure, monitor,
back up, migrate, etc.

Bottom-up approach is a fantastic thing, but it drags certain
consequences that need to be considered.

So, I proposed that we (SAC) should survey the Community about their
hosting needs and ask
if git.osgeo.org is something we actually need, if there are any
projects interested in actually using it.

If yes, do we need plain Git installation, Git+Trac or perhaps GitLab?
If not, then why?
If not, because projects prefer GitHub, BitBucket, etc. then perhaps
OSGeo should
explicitly allow that and, perhaps, let SAC to actively maintain
organization accounts
on those external hosting services.

Unless, we as an established organization do not Wild Wild West approach,
we may need to clarify some answers.

Finally, after reading about similar experiences [1] at
Eclipse/Apache, I think this issue
is related to the recent "OSGeo is becoming irrelevant" thread too, so
it may be something
to make the Board concerned about.

[1] http://redmonk.com/sogrady/2013/06/20/eclipse-github/

I hope it makes more sense now.

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-17 Thread Anita Graser
On Oct 17, 2015 12:10 PM, "Mateusz Loskot"  wrote:
>
> On 17 October 2015 at 10:22, Sandro Santilli  wrote:
> > Given the number of OSGeo projects that are moving their code outside
> > of OSGeo infrastructure, Mateusz Loskot on IRC suggested to include
> > guidelines about what is or ins't accepted as a code repository
> > hosting for OSGeo projects.
>
> To clraify, the suggestion was inspired by this article and
> what Eclise Foundation proposed in their FAQ:
> http://redmonk.com/sogrady/2013/06/20/eclipse-github/
>
> Typical incubation questionnaire asks something like this:
>
> "If you do not intend to host any portion of this project using the OSGeo
> infrastructure, why should you be considered a member project..."
>
> So, perhaps it would be better to clarify hosting
> freedoms/requirements in advance.
>
> > Of course the ethical criteria is orthogonal to the strategic
> > arguments about having code hosted on or off OSGeo infrastructure.
>
> Also, as the latest discussion about GitHub revealed, there is number of
> practical features that make hosting alternatives more attractive.
>
> Finally, with Sandro, we brainstormed idea of surveing the Community
> about their hosting needs/preferences.
> Sandro, Martin, Alex, have been putting efforts into setting up Git,
> improving Trac, and overall improvements.
> Those efforts might be wasted, in case projects will move to GitHub.

What about the projects which are already on Github?

Best wishes
Anita

>
> Best regards,
> --
> Mateusz  Loskot, http://mateusz.loskot.net
> ___
> Discuss mailing list
> Discuss@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-17 Thread Mateusz Loskot
On 17 Oct 2015 17:06, "Anita Graser"  wrote:
> On Oct 17, 2015 12:10 PM, "Mateusz Loskot"  wrote:
> >
> > Finally, with Sandro, we brainstormed idea of surveing the Community
> > about their hosting needs/preferences.
> > Sandro, Martin, Alex, have been putting efforts into setting up Git,
> > improving Trac, and overall improvements.
> > Those efforts might be wasted, in case projects will move to GitHub.
>
> What about the projects which are already on Github?

Nothing. I'm not proposing any changes.
I'm asking questions myself.

Mateusz Łoskot
(Sent from mobile)
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo guidelines for code hosting ?

2015-10-17 Thread Anita Graser
On Sat, Oct 17, 2015 at 10:22 PM, Mateusz Loskot  wrote:
>
>
> I hope it makes more sense now.
>

​Thanks a lot for the background details Mateusz! Everything seems much
clearer now.​

​Looking forward to read other's opinions.

Best wishes,
Anita​
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss