read first Jira

[Igor]

Few weeks ago I started to do some early investigating where we are in general. From rough to very specific ones. That shall not be my personal plan only - what to do in the next 6-12 months? What shell we try to finish, change, close, turn to, remove, go, ...?

There are wishes, plans, micro plans. Some are common, some individual. Most of them are in our heads or just scattered around various forum topics, GitHub issues, personal agendas.

 

Without proper common project tracking, one need a day or a week to sit down, scrap all this, think, make a visual, think again. And perception is still too narrow. What is important, what shell anyone work on if he wants to? Where we go next? When to finish this, that we are able to do that?

 

Recently we did some changes to upgrade organisational levels by starting to track changes via Github kanban project management system. We made groups and few tasks went along smoothly this way. It is probably good enough solo for build script but to manage the project as a whole, we need something (much) better than this.

 

There were several mentioning and ideas related to Jira. I use Jira on a separate project for several months now. Playground is around 50 active users separated in multiple teams doing software development. I am delighted how Jira helps in this process. There is surely some efforts to get this implemented and shift your MO to work the SCRUM way.

Do we want that? Which are pros and cons? Is is worth going this way?

If we go this way, we need and should find assistance. Perhaps there are people here which have (much) longer experiences running software project this way and can show us what is the best way? Dedicated project manager or just an Jira geek, which, in theory, does not need coding skills and can scan and move ideas from forum/GitHub/personal chat. Those which we are happy to deal with, to this central project manager tool. This should be rather a support for development process, not an additional boring unnecessary work.

 

There are videos for quick start and some additional resources can be added if needed. I saw those/recommend at least this few times:

 

• Using Jira (22m)
• Software development best practices (40m)

 

Primary purpose of project management tools is to cope with a complexity. Jira was designed and it is used by many software development projects. Bigger and smaller than ours. We need better organisation and we need to save time!

What shell we do with current Github issues and effort? IMO simply move already created teams and project structure to Jira while leave everything as is. And with help from someone that master Jira. The unstructured part of the development remains as is, while it could and can be linked with Jira.

I already sent a request to get a free Jira licence for open source projects. It was granted at once. Shall we proceed? In case we do, I need help, and help to get help. In case not, what then?

[martinayotte]

I've used Jira from 2005-2008 while working at Ubisoft-Montreal, at that time, the team size was 1000 employees ...

 

[lanefu]

5 hours ago, Igor said:

It is probably good enough solo for build script but to manage the project as a whole, we need something (much) better than this.

What are some of the needs that the github projects isn't satisfying?   Projects can be done at the organization level or the repo level.  Currently we are using them at the org level https://github.com/orgs/armbian/projects.   

 

5 hours ago, Igor said:

There were several mentioning and ideas related to Jira. I use Jira on a separate project for several months now. Playground is around 50 active users separated in multiple teams doing software development. I am delighted how Jira helps in this process. There is surely some efforts to get this implemented and shift your MO to work the SCRUM way.

Do we want that? Which are pros and cons? Is is worth going this way?

So I've used Jira in a few large environments--and even ran Jira at home on my SBCs with armbian    Anyway it's a super cool tool.   Its advantages are things like Nice Dashboards, Reports, robust querying and filtering etc.    JIra has tons of integrations, and a nice API.  People could even make a shell script to create a new ticket.  There's several Jira clients out of varying quality out there as well.. including CLI clients.

 

Con's are it's a big Enterprise grade tool.  Establishing a sensible workflow might take some time to get right because so much is left to the operator to decide.   Github will need to be integrated (hopefully thats easy).  Account management will need to be figured out.. maybe that can be federated to github?     Basically more administration required overall, and another site to go to... 

I'm open to switching to Jira, but I feel like the Github project management can meet our needs with less effort if we use it more frequently.

5 hours ago, Igor said:

If we go this way, we need and should find assistance. Perhaps there are people here which have (much) longer experiences running software project this way and can show us what is the best way? Dedicated project manager or just an Jira geek

