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
-
over 5 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
-
over 5 years ago by gameboy974 | Reply
I disagree : ) opensuse-release-process is simpler and more accurate therefore more sexy ; )
-
-
-
-
over 5 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.
-
-
-
over 5 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
-
over 5 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)
-
-
-
over 5 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 `
-
-
-
-
over 5 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
-
-
over 5 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.
Boards that I have around and there are no images:
- Rock 3B
- Nano PC T3 Plus
- Lichee RV D1
- StartFive VisionFive (has some image needs testing)
Hack Week 22
Hack Week 21
Resources