[GeoNetwork-devel] New Guidelines for contributing

Hi,

According to what we have discussed this week in Bolsena, I created a
wiki page with a guideline for developers:

https://github.com/geonetwork/core-geonetwork/wiki/How-to-contribute

Let me know if I missed something or something should be rephrased.

We still have to block commits on the stable branches and enable the
require reviews on PR to merge. I don't have privileges on github to
do that.

Kind regards,

María Arias de Reyna Domínguez

Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664

Please consider the environment before printing this email.

We should maybe check that this is also inline with current rules
https://trac.osgeo.org/geonetwork/wiki/PSC and adapt it if required.

Francois

···

2017-06-15 10:34 GMT+02:00 Maria Arias de Reyna <maria.arias@anonymised.com>:

Hi,

According to what we have discussed this week in Bolsena, I created a
wiki page with a guideline for developers:

https://github.com/geonetwork/core-geonetwork/wiki/How-to-contribute

Let me know if I missed something or something should be rephrased.

We still have to block commits on the stable branches and enable the
require reviews on PR to merge. I don’t have privileges on github to
do that.

Kind regards,

María Arias de Reyna Domínguez

Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664

Please consider the environment before printing this email.


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


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

On an ideal world, we should adapt the PSC to the new review github
system instead of having to send an email with voting. But for that,
all PSC members should be more or less active on github. Which also
leads me to the question, are all PSC members still active?

On Thu, Jun 15, 2017 at 3:04 PM, Francois Prunayre
<fx.prunayre@anonymised.com> wrote:

We should maybe check that this is also inline with current rules
https://trac.osgeo.org/geonetwork/wiki/PSC and adapt it if required.

Francois

2017-06-15 10:34 GMT+02:00 Maria Arias de Reyna <maria.arias@anonymised.com>:

Hi,

According to what we have discussed this week in Bolsena, I created a
wiki page with a guideline for developers:

https://github.com/geonetwork/core-geonetwork/wiki/How-to-contribute

Let me know if I missed something or something should be rephrased.

We still have to block commits on the stable branches and enable the
require reviews on PR to merge. I don't have privileges on github to
do that.

Kind regards,

María Arias de Reyna Domínguez

Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664

Please consider the environment before printing this email.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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

Are you guys sure you want bug fixes to go to stable, wouldn’t it be better to ug fix unstable (master) and back port to stable (released) branch. Other wise you will reacquire bugs when you make a new release from master?

Ian

···

On 15 June 2017 at 09:34, Maria Arias de Reyna <maria.arias@anonymised.com> wrote:

Hi,

According to what we have discussed this week in Bolsena, I created a
wiki page with a guideline for developers:

https://github.com/geonetwork/core-geonetwork/wiki/How-to-contribute

Let me know if I missed something or something should be rephrased.

We still have to block commits on the stable branches and enable the
require reviews on PR to merge. I don’t have privileges on github to
do that.

Kind regards,

María Arias de Reyna Domínguez

Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664

Please consider the environment before printing this email.


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


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

Ian Turton

On Thu, Jun 15, 2017 at 3:24 PM, Ian Turton <ijturton@anonymised.com> wrote:

Are you guys sure you want bug fixes to go to stable, wouldn't it be better
to ug fix unstable (master) and back port to stable (released) branch. Other
wise you will reacquire bugs when you make a new release from master?

