[GeoNetwork-devel] Contributing fixes/support release schedules

GeoNetwork GeoNetwork Developer
1

Hi All,

We're in the process of upgrading to GeoNetwork 3 (currently working
with 3.8.2) and iso19115-3:2018 and would like to clarify/confirm the
process for contributing fixes and release schedules for such.

We've done some initial smoke testing and have found some issues for
which we have raised some pull requests. We still have more
comprehensive testing to do in the next month or so and so I expect we
will be raising more issues/pull requests in future.

So far we have been raising issues against the relevant repositories
with a description of the problem we are having and creating pull
requests in 3.8.x and in master to fix the issue on the assumption that
we will be able to take a support release of 3.8 including them in future.

Is this the process we should be following? Some of my pull requests
have been reviewed and merged (thanks Francois!) so I think we're
probably not too far off but if there's anything else we should be doing
e.g. tagging issues as bugs/enhancements, requesting reviews from
particular individuals etc please let us know.

With regard to taking a support release of 3.8 containing fixes, what
are the plans/timings for performing these? We were looking to upgrade
at the end of march (likely to slip - still much to do) and we would
like to plan our approach to doing this - using support releases
including fixes, using custom views to fix issues in the interim or some
other approach depending on the types of issues we encounter. Is there
anything we can do to help?

Thanks,

Craig Jones
Integrated Marine Observing System
University of Tasmania

University of Tasmania Electronic Communications Policy (December, 2014).
This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise.

2

I put a call for 3.8.3 fixes back in December …

and did not get much response. My focus is on release automation rather than hitting a specific release date.

That said I am new to the devel list and am also learning the ropes.

···

–
Jody Garnett

3

Hi Craig,

We made a 3.8 monthly release from August to November with a number of bug fixes and minor improvements.
After discussion in December sprint introducing “major” (but not really visible) changes (eg. OL6 update, S3 support), it was discussed that we should move to a new major release ie. 3.10.0 (which I’ve proposed to make tomorrow).

On my side, with the resources I have, I will concentrate on 3.10.x branch (which is the branch used everywhere here now) and I also try to make progress on “es” branch (help welcomed). If everyone is ok with it, I’m also fine to make a ~monthly release for 3.10.x for the coming months. So I would suggest that you help me on 3.10.x (rather than using 3.8.x).

For your PR’s related to the map, I’ll try to look into them by tomorrow if no one else do.

About the process you do it right (maybe better than anyone :)), one PR for each branches, clear description of issue … - During last year, we not often had one PR per branches and I think it is quite some work for not much benefits (in most cases). I’ve been cherry-picking all PRs proposed to master to the branch “maintained” and it was quite efficient (I hope) for everyone (don’t need to ask for missing PR, don’t wait for it … for long time, less stuff to maintain on github). Currently, master is quite similar to 3.8.x that it will work in 95% of the cases. So maybe having one person in charge of this is better than requesting 2 (or more) versions of all PRs ?

Maybe something to clarify is who is maintaining which branches?
Same for schema-plugins could be relevant for users.

Cheers.

Francois

Le mer. 15 janv. 2020 à 23:22, Craig Jones <jonescc@anonymised.com> a écrit :

Hi All,

We’re in the process of upgrading to GeoNetwork 3 (currently working
with 3.8.2) and iso19115-3:2018 and would like to clarify/confirm the
process for contributing fixes and release schedules for such.

We’ve done some initial smoke testing and have found some issues for
which we have raised some pull requests. We still have more
comprehensive testing to do in the next month or so and so I expect we
will be raising more issues/pull requests in future.

So far we have been raising issues against the relevant repositories
with a description of the problem we are having and creating pull
requests in 3.8.x and in master to fix the issue on the assumption that
we will be able to take a support release of 3.8 including them in future.

Is this the process we should be following? Some of my pull requests
have been reviewed and merged (thanks Francois!) so I think we’re
probably not too far off but if there’s anything else we should be doing
e.g. tagging issues as bugs/enhancements, requesting reviews from
particular individuals etc please let us know.

