Who takes care of collective.geo.* packages, or who feels responsible for those packages

It seems like gborelli is not that active anymore, but he's the only one who can make new pypi releases :slight_smile:
Previously he took care of those packages an reviewed/merged PR's.

I actually opened a PR for collective.geo.mapwidgets. I don't expect any reaction within a week, but since the collective.geo packages are well known and used in the plone community it would make sense to have some sort of maintainership for those packages.

I don't wanna discuss the genreal problem about packages in the collective and who is/feels responsible for them, but in this case IMHO it's more important to at least discuss this issue for the collective.geo packages.

Same here. I opened https://github.com/collective/collective.geo.bundle/pull/35 and asked for help. I don't volunteer to adopt these packages but I put in quite a lot of work during the last conference-sprint and would hate to see that go to waste. @maethu if you adopt them I'm willing to assist you whenever I can.

Let me report this to Giorgio, I'm sure he will be happy to share the package (at least with collective user)

I would be able to some testing and/or review small changes BugFix small features. but currently I'm still using plone 4.3.x, so I'm unable to say what some changes mean for plone 5, nor the compatibility between plone 4 and 5.

I'm also no longer familiar with Robot framework test, because I think they're not worth the effort and they're slow.

I would absolutely take responsibility for the plone 4 track and I would be able to manage BugFix releases.

That would be great!!!

I'm happy to see somebody interested in maintaining some parts of c.geo ecosystem.

As @keul suggested, I've shared the ownership of all c.geo packages with the user collective on pypi in order to simplify the maintenance. @maethu I've also shared the same ownership directly to you.

Here the complete list of packages:

  • collective.geo.bundle
  • collective.geo.geographer
  • collective.geo.openlayers
  • collective.geo.settings
  • collective.z3cform.mapwidget
  • collective.geo.mapwidget
  • collective.geo.behaviour
  • collective.geo.contentlocations
  • collective.geo.kml
  • collective.z3cform.colorpicker

Thank you all for your effort.

1 Like

Thank you @gborelli !
Also thank you for all the work you've done for collective.geo.* packages!! I've used it on over 150 Deployments :smile:

So I'll try to do my best, at least for the Plone 4 track.

It's probably also a good entry point for me to dig in Plone 5 :wink:

I fixed plone 4.3 tests and made a new release of collective.geo.mapwidget = 2.4

The new release of c.g.mapwidget uses the googleapi key defined by c.g.settings.

Since the 22th of June, it's necessary to provide a api key for google maps.

Hi @pbauer and everyone, I just migrated a Plone instance from v4 to v5, and the biggest issue is users cannot edit coordinates value through the map with collective.geo.*

I need a quick and simple WKT editing User Interface in Plone5, any advices are welcome. If collective.geo.* is the closest solution, then I will help to make it happen. I did see and try collective.geo.bundle plone5 branch, I can manually edit the WKT values, but this is unacceptable unfriendly for a regular user. Hopefully by end of this thread, we will have a working version for Plone5.

I did some c.geo fixes for Plone 5 lately and released them all.
This is my current GoodKnownSet of c.geo and c.geo related packages.

collective.geo.behaviour = 1.2
collective.geo.contentlocations = 3.2
collective.geo.kml = 3.3
collective.geo.mapwidget = 3.1
collective.geo.openlayers = 4.0
collective.geo.settings = 4.0
collective.geographer = 2.1
collective.z3cform.colorpicker = 2.0
collective.z3cform.mapwidget = 2.2

Be aware that you need a working Google Map API key (JS and geolookup)

2 Likes