I definitely agree with the above.   We need some sort of Agilist / Project Manager to help us, pester us, and nag us.    Should we look for someone on fivvr / etc regardless of Jira?  Just having a project management person's vision would help us a lot.

 

3 hours ago, martinayotte said:

I've used Jira from 2005-2008 while working at Ubisoft-Montreal, at that time, the team size was 1000 employees ...

But how would feel about using it in 2019? What are your thoughts about what we've tried thus far?

 

5 hours ago, Igor said:

I already sent a request to get a free Jira licence for open source projects. It was granted at once. Shall we proceed? In case we do, I need help, and help to get help. In case not, what then?

If we get more feedback and decide to proceed I can help you with setup.   

[ning]

is jira github integration free of charge? 

[Igor]

9 hours ago, ning said:

is jira github integration free of charge? 

https://marketplace.atlassian.com/apps/1219592/github-for-jira?hosting=cloud&tab=overview

This one is free and already installed/connected. Didn't made any deep research at this stage.

[qstaq]

Are we talking about Jira core here? Or Jira with Service Desk?

 

 

[lanefu]

1 hour ago, qstaq said:

Are we talking about Jira core here? Or Jira with Service Desk?

 

 

good question, but I assume Jira Core + Jira Software.  Jira cloud may bundle features differently.

@Igor

Edited October 9, 2019 by lanefu
jira cloud

[qstaq]

Sorry I meant Jira Software when I referred to core

 

Im a fan of Jira, I think its a great system, especially with the service desk, however it takes a good amount of planning, training and workflow documentation / implementation to make it work properly. Roughly 7 out of 10 Jira setups I have encountered actually make life more difficult for contributors and end users seeking support over just using basic github tools because of badly thought out or non existent workflows. Done properly it works very well, my concern would be the resources required implement and continuously monitor and review the structure. 

 

Im not trying to be negative on the idea, I think its a great solution to the problems faced by Igor and the team. I just think its wise to be aware of the extra management overhead it will generate in the short to medium term, potentially hundreds of hours. Also a lot of the work required to plan and implement Jira properly is not specific to Jira. A lot of this extra work could probably apply to re-organising the project as it is now. 

 

An alternative (but not equivalent) option may be to break the Armbian/build project down into multiple smaller, simpler, modular projects. This would make long term management and project planning easier. Obviously this is not an optimal solution but its simpler and less resource intensive and allows contributors to understand the code structure with less effort usually

 

From an idealistic standpoint I would say +1 here for Jira

 

 

 

 

[Igor]

30 minutes ago, qstaq said:

my concern would be the resources required implement and continuously monitor and review the structure. 

Exactly that is my main concern and possible solution is to find or hire someone as proposed. I am aware that only if managed properly we will benefit by going the Jira way. Otherwise only more time will be lost. We surely don't want that.

Before we start to add stories, tasks and users ... a lot has to be done and we don't need to rush anywhere.

 

1 hour ago, lanefu said:

good question, but I assume Jira Core + Jira Software.  Jira cloud may bundle features differently.

I just add you as admin. Check what's enabled. It's a bundle which is free for OSS. Other options such as service desk has to be paid extra. This is it:

Jira Software (Cloud) Standard
10 users
Free

 

30 minutes ago, qstaq said:

especially with the service desk

 

Jira is meant for internal usage only. End users have forum and Github with all its limitations. We have absolutely no resources to address tons of bugs that pops out and we have nothing to do with.

 

bugs: we "see" troubles on forum and a person that has intention to cover something up shell notify others by opening a Jira.

projects: after we all agree that we will go some way, a "project manager" opens a story or more of them with a summary and link to the forum topics. Then story its break down into the tasks and one tasks shell be between 3h - 3 days of work if I understand core agile philosophy correct ...

 

14 hours ago, lanefu said:

Projects can be done at the organization level or the repo level.

Managing the Armbian project, which is more and more not just software development, Github is not enough. Implementing Jira (or something similar) goes also with the idea about leveraging power and responsibility from my shoulders. I could just say: "I have no time for Armbian for next few months which is just a matter of time" and things might start to fall apart ... or we try not to do that  OK. Ain't that bad.

 

