Ever wanted to help out in the development of Ubuntu Server, but did not know how? One of the best ways to get started is by working on bugs. Not only does it improve the distribution for millions of users, but also gives you an opportunity to see how the distribution is made.
I am publishing this after a year of learning various commands, tools, and processes that revolve around fixing bugs. I hope that it is helpful to others who are interested in getting involved with fixing bugs in Ubuntu Server.
The Ubuntu Server team has many hundred source packages that it is responsible for. Resolving bugs in these packages is essential to the overall quality and experience of the release. For newcomers, tackling bugs is also a great way to get involved in the development of Ubuntu and to learn more about open source development.
Here is a summary of the steps I will go over:
If you are interested in either reporting bugs or fixing bugs in Ubuntu you need to have an account on Launchpad. Launchpad is where the development of Ubuntu is tracked. Bugs, source, planning, packages, and much more are all tracked in Launchpad. To get going with Launchpad I recommend reading through the Get set up to work with Launchpad section of the Packaging Guide.
The server team maintains a list of bugs in a backlog that needs to be fixed. This a curated list of bugs that have already undergone triage and have been deemed actionable. That is, a member of the server team, has reviewed the bug to validate that there is some action required and sufficient information exists to preseed on resolving the defect.
There are also two subsets of the backlog as described below:
The first subset of the backlog are bugs with the tag server-next. These are high priority bugs that should be tackled next and as a result is a great place to look for bugs.
The second subset of bugs with the tag bitesize. As the name implies, these bugs are small in size and potentially great for beginners.
Now that you have a list of bugs it is time to choose one. Choosing something to work on can be both intimidating and daunting given the amount of information each bug may or may not contain. If you are new, the best suggestion is to start with a bitesize tagged bug and jump into it, ask questions in IRC or on the bug itself, and determine what work is required.
Another way to select a bug is to find a source package or a package source in a programming language you are familiar with: if you are a fan of Python look for Python source packages.
Finally, try giving the list of server-next tagged bugs a look. These bugs need to be fixed and are tagged next for a reason.
Once you have decided to work on a bug, you need to make sure others know you are working on it. This step is very important for a number of reasons:
To do make sure the bug is not assigned to anyone. At the top of the bug in the row should show “Assigned to” as “Unassigned” like the picture below:
If you are logged in, press the yellow circle with a pencil. On the new window, select “Assign me” and the bug will not be assigned to you:
You will want to make sure you receive any email notifications about the bug status or additional comments that are made on the bug. To do this on the right-hand side, inside of the 4th box from the top, click “not directly subscribed to this bug’s notifications.”:
On the new window, select “Receive all emails about this bug” to have all updates sent to you:
Finally, add a comment to the bug stating your intention to work on the bug. You are not signing your life away and forcing yourself to resolve the bug. Again you are communicating out to the world that you are trying to develop a fix.
Something like the following would work:
Hi! I am taking the bug and will attempt to drive it to resolution. I will be work on proposing a fix and proposing a merge to get this fixed.
You can also consider adding the following information:
I'll be using the fix from <here>
I am targeting to fix in Xenial and Artful.
This is my first bug, but I will give it my best.
To do this, scroll to the bottom of the page, enter your message in the text box, and press “Post Comment”:
Fast-forward a few weeks (or months) and maybe you find yourself unable to fix the bug? Do not have time to devote to fixing it? Changed your mind? Then what do you do?
Essentially reverse the last step:
Do not be embarrassed to say you could not solve the bug or you do not have time. Both of those are far better than never saying anything all, leaving people wondering.
I do suggest staying subscribed to the bug in case someone has questions for you, after all, you did spend some time working on the bug and your experience may still be helpful to others!
Here is a quick summary of the items laid out above:
With a bug in hand, it is time to start the process of developing the fix, submitting a merge request, and testing the proposed package.
The leading platform for scale-out computing, Ubuntu Server delivers the best value scale-out performance available.
In 2016, 16% of all workplace deaths in the US were attributed to falls. Apellix, a Florida-based start up, who specialise in aerial robotics aims to reduce this number by using their drones in place of workers to complete tasks in…
Hello Ubuntu Server The purpose of this communication is to provide a status update and highlights for any interesting subjects from the Ubuntu Server Team. If you would like to reach the server team, you can find us at the #ubuntu-server…
The purpose of this communication is to provide a status update and highlights for any interesting subjects from the Ubuntu Server Team. If you would like to reach the server team, you can find us at the #ubuntu-server channel on Freenode.…