[GRASS-dev] Merging PRs

GRASS GRASS developer
1

Greetings Developers,

In https://trac.osgeo.org/grass/wiki/HowToGit, it is not clear who is responsible for merging PRs when. Are individual core developers encouraged (allowed?) or discouraged to merge them? I’m talking about core, not addons. How does it work?

The main reason why I ask this question is because merging PRs into the upstream master takes time and I cannot wait until that happens (who, when?) to compile all my PRs into one build.

If you create multiple branches off of master and create PRs, it wouldn’t be easy to keep track of all those individual branches in one place and compile the personal “latest” version until the PRs get merged. For example,

  1. master => feature1
  2. master => feature2

Compiling feature1 and feature2 branches would only give me feature1 and feature2, respectively, but not both. Should I do something like this?

  1. master => feature1
  2. feature1 => feature2

Then, how can we make sure that there won’t be any conflicts between my feature2 (<= feature1) branch and the OSGeo master?

Not sure if what I’m doing is “right,” but I’m doing this:

  1. create a personal master branch “hcho” (yes, my name)
  2. master => feature1
  3. master => feature2
  4. merge feature1 and feature2 into “hcho”
  5. compile “hcho”

To be honest, it’s a lot of work :-(. Any suggestions or hints would be very welcome.

Best Regards,
Huidae

···

Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE
Open Source GIS Developer, GRASS GIS Development Team

2

On Fri, Jul 12, 2019 at 4:23 PM Huidae Cho <grass4u@gmail.com> wrote:

Greetings Developers,

In https://trac.osgeo.org/grass/wiki/HowToGit, it is not clear who is responsible for merging PRs when. Are individual core developers encouraged (allowed?) or discouraged to merge them? I’m talking about core, not addons. How does it work?

The main reason why I ask this question is because merging PRs into the upstream master takes time and I cannot wait until that happens (who, when?) to compile all my PRs into one build.

If you create multiple branches off of master and create PRs, it wouldn’t be easy to keep track of all those individual branches in one place and compile the personal “latest” version until the PRs get merged. For example,

  1. master => feature1
  2. master => feature2

Compiling feature1 and feature2 branches would only give me feature1 and feature2, respectively, but not both. Should I do something like this?

  1. master => feature1
  2. feature1 => feature2

Then, how can we make sure that there won’t be any conflicts between my feature2 (<= feature1) branch and the OSGeo master?

Not sure if what I’m doing is “right,” but I’m doing this:

  1. create a personal master branch “hcho” (yes, my name)
  2. master => feature1
  3. master => feature2
  4. merge feature1 and feature2 into “hcho”
  5. compile “hcho”

To be honest, it’s a lot of work :-(. Any suggestions or hints would be very welcome.

Yes, I agree, this is a lot of work. git is convenient for contributors, but a lot of work (much more than with svn) for maintainers.

If your PRs are incremental, i.e PR for feature 2 requires PR for feature 1, it would be easier to have only one PR with several commits.

I tend to merge your PRs related to MS Windows builds, but I can not test. OTOH, testing by others occurs more likely if the changes are in master, not in a PR.

Any opinions on merging PRs related to MS Windows builds to master without testing by another person?

Markus M

3

Any opinions on merging PRs related to MS Windows builds to .>master without

testing by another person?

more description why the changes and more testing before merging is welcome.

it seems there is some windows dll hell issue at the moment which should be
solved before the PRs can be tested. further some of the related winGRASS
tickets are labelled als fixes, thus more description why again changes are
welcome.

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html