[Opendnssec-develop] Move to git

[Jerry Lundström]

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

> Of course, you could in theory batch several bug fixes into one pull request (if they are for the same branch), but that then means they all have to wait for the whole batch to completed, reviewed and accepted. So maybe some common sense about what to combine in a pull request is needed? For example, if someone else needs a bug fix quickly, then you have to create a separate feature branch but if you are working on a bunch of small fixes, maybe just create one feature branch, put all the fixes in that and then do the pull request. Jerry/Jakob - you are not going to reject pull requests that fix more than one JIRA issue are you? ;-)

No why should we. If you do a pull request for many small bugfixes at the end of the day thats all fine, just remember to commit each fix for it self with the correct Jira tag. In this way just that fix will be related to the Jira issue and not all of them. It will also make it easier to see what has been done for what issue and to remove fault commits or just cherry pick a few.

> Also, if a fix is dependant on an earlier fix (say, fix D depends on fix A), then the developer has to wait for the pull request for A to be accepted before they can start on fix D (or if they have already started) being able to pull down those changes, rebase the feature branch, finish the work, push and create a pull request for D. If Jerry/Jakob are busy or the pull request needs to be reviewed by somebody who isn’t around today then the developer just has to wait. There is no nice shortcut here, right?

There are plenty BUT you need to know git and since people are just starting to work with git this is not something you start with. You really REALLY have to know how git works!

All the “if this” “if that” are also many moment 22’s. I don’t think its wise to try and think of the worst situation here because most of them should not happen when this workflow is in place. You do not need to make a pull request to fix the broken code because it should not be broken in the first place thanks to this workflow and ALL the tests we do. But even if that happens it will be very rare occasions and very specific situations and that will be manageable.

> Have I understood all this correctly? If so, then at first read this process feels like a very heavy overhead compared to what we do now with svn because
> a) there are lots more steps and lots more commands needed
> b) I need a work area for every pull request, rather than just one per branch
> c) there are additional dependancies on other people, none of whom work full time on ODS
> d) there is an additional lag in waiting for pull requests to be processed

This is correct IF you want the code to the upstream! There is nothing stopping you from working with your fork just like you do in SVN now.

> I can see the bigger picture benefits of git but this workflow doesn’t immediately seem to make developers daily lives any easier :-(
> ….but then I am probably stuck in my svn ways….Note to self: must drink the git kool-aid...

Best way to learn git is to use git and you really need to use it to understand it.

--
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/20140205/abf8c9d6/attachment.bin>