14 hours ago, lanefu said:

We need some sort of Agilist / Project Manager to help us, pester us, and nag us.    Should we look for someone on fivvr / etc regardless of Jira?  Just having a project management person's vision would help us a lot.

I hope we can attract someone from the community doing just that (we all shell and must be excluded), but yes, that's also an option. 

[qstaq]

I also agree with @lanefu on the project manager side (I hate the term agilist, every self described agilist I have met in person has been a total bullshitter  ). Maybe not necessarily a full on project manager, but certainly some kind of "whip" to keep track of and report on individual projects and how they relate to the overall project so that @Igor can spend less time analysing and decision making. Some basic aspects of this can of course be automated inside Jira but a human is still needed to decide on importance and resource commitment. I think without having such a person the project will struggle with direction

 

I can help with planning / implementing Jira and workflows if there is a shortage of volunteers (like everyone else Im usually restricted on available time but do usually have 1 quiet week per month). I have project managed a few Jira implementations / restructures and I have been and end user for a while. If its just for internal project management with github integration, that does make the structure much simpler

 

[lanefu]

I tinkered with the Jira some last night and tonight.

 

I couldn't make sense of the github integration.. I see the linked repos, but didn't find much documentation on how to interact with them.

 

For grins i created some new components: kernel-legacy,kernel-next,kernel-dev.    I figured maybe labels would be sufficient for boards?  not sure if we want to organize differently, or follow the board-maintainer model... I figured since we're trying to merge kernels, to just focus on the main kernel types and use labels.   Let's keep on tinkering and trying.   What are your thoughts for organization?

 

FYI Currently my gut feeling is stick with github for tracking the technical work, and for tracking strategic and high-level things that don't belong in github or the forum, just use some simple Trello boards or google keep to organize.

[Igor]

8 hours ago, lanefu said:

I couldn't make sense of the github integration.. I see the linked repos, but didn't find much documentation on how to interact with them.

AFAIK it should work as this way. Opening a issue or commenting:

AR-3: Fixing problem 

 

... and it should translate AR-3 to link to Jira issue with this ID. But it doesn't work ... huh. Perhaps permission issue?

 

8 hours ago, lanefu said:

What are your thoughts for organization?

We add versioning once settle and we have it all. IHMO we have to follow the KISS principle. Even legacy-next-dev seems too much. Just kernel issues and label which kernel it is?

 

8 hours ago, lanefu said:

FYI Currently my gut feeling is stick with github for tracking the technical work, and for tracking strategic and high-level things that don't belong in github or the forum, just use some simple Trello boards or google keep to organize.

 

From my perspective technical issues can remain tracked with Github. In Jira if there is benefit, otherwise this can stay. Jira for everything else. Rather then Trello/Google keep stuff.

 

But lets not rush anywhere.

[Igor]

On 10/11/2019 at 11:29 AM, Igor said:

Perhaps permission issue?

 

@lanefu

Connection with Github works now - project has to be public and "Armbian" was changed to public @CSQ-Vero @qstaq (and read-only for anonymous), other Project remains private only.

https://armbian.atlassian.net

 

On 10/11/2019 at 2:46 AM, lanefu said:

to just focus on the main kernel types and use labels.

Components are set by admins, labels by any register/approved user. Component "kernel" is IMO enough.

 

On 10/11/2019 at 2:46 AM, lanefu said:

What are your thoughts for organization?

 

Yes, something like that. Next we need perhaps to define sprint length?

 

Create 4, 6 or 12 sprints / year. Having an IRC meeting to discuss what was done, adjust upcoming time slot on the end of each? Is that realistic?

[lanefu]

43 minutes ago, Igor said:

Yes, something like that. Next we need perhaps to define sprint length?

 

Create 4, 6 or 12 sprints / year. Having an IRC meeting to discuss what was done, adjust upcoming time slot on the end of each? Is that realistic?

 

Part of it will depend on how we want to address unplanned work and planned work.  How much will we allow of each?

 

