Darrel O'Pry (darrel.o...@gmail.com) wrote: > The project has come along way since I first started following it a few > years ago. What is there now is a vast improvement over what I first found > which were the links to Rob's blog. It has been steady forward > progress.
Agreed. > I hear a lot of knee jerk throw everything out and start over undertones. I > don't that that is a wise idea as it loses history. One of the things I > love about git is history. Also being an agile developer I focus on > continuous improvement and rarely like to start things over. Exactly Darrel! I understand where the instinct for "let's start afresh" comes from, but really it's only sweeping ugly stuff under the carpet. And it's not just git history we'd risk losing - it's issue history, wiki history ... > I agree with a lot of Adam's points. Neither a new org nor a new repository > solve the issues with the existing repository. > > It also sounds like there are number of issues being conflated some > political, some technical, and some social. It would be a lot easier to > address them individually. Agreed. > If you put them all together it's going to end > up like congress and we all know how well that governing body functions. ;-) > They could all be git issues that are handled in the issue queue so the > individual conversations can stay a bit more focused in one place. Focusing > on the workflow issues... > > 1) Repository and workflow organization... > > Something that really helped my team was defining a branching strategy and > adhering to it. We used > http://nvie.com/posts/a-successful-git-branching-model/ as as starting > point and customized it to work for us. Making sure our branching and > merging worked well for all of our use cases and that the entire team was > familiar with our branching strategy and naming conventions has helped > keeping everyone on the same page. Right. And we're almost there - the only issue is in the main repo, and Victor already mentioned yesterday that he is on the way to a fix for this. > 2) On boarding new developers. > > We view our github repositories as an environment that caters to > developers. Our standard root README.md focused on onboard developers. The > first section is a quickstart that details setting up your development > environment to work on the latest release, checking out the code, building > the code and testing it. The second section is contributing which > describes out branching strategy, naming converntions, release workflow, > and how/where to submit pull requests. The branching strategy has a > walkthrough for hotfixes and long running feature branches. > > The most important thing we do to facilitate on-boarding new developers is > to make sure there is no confusion on how to fork, clone, run the code, > test the code and share a fix. Definitely agree on all this! Proper support for feature branches has been missing from our workflow for a long time: https://github.com/crowbar/crowbar/issues/1708 That's a good example of the kind of ugliness which will NOT be solved by creating a new organization. > Beyond that we go our of our way to make development across platforms easy. > We typically use virtual box and vagrant as a starting point to normalize > everyone's development environment and share the git checkout with the > vagrant. This way everyone is building on the same build environment. We > typically share the git checkout from the VM host to the build VM. The > build, run, test within the VM. You just expand the number of vagrants you > use to test on other platforms. I tend toward veewee if I need to build and > track any sort of super custom vagrant base boxes. > > Our usual getting start instructions read like.. > > install virtual box 4.2.18 > install vagrant > git clone g...@github.com/org/repo > cd repo > vagrant up > grunt test > > then it gets project specific Standardising the dev environment is a great idea. There's still some remaining work to do in order for this to be SUSE-friendly though. Most SUSE-oriented folk prefer KVM to VirtualBox, and last time I looked, vagrant's support for kvm / libvirt still needed work. This would be well worth completing. Secondly, building openSUSE-based ISOs is still a work in progress (I worked with John on this last weekend). > 3) Maintenance > > We use jenkins extensively to review our pull requests. We do a number of > smoke tests including linting to enfoce code style, fxcop/sniffing/etc to > look for common code mistakes, code coverage. We lean heavily on peer > review of pull requests. Our team is distributed and we don't always have > the luxury of pairing, instead we do a code review with each pull request > that includes a developer on the project and a developer from another > project. It serves to cross train, and have someone less familiar with the > project who will not take the knowledge one develops writing and working on > the code for granted. +1. Of course Crowbar doesn't use Jenkins yet, but it probably could in the future if we reduced the number of git repos and wanted to switch to it (I'm not religious either way - github is good enough for our code reviews IMO). > I know I don't participate in the crowbar discussion much, but I do spend a > lot of time working on Continuous Integration and Continuous Deployment > with distributed teams... Hope the ideas are useful... > > Thanks for all your work on crowbar everyone! Very useful input, thanks a lot Darrel :-) _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
