Welcome to SIG-Release, home of release and feature management. If you are new to this repository, you might find the getting started guide useful. If you are interested in the current state of planning, have a look at our Release Planning Board
We follow a coordinated approach to plan improvements of Eclipse Tractus-X. see also Open Planning and Refinement.
While every repository in the eclipse-tractusx GitHub organization has its own issue management, the Release Planning Board is used to align the overarching Tractus-X releases.
In case you experienced a bug, unexpected behaviour, or you want to propose enhancements to Eclipse Tractus-X, feel free to use one of the provided issue templates and describe your request. Please be aware, that not every feature request can be integrated and that we also cannot treat every issue with the highest priority.
Every Release planning will be kicked off by two public alignment sessions. The dates and further details will be shared via tractusx-dev mailing list. In addition to that, you can also find public meetings and info about how to join on our Open Meetings community page. Issues or bug reports, that should be discussed in these meetings, have to be opened prior to the meeting via our issue templates.
We really welcome every contribution. Every Bug report and feature proposal takes time to prepare, is valuable to our project, and we very much appreciate this input. We are giving our best to give a first feedback in one week. If we should miss that, please stick with us and just use the commenting function to remind us of the issue.
Our issues do have important properties, that enable our planning process. These are:
- Labels: We use them to indicate the involved teams (kit or foss component). A label for each involved component is added to an issue
- Issue Type: To separate between bugs, feature requests and release criterias, we use a custom field
Issue Type - Milestone: Every Tractus-X release is represented by a
Milestone. You can use this field to get a rough idea about the ETA - Status: The status field is used to integrate the progress of an issue
The following statuses are defined:
- Inbox: This is the initial status of all issues. It indicates, that involved components have to be identified and additional information gathered
- Backlog: If enough information is gathered, and we agreed to work on the issue, it is set from
InboxtoBacklogto indicate it is ready for timeline planning - Work in Progress: The issue is actively been worked on.
- Done: All relevant parts have been implemented and released
Every new feature proposal or bug report will be handled as issue in status Inbox initially. The alignment meetings are used to discuss the purpose and impact of the current issues.
While in Inbox status, the involved components are discovered and respective Labels are added. If already possible, a desired Milestone can be set.
Additionally, an Assignee is selected, who will coordinate efforts to solve the issue.
After these details are clarified, an issue is moved to Backlog to open it for detailed timeline planning. In this status, discussions about a fitting Iteration is held.
As soon as actual work is started in the selected iteration, the issue is set to Work in Progress. This is especially helpful on our project milestone views to get an overview of the release progress.
The final status Done is set, as soon as all relevant implementations are done, tested and released. This has to be achieved for every change in every involved component.
While the Release Planning Board is used to coordinate overarching feature and bug requests, we encourage every component team to break these issues down to their component repositories/projects. When doing so, make sure you link to the overarching issue in your component issue description.
The release participation can be initiated by creating issues for the acceptance criteria check from the Issue templates. Each release the templates for the acceptance criteria will be renewed. There are two paths for processing the acceptance criteria for an application team to participate in a release.
Select issue type "release_ac" to make the issue visible in the Release Management Kanban Board. Futhermore select the appropriate milestone to distingush the ticket from other releases.
The three process steps to get to the status you need to pass the Q-Gate are shown in the happy path process flow.
Each acceptance criteria issue in GitHub contains a note with the prime contacts so that it is clear who is the assigned expert or release manager.
If the evidence is not sufficient so that the criterium can not be accepted in the quality gate (QG), obligations for the product team will be defined to make a reassessment.
This work is licensed under the Apache-2.0.
- SPDX-License-Identifier: Apache-2.0
- SPDX-FileCopyrightText: 2022,2023 Contributors to the Eclipse Foundation
- Source URL: https://github.com/eclipse-tractusx/sig-release