What do we want the output of a "sprint" to be.... a release, just a piece of a release?, just work completed?

I definitely like the IRC idea... Its definitely something i wish we had for development and planning stuff.

[Igor]

Quote

Sprint is one timeboxed iteration of a continuous development cycle. Within a Sprint, planned amount of work has to be completed by the team and made ready for review. The term is mainly used in Scrum Agile methodology but somewhat basic idea of Kanban continuous delivery is also essence of Sprint Scrum. Sprint literal meaning is a short race at full speed. Accordingly, teams usually define a short duration of a Sprint up to 2-4 weeks. Team collaboratively sets their target with Product Owner as “Sprint Goal” and plan their work in “Sprint backlog”. As soon race starts after planning session, team work together to complete planned work effectively and make it ready for review by the end of that period. High level User Stories readiness in Product backlog is the prerequisite of starting a Sprint Cycle. Sprint Analytics help Scrum Master and Product Owner to know the progress of Sprint in a glance. It is the place to define Sprint Goal and Definition of Done for each Sprint.

I am still learning this sh*  This looks like a sprint is a collection of tasks we agree to close in this time period. How many of them - depends on resources. Our velocity is low and rapidly changing on how much free time and stamina key persons have. We can also assign some budget to alleviate this a little. Further. IMO we can allocate 50% of sprints time for unplanned work/bugs. This will also add more flexibility. But until we don't define the length of the sprint and until we do some real world work, its hard to say.

 

New sprint shell be planned on IRC meeting. We select / vote / propose / define next "scrum master" which is a leader for that period. He is responsible that tasks are closed (while anyone can close them if done) and to call out for next meeting?

How I understand releasing here is that we tag elements (stories/tasks/bugs), which have to be completed for certain release. Once all things are checked, we can have a release. Which already need to have a known number. For release 3.0 we have to fix (and tag with versions inside Jira) ramlog issues, upgrade bootloaders, ... Upgrading boot loader is a story. Story is broken into tasks: - bump with version, - adjust patches, - test on few devices, - engage community into testings, - run autotest when this will be possible, ...

[TRS-80]

My current job still keeps me quite busy still with no time for hardly anything. Having said that, I would like to contribute, somehow. Perhaps financially, even more than I am doing now (which is not much). Maybe I could contribute a little more for this admin person, I dunno. I just feel a strong urge to help out, somehow, however I can.

 

Also, there exists an #armbian channel on Freenode, I auto-join and hang out in there all the time, but rarely if ever see anyone talking in there. I am not sure if you guys are aware of it, or? MOTD says "unofficial channel awaiting official status." Just FYI.

[qstaq]

Hi guys, sorry for the slow response, was called out over the weekend and haven't had much time to look at things

 

Jira has changed a lot in the last 12 months. I very much like the structure of the new simplified project layouts that are available. Very useful for tracking individual projects or sprints but possibly a little too simple for complex projects.

 

On 10/11/2019 at 1:46 AM, lanefu said:

I couldn't make sense of the github integration.. I see the linked repos, but didn't find much documentation on how to interact with them.

 

I played with this over the weekend and couldn't make it work properly. The way its currently working is OK in that it gives some link between the issues but it has to be manually created. There are other ways to integrate github into Jira that I have used before. We created a system whereby we could assign a specific tag / label to an issue or PR and that issue / PR would automatically get replicated and tracked in Jira. I have asked a previous colleague to forward me some info about how we created that integration in the past. I have Vero coming round this evening to have a look at the integration part and structures. She has been catching up on the forum and github yesterday and is starting to grasp the basics, though she probably needs another day to get comfortable. I also told her to find this Jira thread and introduce herself and read up but I dont think she has access to view it. Can she be invited to have access to this specific thread?

 

On 10/11/2019 at 10:29 AM, Igor said:

From my perspective technical issues can remain tracked with Github. In Jira if there is benefit, otherwise this can stay. Jira for everything else. Rather then Trello/Google keep stuff.

 