With regard to taking a support release of 3.8 containing fixes, what
are the plans/timings for performing these? We were looking to upgrade
at the end of march (likely to slip - still much to do) and we would
like to plan our approach to doing this - using support releases
including fixes, using custom views to fix issues in the interim or some
other approach depending on the types of issues we encounter. Is there
anything we can do to help?

Thanks,

Craig Jones
Integrated Marine Observing System
University of Tasmania

University of Tasmania Electronic Communications Policy (December, 2014).
This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise.

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

4

CraigJ

···

Hi Francois,

Yes it would make sense for us to work on 3.10.x with you if the release is relatively stable (don’t want our upgrade timetable to slip any further).

An upgrade of openlayers and the s3 support for the geonetwork data directory doesn’t sound too major and we may actually want to use s3 support.

We’ll have a look after the release is made and decide what we what to do. Can talk about branch maintenance then if necessary.

Hopefully regular releases of 2.10.x will help Jody as well. (Thanks for your reply Jody).

On 16/1/20 6:36 pm, Francois Prunayre wrote:

Hi Craig,

We made a 3.8 monthly release from August to November with a number of bug fixes and minor improvements.
After discussion in December sprint introducing “major” (but not really visible) changes (eg. OL6 update, S3 support), it was discussed that we should move to a new major release ie. 3.10.0 (which I’ve proposed to make tomorrow).

On my side, with the resources I have, I will concentrate on 3.10.x branch (which is the branch used everywhere here now) and I also try to make progress on “es” branch (help welcomed). If everyone is ok with it, I’m also fine to make a ~monthly release for 3.10.x for the coming months. So I would suggest that you help me on 3.10.x (rather than using 3.8.x).

For your PR’s related to the map, I’ll try to look into them by tomorrow if no one else do.

About the process you do it right (maybe better than anyone :)), one PR for each branches, clear description of issue … - During last year, we not often had one PR per branches and I think it is quite some work for not much benefits (in most cases). I’ve been cherry-picking all PRs proposed to master to the branch “maintained” and it was quite efficient (I hope) for everyone (don’t need to ask for missing PR, don’t wait for it … for long time, less stuff to maintain on github). Currently, master is quite similar to 3.8.x that it will work in 95% of the cases. So maybe having one person in charge of this is better than requesting 2 (or more) versions of all PRs ?

Maybe something to clarify is who is maintaining which branches?
Same for schema-plugins could be relevant for users.

Cheers.

Francois

Le mer. 15 janv. 2020 à 23:22, Craig Jones <jonescc@…158…> a écrit :

Hi All,

We’re in the process of upgrading to GeoNetwork 3 (currently working
with 3.8.2) and iso19115-3:2018 and would like to clarify/confirm the
process for contributing fixes and release schedules for such.

We’ve done some initial smoke testing and have found some issues for
which we have raised some pull requests. We still have more
comprehensive testing to do in the next month or so and so I expect we
will be raising more issues/pull requests in future.

So far we have been raising issues against the relevant repositories
with a description of the problem we are having and creating pull
requests in 3.8.x and in master to fix the issue on the assumption that
we will be able to take a support release of 3.8 including them in future.

Is this the process we should be following? Some of my pull requests
have been reviewed and merged (thanks Francois!) so I think we’re
probably not too far off but if there’s anything else we should be doing
e.g. tagging issues as bugs/enhancements, requesting reviews from
particular individuals etc please let us know.

With regard to taking a support release of 3.8 containing fixes, what
are the plans/timings for performing these? We were looking to upgrade
at the end of march (likely to slip - still much to do) and we would
like to plan our approach to doing this - using support releases
including fixes, using custom views to fix issues in the interim or some
other approach depending on the types of issues we encounter. Is there
anything we can do to help?

Thanks,

Craig Jones
Integrated Marine Observing System
University of Tasmania

University of Tasmania Electronic Communications Policy (December, 2014).
This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise.

GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork