Project & Release Tracking for Xen - Part 2
As promised, and following previous blog (see below), I am going to present you how the Xen project will manage to track and follow the Xen Project itself but also new releases and even bugs, using Gitlab.
Marc Ungeschikts
A quick reminder of the main targets
- Facilitate & improve engagement and discussion between external stakeholders and the Xen community.
- Give the ability to the Xen release manager to track the new release advancement and see potential bottlenecks and release blocker.
- Give more visibilty to the bugs discovered, in order to help Xen developers and maintainers to decide on which issue to focus.
How will we manage it?
Now let's see how we'll manage each part, from the project itself to the bugs, while also talking about the releases. Have a good read!
Xen Projects Tracking
Beyond the initial target, here at Vates, we wanted to help anyone to take a look on what's going on in this great open source project. Let's see that in details!
Everything will happen in Gitlab with the xen-project group [1]
[1]: Not to be confused with xen project, which is a sub-project of xen-project group (since the Xen Project organization itself hosts various projects, including… Xen, the hypervisor).
EPICs to the rescue
We'll rely on using Gitlab EPIC to define main topics (like porting Xen to RISC-V), identify the stakeholders (who is leading this change/new features), and categorized EPICs with labels, define their status and give an estimation of difficulty, effort and finally priority.
For more details, on how to create an Epic and assign labels you can have a look on the following Epic template - (the Wiki page is in construction).
You can also view the status on 2 different Epic boards:
- Backlog triage: To help on following status of Epics on triage or discussion stage.
- Epics Status: To give a view of Epics which Xen community started to work on.
A global visibility
It's important to know who can participate. It's great that now anybody with or without a Gitlab account can see xen-project EPICs and EPIC Boards. This is truly improving the Xen Project visibility!
To create an Epic though, or change labels, if you don't have it already, you will need to request access to the xen-project group. Which is logical since writing requires more permissions!
Finally, Epics can be be created and updated at anytime by xen-project group members. Backlog meetings will be organize frequently (at least every quarter) to do the triage and check status and labels.
Xen Releases tracking
Tracking a release is a big task. You want to know when to cut it, to make your code freeze, and take decisions depending on what's left.
This will be also handled in the Gitlab xen-project group. This time, we'll use Gitlab Issues created in xen project but viewed from xen-project group:
Gitlab Milestones are used to define a target "Xen Release" version. And Gitlab label types to identify the type of issues:
To follow the release progress, we'll rely on Issue boards:
The following people have the capability to create and update issues candidate for a Release:
- a Xen Release manager
- Xen Developers
- Xen Maintainers
But anybody can view Release advancement looking ot Xen issues boards with or without Gitlab account!
A note on the chronology
Issues can be created at anytime but need the Xen community approval to be assigned to a Release (Milestone). Also, issues status has to be updated by Xen Developers, Maintainers, and the Xen Release Manager, when relevant.
This is really important to keep up, otherwise the whole setup will be a lot less relevant.
Finally, release issues will be followed by the Xen Release Manager during all the release development using the "Release boards".
Xen Bugs tracking
This is a kind of very new usage of Gitlab for the Xen Project. Historically, everything was on the mailing list. Let's say it wasn't really convenient to track things just by using an email client.
And you can guess now it's happening directly in the Xen Project namespace: xen project.
Note: It's not the xen-project group, which is the parent group of xen project itself.
Obviously, using a Gitlab issue with label type bug is the right way:
Then, it's suddenly a lot easier to see all the issues in an "Issue board" called Bug Tracking:
For now, bug tracking is targeted for the use of Xen developers and maintainer mainly, and under the watch of the Xen Release & Project Manager. It's important to keep it "clean" as possible, with very detailed bugs so it can be treated correctly and efficiently.
Note that issues can be created at anytime. However, bug tracking has to be followed at least once a week by Xen Release Manager and/or Xen Project manager to check Bug backlog is under control (Critical and High Severity in progress and total number of bugs reasonable).
I'll do my best to be sure those tools stay under control and follow a proper "hygiene". In the past, various trials has been made, but it's hard to keep up when you are a developer, already VERY busy with actual code to write or debug. In other words, my role is to assist everyone involved in the Xen Project with those tools, to keep track on what's going on without generating any extra burden to the existing contributors.