I would vote to leave all technical issues in github. Just pull in or reference them for specific projects or sprints, otherwise the core list in Jira can get unmanageable

 

On 10/12/2019 at 5:34 PM, Igor said:

Yes, something like that. Next we need perhaps to define sprint length?

 

Create 4, 6 or 12 sprints / year. Having an IRC meeting to discuss what was done, adjust upcoming time slot on the end of each? Is that realistic?

There are 3 main approaches to this

1) Some organisations like to have regular scheduled sprints that are planned in advance but without content. The sprint contents are planned closer to the start date and based on whatever issues / developments are pressing at the time

2) Some organisations like to have regular scheduled sprints that are planned in advance including content. This obviously requires some significant ahead of time planning from a development direction perspective. Organisations that use this structure tend to also have ad-hoc sprints for bug fixing sessions

3) Sprints are decided upon and structured in an ad-hoc basis, usually as the result of review or crisis meetings. This kind of structure tends to be better for bug fixes but not so good for development

 

For Armbian I would think that a option 2 is better in the long run with maybe 4-6 major sprints per year for pre planned development / releases and quarterly or monthly mini sprints to deal with bug fix triage

 

On 10/12/2019 at 6:24 PM, lanefu said:

What do we want the output of a "sprint" to be.... a release, just a piece of a release?, just work completed?

 

Development sprints should be releases in my opinion. Bugfix sprints should maybe be point release. Official images are built / released only after a dev sprint or bugfix sprint. Obviously that doesn't work with Armbians current versioning system but maybe that also needs a think about?

 

On 10/12/2019 at 6:24 PM, lanefu said:

I definitely like the IRC idea... Its definitely something i wish we had for development and planning stuff.

+1

 

 

[Igor]

On 10/15/2019 at 6:15 PM, qstaq said:

We created a system whereby we could assign a specific tag / label to an issue or PR and that issue / PR would automatically get replicated and tracked in Jira.

It works. Add a comment or commit with at label [ar-2] and Github will create a link to that issue. I didn't test for other elements such as components or labels.

 

On 10/15/2019 at 6:15 PM, qstaq said:

I have Vero coming round this evening to have a look at the integration part and structures. She has been catching up on the forum and github yesterday and is starting to grasp the basics, though she probably needs another day to get comfortable. I also told her to find this Jira thread and introduce herself and read up but I dont think she has access to view it. Can she be invited to have access to this specific thread?

She should have read/write access to this topic. Users with no approved posts can't just add comments ... but @lanefu fix her permissions and now she can.
 

On 10/15/2019 at 6:15 PM, qstaq said:

I would vote to leave all technical issues in github.

OK. But we will plan in Jira let's say ... "Check and fix Bluetooth on all boards where build in" ?

 

On 10/15/2019 at 6:15 PM, qstaq said:

For Armbian I would think that a option 2 is better in the long run with maybe 4-6 major sprints per year for pre planned development / releases and quarterly or monthly mini sprints to deal with bug fix triage

OK. Then @CSQ-Vero make down a structure from our posting here, keep an eye on the structure, keep content clean, up 2 date, remind us to update changes ... what is her role, what ours?

 

BTW. We shell keep Jira read only for outside but can we enable at least commenting? I already tried to enable that but failed.

 

On 10/15/2019 at 6:15 PM, qstaq said:

Development sprints should be releases in my opinion. Bugfix sprints should maybe be point release. Official images are built / released only after a dev sprint or bugfix sprint. 

To me, sprint is just a time frame where we do something. Some rough estimation about coding can be extracted from https://github.com/armbian/build/commits/master but for everything else we don't have exact tracking. Yet. We should just estimate that we can pull together ... perhaps 30 hours in one week and than adjust to reality with the time. Inside this time frame some development is going on and some bugs are fixed. Development stories has to be break apart that each task go inside 3h - 3 days rule (this rule is from some Jira expert from a video above)
 

On 10/15/2019 at 6:15 PM, qstaq said:

Obviously that doesn't work with Armbians current versioning system but maybe that also needs a think about?

