Migrate to github?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Migrate to github?

Howard Butler-3
All,

In my role as self-appointed maintainer, I became quickly aware that my brain had been poisoned by github's ticket and development workflow. I found myself rather hamstrung without it in the context of doing the proj 4.9.1 release.

I would like to migrate the proj Trac and Subversion instances, including all tickets, revision control, branches, and tags, to a github repository at http://github.com/OSGeo/proj and decommission them once there's sign-off that the migration looks good.

Unless I hear significant pushback *against* doing this, consider this message your notice that the effort is ongoing, and I will notify once a test migration is complete for people to look around. At that time I will then motion to switch over once folks are satisfied.

Note that this same migration was done in the past by Thomas Bonfort for MapServer, with a much larger Trac instance (which itself was preserved from a Bugzilla instance). It's annoying to have software survive multiple generations of bug tracking and revision control software, but I guess it's a good thing that the software is useful enough to warrant the migration in the first place.

Howard

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Migrate to github?

Frank Warmerdam
Howard,

Sounds good to me!

Best regards,
Frank

On Fri, Mar 13, 2015 at 11:27 AM, Howard Butler <[hidden email]> wrote:

> All,
>
> In my role as self-appointed maintainer, I became quickly aware that my brain had been poisoned by github's ticket and development workflow. I found myself rather hamstrung without it in the context of doing the proj 4.9.1 release.
>
> I would like to migrate the proj Trac and Subversion instances, including all tickets, revision control, branches, and tags, to a github repository at http://github.com/OSGeo/proj and decommission them once there's sign-off that the migration looks good.
>
> Unless I hear significant pushback *against* doing this, consider this message your notice that the effort is ongoing, and I will notify once a test migration is complete for people to look around. At that time I will then motion to switch over once folks are satisfied.
>
> Note that this same migration was done in the past by Thomas Bonfort for MapServer, with a much larger Trac instance (which itself was preserved from a Bugzilla instance). It's annoying to have software survive multiple generations of bug tracking and revision control software, but I guess it's a good thing that the software is useful enough to warrant the migration in the first place.
>
> Howard
>
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj



--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Migrate to github?

Kralidis,Tom [Ontario]
In reply to this post by Howard Butler-3
+1

As seen with other projects having gone down this path, this will keep
things up to date, and encourage continued/increased improvements (3
cheers for pull requests!).

..Tom


> -----Original Message-----
> From: [hidden email] [mailto:proj-
> [hidden email]] On Behalf Of Howard Butler
> Sent: 2015-03-13 14:28
> To: PROJ.4 and general Projections Discussions
> Subject: [Proj] Migrate to github?
>
> All,
>
> In my role as self-appointed maintainer, I became quickly aware that
my
> brain had been poisoned by github's ticket and development workflow. I
> found myself rather hamstrung without it in the context of doing the
proj
> 4.9.1 release.
>
> I would like to migrate the proj Trac and Subversion instances,
including all
> tickets, revision control, branches, and tags, to a github repository
at
> http://github.com/OSGeo/proj and decommission them once there's sign-
> off that the migration looks good.
>
> Unless I hear significant pushback *against* doing this, consider this
message
> your notice that the effort is ongoing, and I will notify once a test
migration is
> complete for people to look around. At that time I will then motion to
switch
> over once folks are satisfied.
>
> Note that this same migration was done in the past by Thomas Bonfort
for
> MapServer, with a much larger Trac instance (which itself was
preserved
> from a Bugzilla instance). It's annoying to have software survive
multiple
> generations of bug tracking and revision control software, but I guess
it's a
> good thing that the software is useful enough to warrant the migration
in the
> first place.
>
> Howard
>
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Migrate to github?

