So you created an awesome pull request with a couple of features, but the evil(?) maintainer (could be me) just denied it and said you shouldn’t make pull requests from master? Then you’ve come to the right place to learn what went wrong and how to fix it.
Current (Incorrect) State
Looking at the history of your repository, it probably looks something like the image to the right. There’s a base commit and then you’ve added one commit for each of the features to it. And everything is done on the branch master.
The image was created with Git Extensions. Although I prefer using the command line when working with git, having a tool that can display the branches and commits graphically is indispensible to understand what’s happening.
Doing everytying on master as shown in the image is wrong for a couple of reasons that might not be obvious when first starting working with git.
Every single feature should be created in its own branch. Branches are so lightweight in git that it’s okay to branch all the time.
Submitting a pull request from your own master branch is a recipe for disaster, as it effectively prevents you from getting the latest code from the upstream repository (more on that later).
Unfortunately it’s easy to end up in this situation with git. Fortunately, it’s also quite easy to fix.
It’s call for papers season and I’m preparing abstracts and sending them off hoping that I’ll be accepted with my talks. What surprises me is how huge quality difference there is between different conferences in their call for papers (CFP). It’s basically anything ranging from very detailed information to a mailto: link.
I still have quite limited experience in submitting to conferences (and even less experience of being accepted). But when looking at what’s in a good CFP I think that is actually an advantage. A seasoned speaker will know how to write an abstract and what to expect – and what to demand(!) from the conference organizers. Someone less experienced need more information. To get relevant content and a wider selection of speakers it should be in the interest of conference organizers to have a good CFP.
This is a guest post by Albin Sunnanbo introducing a great hack to work with mails in test environments.
If you have a .NET application that sends emails, this is probably something for you.
PickupMailViewer is a simple web viewer for emails saved by the specifiedPickupDirectory SMTP setting in a .NET application.
Download the source, publish to your test server, configure pickup directory and you should be up and running within five minutes.
IMHO that is the way to go regarding emails in your test environment.
However, there is one drawback, the emails gets dropped in a folder somewhere on your test server. Typically in a location that nobody looks at regularly. In my case I first have to connect a VPN, then open a remote desktop connection to our server, open the folder and copy the desired file back to my own computer (no eml viewer, a.k.a. Outlook, on the test server) and finally open it in Outlook.
Even worse for our testers that don’t even have permissions to login on the test machine. They have to ask a developer to get their emails out of the test system. As you can imagine this only happens when it is absolutely necessary.
To write an awesome pull request is not that hard, but requires a bit of planning and reading up on tools.
Add an issue describing the feature before coding. It’s an opportunity to get feedback both on the suggested feature and on how to make it fit with the existing design/architecture.
Learn git. As a minimum you need to know how to fork the main repository, create feature branches and how to rebase them on a refreshed master pulled from the main repository. Check out the contribution guidelines from Nancy for details.
Limit each pull request to a single issue/feature. It’s much easier to review and discuss multiple small focused PRs than one large complex.
So you have Resharper and found a bunch of unused usings and other things that should be cleaned up? You’re welcome to submit those non-functional changes in a separate pull request.
Run any existing tests and make sure you didn’t break anything.
Make sure your code meets the test coverage expected and coding standard in the project.
Respect the architecture of the existing code. For example in AuthServices that supports both IIS and Owin hosting, it’s not acceptable to reference System.Web from most parts of the code.
A Gift to Who?
Finally I’d like to mention the view of pull requests as gifts. I totally agree with viewing pull requests as gifts. But not only a gift from the contributor (sending the PR) to the maintainer (receiving the PR), but also from the maintainer to the contributor.
I give you this code that I have written to improve your project.
I will take care of your code by reviewing it, maintaining it and take responsibility for any bugs in it.
This post was inspired by a similar post by Mark Seemann. It’s very good (although more lenghty than this), so I recommend reading it.
Is politics agile? Hardly. Can politics benefit from an agile mindset? I don’t know, but I’m running an experiment. Besides working as a developer and doing some open source coding (which is what I usually blog about) I’m also a part time politician (for the greens in the municipality assembly of Huddinge, in Stockholm county, Sweden). If anyone’s up for a political discussion, I’m into it, but this post is not about it. This post is about an effort I’m doing to bring some of the Agile mindset into politics.
In a municipality in Sweden, there is the municipality assembly, the municipality executive committee and a number of committees for various purposes such as school, preschool, social care etc. For all of these, there are MASSIVE amounts of decisions to be made, with even MORE MASSIVE amounts of background material. For a single meeting with the municipality assembly, the pile of paper to read is often about 10cm thick. In this massive pile of paper, there is often some interesting details that we in the green party would like to somehow act on. When we get the pile of paper, there are two questions that we need to answer:
What things do we want to act on?
How do we best act on those?
When we have got all the material, we have an internal preparatory meeting where we discuss those two questions. When I first joined those meetings, I found them quite inefficient. So I suggested that we tried another way of working – and brought Trello to help.