Re: [GRASS-dev] Merging PRs
>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 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Merging PRs
On Fri, Jul 12, 2019 at 4:23 PM Huidae Cho 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Merging PRs
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 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
