[Opendnssec-develop] Move to git

[Jerry Lundström]

On 06 Feb 2014, at 15:12 , Sara Dickinson <sara at sinodun.com> wrote:

> 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”?

Fixed.

> - 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? 

You should only remove your feature branch after it has been merged and before that you should have made a copy of that feature branch to make pull request for another major version.

If its already merged and you have removed your feature branch you can cherry pick the commits into a new feature branch and make a new pull request for a different major version.

> - 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?

That is true.

> - 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?

Ehm, no you don’t merge, you cherry-pick (yes its a actual git command).

I can try and add some doc on that.

> - 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?

Well yes and no, GitHub will tell you if the pull request will merge cleanly or not, if not then you need to update your feature branch with the changes made in the develop branch its based on and rebase and fix the conflicts.

> 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?

We can add more later on but to begin we got “build” now and it runs all tests, new and modified, which is just what happens now if you do a commit.

> 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? 

This is what I’ve been saying many times now, we need to rework how and what we run at each stage. As low as possible is the goal.

> 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?

Do we really need this in writing now? Think common sense here will prevail.

> 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? 

We can do both or just one, we can collectively decide per pull request based on the changes. The initial plan is to run all test because it was the easiest to get working at first (see “build” above).

--
Jerry Lundström - OpenDNSSEC Developer
http://www.opendnssec.org/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 625 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.opendnssec.org/pipermail/opendnssec-develop/attachments/20140206/5c98c21f/attachment.bin>