>From the peanut gallery... 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. 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.
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. 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. 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. 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 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. 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! On Wed, Nov 20, 2013 at 4:39 PM, <sakvinder_...@dell.com> wrote: > *Dell - Internal Use - Confidential * > > +1 A more structured and clean environment will aide in future development > as well as testing, it’s a definite need. > > > > Sak > > -----Original Message----- > From: crowbar-bounces On Behalf Of Adam Spiers > Sent: 20 November 2013 17:31 > To: crowbar > Subject: Re: [Crowbar] Crowbar 2 Hack Report > > John Terpstra (john_terps...@dell.com) wrote: > > The fact that Crowbar has a high barrier to new participants is > > undeniable. It is of utmost importance to the future of the project > > that the obstacles to entry of new developers must be removed. > > Agreed! > > > The positive steps to remove barriers should result in: > > > > a) Greater recognition that Crowbar is an Open Source and > Community-driven project > > Right. Recognition will come only if the project becomes truly > community-driven. > > > b) Ability to readily identify the exact code repositories that > make up all components of the Crowbar project > > Yes. Architecture quickstarts, reduction in the number of repos, and > simplification / elimination of a monolithic dev tool would address this. > > > c) Improved information - Ready ability to find and locate all > essential documentation (web as well as documents) > > Yes! > > > d) Ease of getting from start to effective and efficient code > development/production > > Yes! > > > e) Easy to get new organizations on board in support of the project > > Yes! > > > Achievement of these achievements (in my opinion) validates any > > challenges of efforts required. > > Agreed! > > > The new information resources should point to all the old Crowbar 1.x > > code and documentation. > > I don't understand the logic behind this last statement. Currently we > have one set of crufty docs. Creating another set which points back to it > is going to hinder not help the above goals. > > _______________________________________________ > Crowbar mailing list > Crowbar@dell.com > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/ > > Dell Corporation Limited is registered in England and Wales. Company > Registration Number: 2081369 > Registered address: Dell House, The Boulevard, Cain Road, Bracknell, > Berkshire, RG12 1LF, UK. > Company details for other Dell UK entities can be found on www.dell.co.uk > . > > _______________________________________________ > Crowbar mailing list > Crowbar@dell.com > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/ >
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
