Goal:
I'd like to have the release process defined in markdown/git and use it as a source for process creation in redmine.
openSUSE Leap Release process definition currently lives inside redmine, from where we copy it from release to release via the integrated copy/clone functionality.
The plan is to create it directly from Git and benefit from issues/pull request for the coordinated process improvements. The Tool which SLE uses to create Jira from Markdown is here https://github.com/opensuse/md2workflow, so we essentially need to add just the redmine support.
Reasoning I have really good experience with co-operating within larger team on the process improvement via gitlab/issues and I believe that opensuse would benefit from it as well. We'd set some standards such as "Definition of Done" for the task (when the task can be resolved). I also believe that this would bring more transparency in between community and Release Management.
The benefits were clear, process is more and more follow-able by everyone within the team and task instructions. Set and enforce some process standards via git hooks/github ci, e.g. every task needs to self-contain definition of done. And it could be easy to unify some process steps between leap and SLE.
Useful links:
Current improvement backlog for the SLE process. https://gitlab.suse.de/sle-prjmgr/release-management-checklist/issues
SLE-12-SP5 process overview in JIRA https://jira.suse.com/secure/RapidBoard.jspa?rapidView=1441&useStoredSettings=true
Release Management Checklist documentation https://confluence.suse.com/display/projectmanagement/Release+Management+Checklist
openSUSE Leap process overview in Redmine https://progress.opensuse.org/projects/leap_152/issues/gantt
Tool which is intended to create both JIRA and newly redmine process (this would be part of the hackweek excercise): https://github.com/opensuse/md2workflow
*How can you participate? * Feel free to check available tasks with hackweek19 label: https://github.com/openSUSE/md2workflow/issues https://github.com/openSUSE/openSUSE-release-process/issues
This project is part of:
Hack Week 19
Activity
Comments
-
almost 6 years ago by lkocman | Reply
Just a brainstorm github.com/opensuse/how-to-release sounds more sexy than /opensuse-release-process which is otherwise more accourate
-
almost 6 years ago by gameboy974 | Reply
I disagree : ) opensuse-release-process is simpler and more accurate therefore more sexy ; )
-
-
-
-
almost 6 years ago by lkocman | Reply
I've just created https://github.com/openSUSE/md2workflow/tree/hackweek19
People who want to help can check https://github.com/openSUSE/md2workflow/issues/11 which is a task to support redmine. We essentially want to replicate md2workflow/backend/jirabackend.py but for redmine (including task depedencies and so on). I could use a help on this one as long as people are willing to write some basic tests as well.
-
-
-
almost 6 years ago by lkocman | Reply
https://github.com/openSUSE/md2workflow/issues/16 Was resolved. This unblocks bunch of other tasks. You can now export redmine to markdown (example is the attached single-dump.txt to the Issue 16).
First task for myself is to replace initial tree with the output from lkocman@deadrat:~/Workspace/md2workflow> bin/redmine2md ~/Workspace/opensuse/openSUSE-release-process/redmine-export-openSUSE-Leap-15.220200205.csv
Fortunately we can use --target-version to e.g. Chose only tasks for Alpha and dump them to the file and so on. I expect also a lot of issues without Target version set, so these will require manual placement to e.g. unsorted.md This will unblock more tasks in openSUSE-release-process
What I'd really appreciate as a help is to create a simple ical integration. https://github.com/openSUSE/md2workflow/issues/17 This might be as easy as adding markdown variables (Start date: YYYY-MMDD, Due Date: YYYY-MMDD and Schedule item: MATCHING NAME from .ical) and simply be able to pair these with values from .ical file which could be passed as an argument to bin/md2worflow --env local (--ical-file FILE) example/my_project.conf
-
almost 6 years ago by lkocman | Reply
Initial import is done! This unblocks whole bunch of tasks for
Just out of curiousity I did try to import openSUSE Leap 15.2 instructions to JIRA to see how it would look like. Fortunately there were no issues/errors raised during creation.
Stdout from md2workflow with jira backend: http://pastebin.suse.de/25600 Backlog: https://jira-devel.suse.de/secure/RapidBoard.jspa?rapidView=1492&view=planning&selectedIssue=RMC-2258 Kanban board: https://jira-devel.suse.de/secure/RapidBoard.jspa?rapidView=1492&view=detail&selectedIssue=RMC-2229
(tasks states are random, data might be trashed in about a week or so, as this is a devel instance of jira)
-
-
-
almost 6 years ago by lkocman | Reply
Just a tip for testing api by using a ad-hoc container running redmine instance https://hub.docker.com/_/redmine ` sudo docker pull redmine sudo docker run --name hackweek19-redmine redmine sudo docker inspect hackweek19-redmine | grep '"IPAddress":' "IPAddress": "172.17.0.2",
grep redmine /etc/hosts 172.17.0.2 redmine-local `
-
-
-
-
almost 6 years ago by lkocman | Reply
So I have the local redmine creation done. However I figured out that you can't create the entire stack of layers by yourself as redmine api does not support adding Tracker. It supports only .get() for this Resource.
Therefore I can create project -> subproject -> targetversion -> (NOT tracker) -> task -> subtask Reansonable sounds to have setup of Project and Subproject in advance together with tracker. While targetversion, task subtask gets created by the tool. https://python-redmine.com/resources/tracker.html
-
-
almost 6 years ago by lkocman | Reply
I think I'm 80 percent done with coding part. Just small correction in issue relations and schedule integration. That would be topic for tomorrow.
Last code is available here https://github.com/openSUSE/md2workflow/pull/22 and https://github.com/openSUSE/openSUSE-release-process/tree/hackweek19
-
-
-
-
Similar Projects
Create openSUSE images for Arm/RISC-V boards by avicenzi
Project Description
Create openSUSE images (or test generic EFI images) for Arm and/or RISC-V boards that are not yet supported.
Goal for this Hackweek
Create bootable images of Tumbleweed for SBCs that currently have no images available or are untested.
Consider generic EFI images where possible, as some boards can hold a bootloader.
Document in the openSUSE Wiki how to flash and use the image for a given board.
Hack Week 22
Hack Week 21
Resources
Song Search with CLAP by gcolangiuli
Description
Contrastive Language-Audio Pretraining (CLAP) is an open-source library that enables the training of a neural network on both Audio and Text descriptions, making it possible to search for Audio using a Text input. Several pre-trained models for song search are already available on huggingface
Goals
Evaluate how CLAP can be used for song searching and determine which types of queries yield the best results by developing a Minimum Viable Product (MVP) in Python. Based on the results of this MVP, future steps could include:
- Music Tagging;
- Free text search;
- Integration with an LLM (for example, with MCP or the OpenAI API) for music suggestions based on your own library.
The code for this project will be entirely written using AI to better explore and demonstrate AI capabilities.
Resources
- CLAP: The main model being researched;
- huggingface: Pre-trained models for CLAP;
- Free Music Archive: Creative Commons songs that can be used for testing;
- Colab: To be used as the development environment;
- hw25-song-search: Github repo of the project.
Enhance git-sha-verify: A tool to checkout validated git hashes by gpathak
Description
git-sha-verify is a simple shell utility to verify and checkout trusted git commits signed using GPG key. This tool helps ensure that only authorized or validated commit hashes are checked out from a git repository, supporting better code integrity and security within the workflow.
Supports:
- Verifying commit authenticity signed using gpg key
- Checking out trusted commits
Ideal for teams and projects where the integrity of git history is crucial.
Goals
A minimal python code of the shell script exists as a pull request.
The goal of this hackweek is to:
- Add more unit tests
- Make the python code modular
- Add code coverage if possible
Resources
- Link to GitHub Repository: https://github.com/openSUSE/git-sha-verify
Improve/rework household chore tracker `chorazon` by gniebler
Description
I wrote a household chore tracker named chorazon, which is meant to be deployed as a web application in the household's local network.
It features the ability to set up different (so far only weekly) schedules per task and per person, where tasks may span several days.
There are "tokens", which can be collected by users. Tasks can (and usually will) have rewards configured where they yield a certain amount of tokens. The idea is that they can later be redeemed for (surprise) gifts, but this is not implemented yet. (So right now one needs to edit the DB manually to subtract tokens when they're redeemed.)
Days are not rolled over automatically, to allow for task completion control.
We used it in my household for several months, with mixed success. There are many limitations in the system that would warrant a revisit.
It's written using the Pyramid Python framework with URL traversal, ZODB as the data store and Web Components for the frontend.
Goals
- Add admin screens for users, tasks and schedules
- Add models, pages etc. to allow redeeming tokens for gifts/surprises
- …?
Resources
tbd (Gitlab repo)
Bring to Cockpit + System Roles capabilities from YAST by miguelpc
Bring to Cockpit + System Roles features from YAST
Cockpit and System Roles have been added to SLES 16 There are several capabilities in YAST that are not yet present in Cockpit and System Roles We will follow the principle of "automate first, UI later" being System Roles the automation component and Cockpit the UI one.
Goals
The idea is to implement service configuration in System Roles and then add an UI to manage these in Cockpit. For some capabilities it will be required to have an specific Cockpit Module as they will interact with a reasource already configured.
Resources
A plan on capabilities missing and suggested implementation is available here: https://docs.google.com/spreadsheets/d/1ZhX-Ip9MKJNeKSYV3bSZG4Qc5giuY7XSV0U61Ecu9lo/edit
Linux System Roles: https://linux-system-roles.github.io/
First meeting Hackweek catchup
- Monday, December 1 · 11:00 – 12:00
- Time zone: Europe/Madrid
- Google Meet link: https://meet.google.com/rrc-kqch-hca
Improvements to osc (especially with regards to the Git workflow) by mcepl
Description
There is plenty of hacking on osc, where we could spent some fun time. I would like to see a solution for https://github.com/openSUSE/osc/issues/2006 (which is sufficiently non-serious, that it could be part of HackWeek project).
The Agentic Rancher Experiment: Do Androids Dream of Electric Cattle? by moio
Rancher is a beast of a codebase. Let's investigate if the new 2025 generation of GitHub Autonomous Coding Agents and Copilot Workspaces can actually tame it. 
The Plan
Create a sandbox GitHub Organization, clone in key Rancher repositories, and let the AI loose to see if it can handle real-world enterprise OSS maintenance - or if it just hallucinates new breeds of Kubernetes resources!
Specifically, throw "Agentic Coders" some typical tasks in a complex, long-lived open-source project, such as:
❥ The Grunt Work: generate missing GoDocs, unit tests, and refactorings. Rebase PRs.
❥ The Complex Stuff: fix actual (historical) bugs and feature requests to see if they can traverse the complexity without (too much) human hand-holding.
❥ Hunting Down Gaps: find areas lacking in docs, areas of improvement in code, dependency bumps, and so on.
If time allows, also experiment with Model Context Protocol (MCP) to give agents context on our specific build pipelines and CI/CD logs.
Why?
We know AI can write "Hello World." and also moderately complex programs from a green field. But can it rebase a 3-month-old PR with conflicts in rancher/rancher? I want to find the breaking point of current AI agents to determine if and how they can help us to reduce our technical debt, work faster and better. At the same time, find out about pitfalls and shortcomings.
The Outputs
❥ A "State of the Agentic Union" for SUSE engineers, detailing what works, what explodes, and how much coffee we can drink while the robots do the rebasing.
❥ Honest, Daily Updates With All the Gory Details
Is SUSE Trending? Popularity and Developer Sentiment Insight Using Native AI Capabilities by terezacerna
Description
This project aims to explore the popularity and developer sentiment around SUSE and its technologies compared to Red Hat and their technologies. Using publicly available data sources, I will analyze search trends, developer preferences, repository activity, and media presence. The final outcome will be an interactive Power BI dashboard that provides insights into how SUSE is perceived and discussed across the web and among developers.
Goals
- Assess the popularity of SUSE products and brand compared to Red Hat using Google Trends.
- Analyze developer satisfaction and usage trends from the Stack Overflow Developer Survey.
- Use the GitHub API to compare SUSE and Red Hat repositories in terms of stars, forks, contributors, and issue activity.
- Perform sentiment analysis on GitHub issue comments to measure community tone and engagement using built-in Copilot capabilities.
- Perform sentiment analysis on Reddit comments related to SUSE technologies using built-in Copilot capabilities.
- Use Gnews.io to track and compare the volume of news articles mentioning SUSE and Red Hat technologies.
- Test the integration of Copilot (AI) within Power BI for enhanced data analysis and visualization.
- Deliver a comprehensive Power BI report summarizing findings and insights.
- Test the full potential of Power BI, including its AI features and native language Q&A.
Resources
- Google Trends: Web scraping for search popularity data
- Stack Overflow Developer Survey: For technology popularity and satisfaction comparison
- GitHub API: For repository data (stars, forks, contributors, issues, comments).
- Gnews.io API: For article volume and mentions analysis.
- Reddit: SUSE related topics with comments.