Charles Karney
In reply to this post by Howard Butler-3
+1 (mainly because by now I'm more familiar with git than svn)

On 2015-03-13 14:27, Howard Butler wrote:

> All,
>
> In my role as self-appointed maintainer, I became quickly aware that my brain had been poisoned by github's ticket and development workflow. I found myself rather hamstrung without it in the context of doing the proj 4.9.1 release.
>
> I would like to migrate the proj Trac and Subversion instances, including all tickets, revision control, branches, and tags, to a github repository at http://github.com/OSGeo/proj and decommission them once there's sign-off that the migration looks good.
>
> Unless I hear significant pushback *against* doing this, consider this message your notice that the effort is ongoing, and I will notify once a test migration is complete for people to look around. At that time I will then motion to switch over once folks are satisfied.
>
> Note that this same migration was done in the past by Thomas Bonfort for MapServer, with a much larger Trac instance (which itself was preserved from a Bugzilla instance). It's annoying to have software survive multiple generations of bug tracking and revision control software, but I guess it's a good thing that the software is useful enough to warrant the migration in the first place.
>
> Howard
>
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Migrate to github?

Greg Troxel
In reply to this post by Howard Butler-3

I am unclear on osgeo hosting, but I think that in general Free Software
projects should be hosted at Free Software-supporting nonprofits.
(But you're the one doing the work, so I'll just say this once and be
done.)



_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

attachment0 (186 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Migrate to github?

Roger Bivand
Greg Troxel <gdt <at> ir.bbn.com> writes:

>
>
> I am unclear on osgeo hosting, but I think that in general Free Software
> projects should be hosted at Free Software-supporting nonprofits.
> (But you're the one doing the work, so I'll just say this once and be
> done.)
>
>

This is a contentious but vital point, which other Free Software foundations
have found troubling. It means that someone must have an actively maintained
plan for withdrawal from github.com should the company fold, or its domain
be blocked in jurisdictions where users and developers need access to code
and documentation.

Use of cloudy-CDN for software distribution is another very controversial
topic for similar reasons.

If PROJ closes SVN read access, I will stop tracking trunk for uses in R,
and consequently not provide reports on changes in PROJ that break other
stuff. Life is too short to use only fashionable tools (and git is not
uniformly accepted as being superior to svn).

Roger

>
> _______________________________________________
> Proj mailing list
> Proj <at> lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj




_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: Migrate to github?

Charles Karney
On 03/15/2015 06:59 AM, Roger Bivand wrote:

> Greg Troxel <gdt <at> ir.bbn.com> writes:
>
>> I am unclear on osgeo hosting, but I think that in general Free Software
>> projects should be hosted at Free Software-supporting nonprofits.
>> (But you're the one doing the work, so I'll just say this once and be
>> done.)
>
> This is a contentious but vital point, which other Free Software foundations
> have found troubling. It means that someone must have an actively maintained
> plan for withdrawal from github.com should the company fold, or its domain
> be blocked in jurisdictions where users and developers need access to code
> and documentation.
>
> Use of cloudy-CDN for software distribution is another very controversial
> topic for similar reasons.
>
> If PROJ closes SVN read access, I will stop tracking trunk for uses in R,
> and consequently not provide reports on changes in PROJ that break other
> stuff. Life is too short to use only fashionable tools (and git is not
> uniformly accepted as being superior to svn).
>
> Roger
>

I'm not a purist about hosting sites provided that the software license
isn't affected.  github seems fine to me.  The software can't just
disappear with a git repository since every contributor will have a
copy.  I suppose that the metadata (bug tracking information) can vanish
-- but that's probably true (more likely?) with the current setup.

I'm also fine using either svn or git (with a preference for git).

What I think is unacceptable is a 3-year interval between releases for
proj4.  (4.8.0 was released on 2012-03-13; 4.9.0 was never released;
4.9.1 was released on 2015-03-04.)

Howard Butler stepped up after a long period of inactivity to make the
latest release of proj4 happen.  I'm strongly inclined to defer to his
wishes going forward in the hope that we can see more timely releases.

   --Charles

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Migrate to github?

peifer
On 2015-03-15 14:25, Charles Karney wrote:
>
> What I think is unacceptable is a 3-year interval between releases for
> proj4.  (4.8.0 was released on 2012-03-13; 4.9.0 was never released;
> 4.9.1 was released on 2015-03-04.)
>
> Howard Butler stepped up after a long period of inactivity to make the
> latest release of proj4 happen.  I'm strongly inclined to defer to his
> wishes going forward in the hope that we can see more timely releases.
>

I can only blow into the same horn: it hurted me seeing PROJ.4 moving
towards abandonware, as e.g. confirmed by fact of release 4.9.0 being
abandoned.

 From my somewhat simplistic use-PROJ.4-from-source perspective, the
issue boils simply down to: "svn up" vs. "git pull". If I had to choose
between abandoned code and bug reports in a politically correct
repository vs. actively maintained code at github.com or similar: life
is too short for not choosing the latter option.

There is also:
https://help.github.com/articles/support-for-subversion-clients/, for
those who have a preference for: svn up.

Hermann

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Migrate to github?

Howard Butler-3

> On Mar 15, 2015, at 10:37 PM, Hermann Peifer <[hidden email]> wrote:
>
> On 2015-03-15 14:25, Charles Karney wrote:
>>
>> What I think is unacceptable is a 3-year interval between releases for
>> proj4.  (4.8.0 was released on 2012-03-13; 4.9.0 was never released;
>> 4.9.1 was released on 2015-03-04.)
>>
>> Howard Butler stepped up after a long period of inactivity to make the
>> latest release of proj4 happen.  I'm strongly inclined to defer to his
>> wishes going forward in the hope that we can see more timely releases.
>>
>
> I can only blow into the same horn: it hurted me seeing PROJ.4 moving
> towards abandonware, as e.g. confirmed by fact of release 4.9.0 being
> abandoned.
>
> From my somewhat simplistic use-PROJ.4-from-source perspective, the
> issue boils simply down to: "svn up" vs. "git pull". If I had to choose
> between abandoned code and bug reports in a politically correct
> repository vs. actively maintained code at github.com or similar: life
> is too short for not choosing the latter option.
>
> There is also:
> https://help.github.com/articles/support-for-subversion-clients/, for
> those who have a preference for: svn up.


Hmm, I didn't expect my proposal to move to github would be controversial. I know that Trac is a PITA, especially OSGeo's somewhat custom UserID implementation, and while going through the tickets it appeared to me that if it was easier to contribute, there would be more contribution. In my opinion, it is undeniable that github makes it much easier for people to contribute. I have seen this in projects I've managed, projects I've participated in, and projects I've contributed to.

All of the free github clones might have this property too, but then those things don't come with the built-in developer audience. And it's yet another thing to run and maintain for an organization like OSGeo that's already strapped for volunteer administration resources. I think it would be more efficient for OSGeo to pay for github infrastructure if they have to (don't need to currently) than to waste volunteer mojo on care and feeding of redundant and less-efficient self-hosting of infrastructure.

The Pull Request is an extremely powerful way to contribute that allows drive-by contribution. proj.4 is too important of a project to let fall away, but its nature means that only when people have issues will they be compelled to contribute. That cycle needs to be as friction free, painless and convenient as possible, otherwise it's just too damn much effort and people don't bother. If we want proj.4 to continue in low-maintenance mode, we need to make sure that drive-by contribution is front-and-center visible. Even if a contributor gets over the login hump, that type of contribution ends up being buried in Trac instead of in front of other potential contributors.

OSGeo's Trac instance is probably never going to get OAuth, meaning its logins and security access will always be kind of one-off. Trac itself is not so actively developed anymore. In combination, these facts mean OSGeo's Trac instance will slowly fall into disrepair like a crumbling city in which no one remembers why it was there in the first place. This is not because it has failed in any way, it is simply because people have moved on. It's the same thing for Google Code too. And someday in the future, the probability is not zero the same will happen to github too.

I think the market has clearly spoken with respect to DVCS like git vs central VCS like cvs/svn. CVS/SVN incentivizes very small contributions to the codebase if you are a developer external to the project. A geriatric project like proj.4 needs to make it easy for outside contributors to hop in and contribute without friction. Artificial barriers, purposeful or not, waste that developer attention.

A number of OSGeo projects use github for hosting, as do plenty of LocationTech ones as well. I'm comfortable using it for my projects (http://github.com/PDAL/PDAL) too. For a small audience, big impact project like proj.4, it's a well-matched venue.

Howard
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Migrate to github?

Roger Bivand
Howard Butler <howard <at> hobu.co> writes:

>
>
> > On Mar 15, 2015, at 10:37 PM, Hermann Peifer <peifer <at> gmx.eu> wrote:
> >
> > On 2015-03-15 14:25, Charles Karney wrote:
> >>
> >> What I think is unacceptable is a 3-year interval between releases for
> >> proj4.  (4.8.0 was released on 2012-03-13; 4.9.0 was never released;
> >> 4.9.1 was released on 2015-03-04.)
> >>
> >> Howard Butler stepped up after a long period of inactivity to make the
> >> latest release of proj4 happen.  I'm strongly inclined to defer to his
> >> wishes going forward in the hope that we can see more timely releases.
> >>
> >
> > I can only blow into the same horn: it hurted me seeing PROJ.4 moving
> > towards abandonware, as e.g. confirmed by fact of release 4.9.0 being
> > abandoned.
> >
> > From my somewhat simplistic use-PROJ.4-from-source perspective, the
> > issue boils simply down to: "svn up" vs. "git pull". If I had to choose
> > between abandoned code and bug reports in a politically correct
> > repository vs. actively maintained code at github.com or similar: life
> > is too short for not choosing the latter option.
> >
> > There is also:
> > https://help.github.com/articles/support-for-subversion-clients/, for
> > those who have a preference for: svn up.
>
> Hmm, I didn't expect my proposal to move to github would be controversial.
I know that Trac is a PITA,
> especially OSGeo's somewhat custom UserID implementation, and while going
through the tickets it
> appeared to me that if it was easier to contribute, there would be more
contribution. In my opinion, it is
> undeniable that github makes it much easier for people to contribute. I
have seen this in projects I've
> managed, projects I've participated in, and projects I've contributed to.
>
> ...
>
> ...
> Even if a contributor gets over the login hump, that type of contribution
ends up being buried in Trac
> instead of in front of other potential contributors.
>
> ... This is not because it has failed in any way, it is simply because people
> have moved on. It's the same thing for Google Code too. And someday in the
future, the probability is not
> zero the same will happen to github too.
>
> ... A
> geriatric project like proj.4 needs to make it easy for outside
contributors to hop in and contribute
> without friction. Artificial barriers, purposeful or not, waste that
developer attention.
>
> A number of OSGeo projects use github for hosting, as do plenty of
LocationTech ones as well. I'm
> comfortable using it for my projects (http://github.com/PDAL/PDAL) too.
For a small audience, big
> impact project like proj.4, it's a well-matched venue.

I apologise for pruning, but am posting via Gmane. As you'll have gathered,
I don't think that things are this simple.

One reason is that we really don't want outside contributors or hip
developers without insight into the history and traditions of actually doing
projections on computers making random changes. The level of specialist
expertise needed is considerable. I know that I don't have it, but I'd be
very concerned about pull requests bazaar style becoming the norm

Another is that there is no agreement that all projects are suited by a
decentralised model for repositories.

Yet another is the consideration that some jurisdictions may block a domain
for whatever reasons. Currently proj is hosted on osgeo.org for everything,
but if the code repository is elsewhere, will the releases also be hosted
elsewhere?

I agree that it is probable that the fashion for github will recede in some
years. Maybe git will continue, it isn't unuseful, but seems better suited
to front-end work.

I believe that many scientists rely on proj to deliver research results of
importance, results that can be predictably reproduced from securely run and
archived repositories.

I don't think that I'm being unnecessarily critical - finding and resolving
the init bug #229 and the uoff bug #239 show that I've been trying to track
where changes in proj break stuff in its use in R, and I'm grateful for the
resolution of these issue. However, I don't think that a quick shift to
github will solve the longer term problem of managing the project. Does
MetaCRS still exist? Should its PSC help decide? Could you put up an RFC
with a time line? Just getting handwaves on a list is too ad-hoc - I've seen
it happen before and it wasn't a constructive experience.

If you believe that this has to be done your way, it also implies affirming
your responsibility for the project in the long term, which, given your
other major commitments, is maybe over-generous.

My conservatism is also driven by a feeling of responsibility, in my case
for many students and researchers using sp and rgdal in R, and through them
proj4, for handling spatial data. Just keeping things running is plenty of
work.

In any case, I guess everyone will follow a lead, we certainly will.

Best wishes,

Roger


>
> Howard
> _______________________________________________
> Proj mailing list
> Proj <at> lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>
>




_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: Migrate to github?

Frank Warmerdam
On Mon, Mar 16, 2015 at 1:11 PM, Roger Bivand <[hidden email]> wrote:
> I apologise for pruning, but am posting via Gmane. As you'll have gathered,
> I don't think that things are this simple.
>
> One reason is that we really don't want outside contributors or hip
> developers without insight into the history and traditions of actually doing
> projections on computers making random changes. The level of specialist
> expertise needed is considerable. I know that I don't have it, but I'd be
> very concerned about pull requests bazaar style becoming the norm

Roger,

I wanted to stress a couple points.

1) moving to github.com does not mean anyone can make changes in the
main code stream.  They can propose a pull request, but someone
responsible (an approved commiter) still needs to review and merge the
changes.  In this regard it is not much different than folks offering
patches via Trac though the process is perhaps more streamlined.

>
> Another is that there is no agreement that all projects are suited by a
> decentralised model for repositories.
>
> Yet another is the consideration that some jurisdictions may block a domain
> for whatever reasons. Currently proj is hosted on osgeo.org for everything,
> but if the code repository is elsewhere, will the releases also be hosted
> elsewhere?

My expectation would be that release tarballs would still live in the
usual location on downloads.osgeo.org.

> I agree that it is probable that the fashion for github will recede in some
> years. Maybe git will continue, it isn't unuseful, but seems better suited
> to front-end work.
>
> I believe that many scientists rely on proj to deliver research results of
> importance, results that can be predictably reproduced from securely run and
> archived repositories.
>
> I don't think that I'm being unnecessarily critical - finding and resolving
> the init bug #229 and the uoff bug #239 show that I've been trying to track
> where changes in proj break stuff in its use in R, and I'm grateful for the
> resolution of these issue. However, I don't think that a quick shift to
> github will solve the longer term problem of managing the project. Does
> MetaCRS still exist? Should its PSC help decide? Could you put up an RFC
> with a time line? Just getting handwaves on a list is too ad-hoc - I've seen
> it happen before and it wasn't a constructive experience.

I believe Howard ought to propose a migration to github (also
explaining trac, and wiki migration) as an RFC to the MetaCRS PSC.

I certainly see the MetaCRS PSC continuing to consider RFCs and final
releases and approving new commiters (ie. those allowed to merge pull
requests or commit to the osgeo organization github organization).

> If you believe that this has to be done your way, it also implies affirming
> your responsibility for the project in the long term, which, given your
> other major commitments, is maybe over-generous.
>
> My conservatism is also driven by a feeling of responsibility, in my case
> for many students and researchers using sp and rgdal in R, and through them
> proj4, for handling spatial data. Just keeping things running is plenty of
> work.
>
> In any case, I guess everyone will follow a lead, we certainly will.

I quite agree that github is no panacea.  I am concerned it will lose
a few folks who were tracking svn and understood that flow.  In fact,
I stopped tracking MapServer trunk when it moved to github.  But it
will still be accessable to anyone who wants to make an effort, and it
will be more natural for many others already on github (a transition I
have now mostly absorbed).  If Howard wasn't keen on it, I'd tend to
leave well enough alone for a while, but given his huge contributions
to PROJ.4, and his generally good instincts on this sort of thing, I'm
happy to be supportive of a transition.

Best regards,
Frank

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Migrate to github?

Howard Butler-3
In reply to this post by Roger Bivand

> On Mar 16, 2015, at 3:11 PM, Roger Bivand <[hidden email]> wrote:
>
> One reason is that we really don't want outside contributors or hip
> developers without insight into the history and traditions of actually doing
> projections on computers making random changes. The level of specialist
> expertise needed is considerable. I know that I don't have it, but I'd be
> very concerned about pull requests bazaar style becoming the norm

The protection against your concern is better tests and better testing of release candidates, not limiting who can contribute. I'll grant you the maths are specialized knowledge, but a significant chunk of the ticket traffic is your normal workaday library and management stuff, not intricacies of the maths. Nearly all of my ticket efforts in the run up to the 4.9.1 release was this workaday stuff, no maths.

> Another is that there is no agreement that all projects are suited by a
> decentralised model for repositories.

A centralized repository supposes a group of folks with the wherewithal to manage, curate, and administer that software project. PROJ.4 clearly doesn't have that anymore (and I would posit it never did -- it just had ready access to Frank and he was able to justify spending his time one it). It has a bunch of users who care but aren't empowered to make the changes they need to happen. I stepped in to do the release because my software, PDAL, depends heavily on a working PROJ.4, and I'm special in that I'm a MetaCRS member with commit access in the repository. I have historically never been a PROJ.4 developer, and without my having been previously blessed, I otherwise would have been stuck.

A way forward is for PROJ.4 to be in (low) maintenance mode with wide contribution for any/all who feel empowered to do so, along with some people who have the authority to make a release happen. Subversion and a stove-piped Trac instance cut very hard against that mode of operation. The alternative is (no) maintenance mode with almost no one having access to the revision control to maintain the software and waiting extremely long periods between releases. No one has been comfortable with the latter scenario.

Let's try something different. I'm willing to step in as a release manager for PROJ.4, and help out where I can and shepherd release activity. I'm also not very comfortable on the maths, but I'm willing to react to testing, and I have enough confidence on other typical open source software development activities. I want to solicit more contribution. Expertise can be acquired, historical rational can be learned, and tests can be satisfied. People will invest the time if they know that it can lead somewhere useful for them.

> Yet another is the consideration that some jurisdictions may block a domain
> for whatever reasons. Currently proj is hosted on osgeo.org for everything,
> but if the code repository is elsewhere, will the releases also be hosted
> elsewhere?

This would frankly be worse if osgeo.org were blocked in China or whatever. The organization has no financial or legal capacity to fight anything like that. github will.

> I believe that many scientists rely on proj to deliver research results of
> importance, results that can be predictably reproduced from securely run and
> archived repositories.

The organization that produces the release, MetaCRS, will still be responsible for promoting and releasing it. That will not change regardless of the revision control or ticket tracking system that is used.

> I don't think that I'm being unnecessarily critical - finding and resolving
> the init bug #229 and the uoff bug #239 show that I've been trying to track
> where changes in proj break stuff in its use in R, and I'm grateful for the
> resolution of these issue. However, I don't think that a quick shift to
> github will solve the longer term problem of managing the project. Does
> MetaCRS still exist? Should its PSC help decide? Could you put up an RFC
> with a time line? Just getting handwaves on a list is too ad-hoc - I've seen
> it happen before and it wasn't a constructive experience.

I'm not going to write an RFC for this. I will put a test ingest up for discussion, and when we feel ready, I will motion to the MetaCRS committee to get sign off on a github migration.

> If you believe that this has to be done your way, it also implies affirming
> your responsibility for the project in the long term, which, given your
> other major commitments, is maybe over-generous.

I have a project and financial stake in making sure PROJ.4 is a viable software library going forward. Without the PROJ.4, libgeotiff, OSR triumvirate, I need to find new software to support horizontal and vertical coordinate transformation for 3D geospatial point cloud data. I don't have the funding available to build something from scratch, and moving to something like CS-Map is going to cost more money and time. I won't be migrating PROJ.4 to github and walking away. My contribution history to this and other OSGeo-sphere projects should make that clear.

Howard
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: Migrate to github?

Roger Bivand
Howard Butler <howard <at> hobu.co> writes:

>
>
> > On Mar 16, 2015, at 3:11 PM, Roger Bivand <Roger.Bivand <at> nhh.no> wrote:
> >
>...
>
> > ...
>
> Let's try something different. I'm willing to step in as a release manager
for PROJ.4, and help out where I
> can and shepherd release activity. I'm also not very comfortable on the
maths, but I'm willing to react to
> testing, and I have enough confidence on other typical open source
software development activities. I
> want to solicit more contribution. Expertise can be acquired, historical
rational can be learned, and
> tests can be satisfied. People will invest the time if they know that it
can lead somewhere useful for them.
>

Thanks for many useful clarifications. It is arguably important to have a
record of why a change is being considered - now we have it.

> >
...
>
> > I believe that many scientists rely on proj to deliver research results of
> > importance, results that can be predictably reproduced from securely run and
> > archived repositories.
>
> The organization that produces the release, MetaCRS, will still be
responsible for promoting and
> releasing it. That will not change regardless of the revision control or
ticket tracking system that is used.

OK, good.

>
> >
...
>
> I'm not going to write an RFC for this. I will put a test ingest up for
discussion, and when we feel ready, I will
> motion to the MetaCRS committee to get sign off on a github migration.
>
> ...

And a process clarification - so we know more or less where we are and where
we are going. The final point is for as many as possible to offer active
support in taking PROJ.4 forward.

Best wishes,

Roger

>
> Howard
> _______________________________________________
> Proj mailing list
> Proj <at> lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>
>




_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: Migrate to github?

Greg Troxel
In reply to this post by Howard Butler-3

I know you said you'd keep release tarballs on osgeo.org, but I wanted
to point out what having releases on github tends to do.  I don't mean
to pick on jswhit; this sort of not following naming conventions is very
common with github.

https://github.com/jswhit/pyproj/issues/7

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

attachment0 (186 bytes) Download Attachment