It's complicated but if we just proceed with the current version scheme, we can make use of releasing with Jira https://www.atlassian.com/agile/tutorials/versions right?

 

On 10/15/2019 at 6:15 PM, qstaq said:

+1

Another task for @CSQ-Vero She has to find the best time/date and make sure we came together. I am terrible in doing that  #armbian is sadly not recorded so a manual client logging will be needed.

 

And. Shell we do some trial period at least by the end of the month to make our-self comfortable, then delete things and start from scratch?

[Igor]

I managed to start Jira from scratch and made this pull request with help of Jira.

 

What was done inside Jira?

- cleaned all content except userdate

- created project Armbian which has read only public access

- create new version according to new versioning scheme

- added fixed components which are used to tag issue/bug/epic.

1. QA Quality assurance
2. Legacy Legacy kernel
3. Infrastructure Physical and logical
4. Development Unstable things
5. Current Mainline kernel
6. Builder Armbian build system

- added issues related to this pull request to the backlog and label them accordingly

- created three EPIC (groups of tasks/bugs) which are ad-hoc

1. Remove legacy kernel
2. Change branch naming
3. New features

Structural support is getting shaped here: https://github.com/armbian/documentation/blob/master/docs/Process_Release-Model.md

Example of making a release notes ...
https://armbian.atlassian.net/secure/ReleaseNote.jspa?projectId=10100&version=10000

Spoiler

 

Task

[AR-1] - Adding support category for distributions

[AR-4] - Remove Allwinner legacy

[AR-5] - Drop Udoo family and move Udoo board into newly created imx6 family

[AR-9] - Rename sunxi-next to sunxi-legacy

[AR-10] - Rename sunxi-dev to sunxi-current

[AR-11] - Adding Radxa Rockpi S support

[AR-13] - Rename rockchip64-default to rockchip64-legacy

[AR-14] - Add rockchip64-current as mainline source

[AR-15] - Drop Rockchip 4.19.y NEXT, current become 5.3.y

[AR-16] - Rename RK3399 default to legacy

[AR-17] - Rename Odroid XU4 next and default to legacy 4.14.y, add DEV 5.4.y

[AR-18] - Add Odroid N2 current mainline

[AR-19] - Move Odroid C1 to meson family

[AR-20] - Rename mvebu64-default to mvebu64-legacy

[AR-21] - Rename mvebu-default to mvebu-legacy

[AR-22] - Rename mvebu-next to mvebu-current

[AR-23] - Drop meson64 default and next, current becomes former DEV 5.3.y

[AR-24] - Drop cubox family and move Cubox/Hummingboard boards under imx6

[AR-26] - Adjust motd

[AR-27] - Enabling distribution release status

[AR-28] - Added new GCC compilers

[AR-29] - Implementing Ubuntu Eoan

[AR-30] - Add desktop packages per board or family

[AR-31] - Remove (Ubuntu/Debian) distribution name from image filename

[AR-32] - Move arch configs from configuration.sh to separate arm64 and armhf config files

[AR-33] - Revision numbers for beta builds changed to day_in_the_year

[AR-34] - Patches support linked patches

[AR-35] - Break meson64 family into gxbb and gxl

[AR-36] - Add Nanopineo2 Black

[AR-38] - Upgrade option from old branches to new one via armbian-config

Bug

[AR-25] - Armbian resize stopped working in Ubuntu 19.10 or higher

 

 

[lanefu]

@Igor  

How do we want to manage PRs like this https://github.com/armbian/build/pull/1721 that don't have a Jira issue?  Do we need to go back to Jira and create a cooresponding issue and map it to a release version? 

[Igor]

4 hours ago, lanefu said:

Do we need to go back to Jira and create a cooresponding issue and map it to a release version? 

 

Yes, I guess that is the fastest way to have a reference and entry in the release log. Which is with Jira very simple to do when the time comes. In case we have a big story and more commits to that story it could be wise to add a link to Jira ID at the PR.

We are anyway somewhere in the grey zone at this moment and we would need to set some rules how to use Jira best for the future. Rules that will be clear, simple and useful. IMO it would be perfect to open a Jira and then create a PR and not the other way around. Or more of them. I guess close to this is already good enough. But since I wan to keep Jira closed - only we can open tickets - this way of operation will remain: PR first, Jira later. And this way we already filter out minor things for the release documentation.

[lanefu]

Added new section to release doc.. will continue to update as we go through the process for 20.02

https://github.com/armbian/documentation/blob/master/docs/Process_Release-Model.md#release-coordinating

[Igor]

5 hours ago, lanefu said:

Added new section to release doc.. will continue to update as we go through the process for 20.02

My possible time to attend IRC at working days 6-8 am CET, 5pm-1am CET, weekends more flexible.

[Werner]

Btw. when did you identify yourself last time with nickserv @Igor?

Just asking as I noticed a message from JackFrost last night:

Quote

<JackFrost> TRS-80: Does Igor pop up on IRC often?  NickServ doesn't think so, but that's only if he logs in.

 

[Igor]

19 minutes ago, Werner said:

when did you identify yourself last time with nickserv @Igor?

Just asking as I noticed a message from JackFrost last night:

Last time, don't recall but I did it right now.

13:22:02 -NickServ- You are now identified for IgorPec.

 

We are waiting for OP since 2017 

 

Topic for #armbian is: Un-official Armbian channel waiting to get official status.
Topic for #armbian set by zoobab!~zoobab@195-154-118-161.rev.poneytelecom.eu (Fri May 19 09:24:15 2017)

[Igor]

In Jira we have a good versioning system. Now ... what to do with "bugfix" releases? Open a new 20.08.1,2,... release tag and squeeze there all tasks that were done after 20.08 was released? Or just 20.08-bugfix 20.08.fixes? There is too much trouble to open new releases for each minor change. Overall there is a lot of administration, which I am already unable to keep up ... What would be most proper way to solve this problem? Another option is to tag leave them in the release (20.08) and tag them. This way we know what was bumped in later.

[lanefu]

yeah I like just stick the major version number for release in Jira, and just add a tag for the sub version number.

[Igor]

Copy / pasted from internet - to also have meaning attached to those two new labels - those releases are a combination of:

 

Example: not critical, so patch-release https://armbian.atlassian.net/browse/AR-422 and present in both 20.08 and 20.11 releases since they are usually done in between.

 

patch-release

Patch release is regular release which publishes in a regular interval for the product. Minor New features, enhancements, fixes of bugs are incorporated with patch releases. This release holds general updates hence it is beneficial to all the customers who are using the product. Most software products publish patches at regular intervals.
 

Hotfix 

When any customer reports a critical issue which is needed to be fixed as soon as possible, then product owner publishes hotfix which is the fix for the critical issue. A hotfix may hold one or more fix of critical bugs which is beneficial to either the specific one or more clients. Interval of hotfix is not regular, product owner release it as per request

[Tido]

4 hours ago, Igor said:

There is too much trouble to open new releases for each minor change. Overall there is a lot of administration, which I am already unable to keep up ..

For a common understanding..  semantic versioning   8.5.4 == MAJOR.MINOR.PATCH - for a programm, not a distribution. But, people really care which version they have and they want the latest an greatest - as we know from questions in the forum.

Ubuntu LTS on the other hand fixes stuff and after a period they release 20.04.1  that incorporates all the fixes. However, I guess your release cycle is too short.

[Werner]

8 hours ago, Tido said:

I guess your release cycle is too short.

Agree. Maybe things should not be pushed so hard. Not only there is (from gut feels) little effect on (to use @Tido's scheme for simplification) patch releases, it also increases the administration effort as @Igor noted.

What about this? Do not push out intermediate releases (like 20.08.4) UNLESS there are critical issues like board does not boot.

Everything else can most likely be pushed via apt kernel upgrade anyways and will be merged in the next 3-month-release as well.

If somebody wants a provided fix faster they have to build their own either image or kernel package from master or wait. No discussion.

 

my two cents.