Branches always go forwards, not backwards. Everything on stable will
go to unstable. So the bugfix will go to unstable. Things pushed to
unstable will not be cherry picked to stable (or shouldn't be).

On Thu, Jun 15, 2017 at 3:26 PM, María Arias de Reyna <delawen@anonymised.com.> wrote:

On Thu, Jun 15, 2017 at 3:24 PM, Ian Turton <ijturton@anonymised.com> wrote:

Are you guys sure you want bug fixes to go to stable, wouldn't it be better
to ug fix unstable (master) and back port to stable (released) branch. Other
wise you will reacquire bugs when you make a new release from master?

Branches always go forwards, not backwards. Everything on stable will
go to unstable. So the bugfix will go to unstable. Things pushed to
unstable will not be cherry picked to stable (or shouldn't be).

We are following (or try to follow) this approach:
https://github.com/geonetwork/core-geonetwork/wiki/Git-merge-branching-good-practices

Hi,

Ian, in GeoServer there are 2 stable branches + the master branch, so it’s good to have a starting point (master) and then move toward a single direction (backward) for porting the fix.
In GN there are 2 active branches, so I guess any direction for porting is good; anyway (@Maria) there is no info in the wiki page about how the fix should be ported forward.

Cheers,
Emanuele

···

2017-06-15 15:26 GMT+02:00 María Arias de Reyna <delawen@anonymised.com>:

On Thu, Jun 15, 2017 at 3:24 PM, Ian Turton <ijturton@anonymised.com> wrote:

Are you guys sure you want bug fixes to go to stable, wouldn’t it be better
to ug fix unstable (master) and back port to stable (released) branch. Other
wise you will reacquire bugs when you make a new release from master?

Branches always go forwards, not backwards. Everything on stable will
go to unstable. So the bugfix will go to unstable. Things pushed to
unstable will not be cherry picked to stable (or shouldn’t be).


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


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

Hi,
humbly chiming in, mostly to explain why GeoServer has that direction for bug fixes.

One has already been cited by Ian, to avoid losing them. In a perfect world one would fix the stuff and then
port the fix to master as well, but life is sometimes a bit more complicated, e.g, you fix the bug on stable,
then get into a meeting, or some emergency investigation, or a vacation, whatever, and forget to do the
forward port. When the new master is released, months later, the issue is going to regress.
Now, of course one can commit to master and forget to backport by the same mechanics. It’s still bad,

but you get feedback right away that it happened, and if you don’t, well at least the fix is going to survive in the future.

A second rationale is side effects. Again, in an ideal world, making a bug fix is a simple, isolated activity.
But in practice, it happens that it’s convoluted, sometimes it’s large and scary, let alone the cases in which
you are sure nothing else is affected and then… it is anyways :wink:
Committing on master first allows other core developers to assess the issue without risking it first.
I just made a large fix for a bug in GeoTools image mosaic for images with heterogeneous CRSs,
it was a fix, but it was so big that I treated it as a feature, and let it stew on master for a month
before risking a backport.

Just sharing my 2 cents, don’t get mad at me :-p

Cheers
Andrea

···

On Thu, Jun 15, 2017 at 6:04 PM, Emanuele Tajariol <etj@anonymised.com> wrote:

Hi,

Ian, in GeoServer there are 2 stable branches + the master branch, so it’s good to have a starting point (master) and then move toward a single direction (backward) for porting the fix.
In GN there are 2 active branches, so I guess any direction for porting is good; anyway (@Maria) there is no info in the wiki page about how the fix should be ported forward.

Cheers,
Emanuele


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


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

2017-06-15 15:26 GMT+02:00 María Arias de Reyna <delawen@anonymised.com>:

On Thu, Jun 15, 2017 at 3:24 PM, Ian Turton <ijturton@anonymised.com> wrote:

Are you guys sure you want bug fixes to go to stable, wouldn’t it be better
to ug fix unstable (master) and back port to stable (released) branch. Other
wise you will reacquire bugs when you make a new release from master?

Branches always go forwards, not backwards. Everything on stable will
go to unstable. So the bugfix will go to unstable. Things pushed to
unstable will not be cherry picked to stable (or shouldn’t be).


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


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

==
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 di Montramito 3/A
55054 Massarosa (LU)
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.


Hi,

I added some explanation on how GeoNetwork works with branches:

https://github.com/geonetwork/core-geonetwork/wiki/Git-merge-branching-good-practices

On Thu, Jun 15, 2017 at 6:28 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

Hi,
humbly chiming in, mostly to explain why GeoServer has that direction for
bug fixes.

One has already been cited by Ian, to avoid losing them. In a perfect world
one would fix the stuff and then
port the fix to master as well, but life is sometimes a bit more
complicated, e.g, you fix the bug on stable,
then get into a meeting, or some emergency investigation, or a vacation,
whatever, and forget to do the
forward port. When the new master is released, months later, the issue is
going to regress.
Now, of course one can commit to master and forget to backport by the same
mechanics. It's still bad,
but you get feedback right away that it happened, and if you don't, well at
least the fix is going to survive in the future.

A second rationale is side effects. Again, in an ideal world, making a bug
fix is a simple, isolated activity.
But in practice, it happens that it's convoluted, sometimes it's large and
scary, let alone the cases in which
you are sure nothing else is affected and then.. it is anyways :wink:
Committing on master first allows other core developers to assess the issue
without risking it first.
I just made a large fix for a bug in GeoTools image mosaic for images with
heterogeneous CRSs,
it was a fix, but it was so big that I treated it as a feature, and let it
stew on master for a month
before risking a backport.

Just sharing my 2 cents, don't get mad at me :-p

Cheers
Andrea

On Thu, Jun 15, 2017 at 6:04 PM, Emanuele Tajariol <etj@anonymised.com>
wrote:

Hi,

Ian, in GeoServer there are 2 stable branches + the master branch, so it's
good to have a starting point (master) and then move toward a single
direction (backward) for porting the fix.
In GN there are 2 active branches, so I guess any direction for porting is
good; anyway (@Maria) there is no info in the wiki page about how the fix
should be ported forward.

   Cheers,
   Emanuele

2017-06-15 15:26 GMT+02:00 María Arias de Reyna <delawen@anonymised.com>:

On Thu, Jun 15, 2017 at 3:24 PM, Ian Turton <ijturton@anonymised.com> wrote:
> Are you guys sure you want bug fixes to go to stable, wouldn't it be
> better
> to ug fix unstable (master) and back port to stable (released) branch.
> Other
> wise you will reacquire bugs when you make a new release from master?
>

Branches always go forwards, not backwards. Everything on stable will
go to unstable. So the bugfix will go to unstable. Things pushed to
unstable will not be cherry picked to stable (or shouldn't be).

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
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

--

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 di Montramito 3/A
55054 Massarosa (LU)
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.

-------------------------------------------------------