[Opendnssec-develop] Move to git

[Sara Dickinson]

Hi,

So, some other questions and comments:

Workflow:

- On the workflow wiki page, in the bullet point describing what to do when a pull request is accepted it says “It is VERY IMPORTANT that you now DELETE YOUR USER REPOSITORY”. Shouldn’t this say “It is VERY IMPORTANT that you now DELETE YOUR USER FEATURE BRANCH”?

- I think we should add a note at this point in the instructions to say that if you want to use the feature branch to port the fix to a different release you need to keep it? 
- Also, am I right that the re-basing approach only works if you want to port _everything_ in that feature branch? So it if contains various fixes this isn’t the best way to port them?
- If you do delete your feature branch, or need to cherry pick commits to port them then I imagine you use ‘merge’? Jerry - could you please document this workflow too as I suspect this is going to be much more likely in practice than being able to do a clean rebase?

- I presume it is good practice to update your fork and feature branch with changes from upstream right before doing a final test and creating a pull request? If so could we add that comment to the first bullet point this page?

Pull requests:

It is still not clear to me exactly what happens with the review stage or the tests. Jerry - I saw your email describing what build-bot commands are available, which look good. I see there is:
"build - Build and run all tests”  For ‘build’ when you say ‘all tests’ do you mean _all_ tests, or all the smoke tests? What about, to begin with we have
build                    - Build
build smoke_test - Build and run smoke tests 
build mod_test     - Build and run smoke and modified tests
build test              - Build and run all tests
I think have the first 3 as separate actions would give developers the most flexibility to run and fix builds/tests by themselves without having to involve anyone else?

So I think we still need to decide what happens in a normal case on a pull request…

a) I really like the idea that developers can create a pull request and initiate a build and run the smoke and/or modified tests before anyone else looks at the request. This sounds like the right thing to do in most cases. But if so, we should make sure our current smoke tests run in, say 5 or 10 mins max? 

b) Then who decides who should review it? 
- Seems sensible that the developer should requests a specific reviewer in the pull request comment if they want one? 
- If it doesn’t need a full blown review what happens - Jerry/Jakob will you give it the once over to see what you think? 
- If we want to give other developers who will be watching the pull requests time to comment how long should we wait before moving forward with the process? 

c) Then after this, what additional testing is done before the pull request is actually accepted? If we don’t run all the tests, then it is possible for the PR (see - I’m learning the lingo!) to be accepted and then break a test, but the tests take a long time. Is the initial plan to run all the existing tests on every pull request?  Also, who is responsible for this stage - the developer or Jerry/Jakob? 

Sara. 


On 4 Feb 2014, at 16:11, Yuri Schaeffer <yuri at NLnetLabs.nl> wrote:

> Signed PGP part
> >> Imagine -for argument sake- the bugfix is for "ODS does not
> >> compile”.
> 
> > That is not a good example since that would never really be merged
> > into the upstream since all pull requests are compiled and tested.
> 
> Fine. what about:
> Imagine -for argument sake- the bugfix is for "ODS does not compile on
> computers with a pink keyboard”.
> 
> >> My impression of Git was that each commit can be uniquely
> >> identified. Thus applying commits to multiple branches and then
> >> merging them does not cause conflicts [for those commits]. But
> >> that is not true?
> 
> > It might work but it will most likely make the order in your tree
> > wrong and you can get problems later on.
> 
> ack.
> 
> 
> --
> Composed on an actual keyboard: all typos genuine.
> 
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop