ISO release discussion

The run-time lack in latest manjaro-kde-21.1.6-211017-linux513.iso ISO:
duplication of summary text section of the future partition system before installation stage of modifying the storage content.


Looking back to announcement of stable branch perhaps to release new ISO image file the same time as update is too early action to do: in 2-3 days usually it needs to rebuild ISO to include bug fixes in it or even to revert back ISO as was with 21.2pre1.

Perhaps better to release ISO after announcement thread of stable update settle down report activity and got needed fixes to make ISO more stable. and to add it to ISO list for a few months, not for a few days only before it will be recalled back and to revert to earlier one ISO. BTW, before the 21.2pre1 it was stable ISO built on November, 16 and before it stable ISO built on November, 17.

Need to make ISO great again :slight_smile: May be to wait 2-3 days after stable branch will got fixes.
Or to re-issue ISO again in a one week after stable branch got massive update.

Well, ISOs get actually built every day. This goes for Gnome, KDE Plasma and also for XFCE. People can freely test those and give us feedback. When the team thinks it is ready we will publish ISO we promote on our download page. When there is a stable snap we also build new ISOs. Those get tested and announced when ready. Sometimes however not all lands in stable branch, which was approved in unstable already.

Switching to Qonos now is needed due to the removal of Kernel 5.13, which was shipped with Pahvo.

1 Like

Philip, thank you for the answer! Perhaps a bit misunderstanding here, tried to reword: I meant to use stable branch updates as another one testing level prior to release stable ISO image file.

Let’s switch to example:

We already have some current stable ISO from the past (for example a month ago). ok.

Stable branch got massive 100+ (200+) package updates.

And suggested idea goes like this:
to get feedback from users already having Manjaro installed and using stable branch on how the update went for them, to fix reported issues from stable users and and report activity will settle down or almost all bug will be fixed (after 2-3-5 days after stable branch got a massive update) and only then to build ISO of stable branch which will be really stable - as was hardened by stable branch users report bugs.

I think it will be the most stable moment to build ISO image which has minimum chances to be broken for existing and new users, who download image just to give Manjaro a spin a test run, and that hardened ISO image will show maximum stability the distro has.

Currently stable ISO images usually releases in the day of updates came into stable branch or a day after it, so it does not include several bug fixes cause they are came in several hours or days later, also not all users updates in single day, may be some of them update in Saturday night, Sunday or even on Monday.
Also even most users updates on Saturday, some or them did not reported they bugs yet cause they are not discovered yet or not realized the cause and users wants to try to fix by themselves first and if in 1-2 days failed, when to report and when devs saw the bug report? several hours later.
When they fix it? may be in 5 minutes, may be on the next 1-2 days only.
So need some period to make stable branch incorporate many bug fixes which was introduced by massive package updates.

I suggest 2-3-5 days to wait stable branch to make most bug fixes to reach it prior to build maximum stable ISO
current period of 0-1 days before to build ISO when stable branch became a bit more buggy
comparing to period after it will settle down in 2-3-5 days.

Re-phrased the same:
To postpone stable ISO build for a 2-3-5 days after stable branch get massive update
to make it maximally stable ISO.

I have non-perfect English, sorry.

Could you run that by us again clearly and concisely broken into each issue your want to address with potential solutions with how they can be actionable?


  1. Issue about the thing
    • One way it can be improved
    • Another way it can be improved
  2. Issue about the other thing
    • so on and so forth

Current release cycle is:

  • doing the stable snap
  • doing the ISO builds
  • doing the internal testings
  • announce the stable snap after internal testing was fine

However people already complaint when I post just the don’t video and did the announcement couple days later …

Perhaps I should go into English kinder garden to start to learn English

Mark, the only thing I trying to tell is in the purpose.

Make stable ISO images even more stable.

Expected (suggested) solution
Release ISO image file of stable branch only 5 days after the stable branch received massive update.

Current state
ISO image file of stable branch released 0-1 day after the stable branch received massive update.

Why to change?
That 5 days gives bug fixes to reach stable branch and they will be inside of stable ISO to meet Purpose goal above. This will make ISO even more stable before it’s release cause it is widely tested.

Switching to Philip’s post:

The idea goes like this:

  • doing the stable snap
  • doing the internal testings
  • announce the stable snap after internal testing was fine
  • bug fixing process based on users feedback of stable branch during 3-5 days
  • doing the most stable ever ISO build (cause now it includes many patches for those 3-5 days delay)

But I like that video. :stuck_out_tongue_winking_eye:

More people need to use the testing and unstable branches to catch things before they hit stable. I know you use unstable and do provide feedback, that’s appreciated.

The stable ISO’s normally correspond with the stable updates. The ISO is just a snapshot in time of a rolling release. If pressing bugs are found, some packages may be pushed to the stable branch after. Users need to update regardless.

Yes, please leave unstable daily builds as they are, it is out of scope here.

Yes, I just suggested to make this snapshot 3-5 days after stable branch got passive update to let stable branch to collect many bug fixes on bugs reported by stable branch users.

Yes! I suggest to wait those 3-5 days to get that pressing bug fixes to reach stable branch and after that to do even more stable/hardened ISO based on now fixed stable branch.

Current stable ISO images does not included those pressing bug fixes reported in Stable announcement thread, cause the snapshot for ISO created in the same time packages reaches stable branch.

And after 3-5 days the stable branch become having those pressing bug fixes, but ISO image lacks them cause was created from snapshot before those pressing bug fixes

EDIT: fixed typo in the last sentence (thenthem)

Mark, we all are from different cultures even continents here, so having some different templates of thinking, the picture may not clarify our thoughts.

That “steam locomotive” term here could have at least two opposite meanings:

-) steam locomotive = vapor technologies = the idea was so bad, like it suggests to resurrect vapor technologies in 21st century electricity and PC based on beams of light (quantum PC based on qubits).

-) steam locomotive = it is one of symbols of progress / development = the idea was good and it is worth to try it in order to improve the Manjaro project.

So by that icon, I do not know that exactly you meant, and hope others understood your sign as you expect them to interpret it :slight_smile:

Neither. There is no steamroller emoji, so I clicked that. :stuck_out_tongue:

You asked for it: You steamrolled right over the top of what both Phil and I said.

Tip: Don’t take emoji’s seriously. :wink:

May be user base became more so serious users became more visible/notable.

Imagine MS will post some internal stuff in change.log web page for a couple of days. What users will do? Where out logs and what the hell is that? Were they hacked? Are they serious guys or not?

Perhaps it is just one of possible signs that user share increases.
BTW, it is 12th of December. Where a telemetry package? :slight_smile: Where and to whom to complain? :slight_smile: It was noted to be ready by 2022, so before NY-2022 as I understood.

I checked the running of manjaro-kde-21.2.0-211220-linux515.iso linked in the Manjaro 21.2.0 Qonos released! the issue mentioned in the first post is solved: storage section summary now is not doubles.

I saw stable branch updates release and a bit postponed release of stable ISO. So the idea discussed in that thread was implemented. May be the approach will be changed/optimized in future. But I happy that the idea got a spin to try it out. Thank you!

I see no reason to leave the topic open: the issue was fixed, the idea was implemented. Mods, please close the thread.