Armbian 21.08 (Caracal) Release Thread


 Share

4 4

Recommended Posts

Release Candidate Code Freeze Date: 2021-07-18. (Fixes only afterwards)

Release Planning Meeting Date: 2021-07-10 1400GMT
Release Date: 2021-08-08

Release Candidate Branch Link: TBD 

Release Changelog: TBD

Release Coordinator: @lanefu

Testing Tracking Sheet: TBD (google sheets)

 

The purpose of this thread is to discuss testing, bugfixes, and the overall quality of the release. Once the release is complete, this thread should be locked and unpinned.

 

Please subscribe to this thread!

I want this release to focus on upgrade stability.   That means we need to strongly focus on:

* kernel packages

* rootfs packages

* u-boot updates

* -current kernel remains on 5.10LTS!

* testing

* testing

* TESTING

 

Please share you priorities, thoughts, etc in this thread...  Any format is fine.. post, GitHub link, jira issue.

 

 

help me menton peeps plz.

@Igor@Werner @TonyMac32 @martinayotte@piter75 @ning@Myy@balbes150 @sfx2000 @ebin-dev@chwe@gprovost@aprayoga@5kft@JMCC@going@jeanrhum@dolphs @jock@belfastraven@TRS-80@Bozza@Rich Neese@sgjava@Mangix@tony013
 

 

 

 

 

 

Link to post
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

On 6/6/2021 at 9:59 AM, lanefu said:

 

 

Please subscribe to this thread!

I want this release to focus on upgrade stability.   That means we need to strongly focus on:

* kernel packages

* rootfs packages

* u-boot updates

* -current kernel remains on 5.10LTS!

* testing

* testing

* TESTING

 

Please share you priorities, thoughts, etc in this thread...  Any format is fine.. post, GitHub link, jira issue.

 

 

help me menton peeps plz.

@Igor@Werner @TonyMac32 @martinayotte@piter75 @ning@Myy@balbes150 @sfx2000 @ebin-dev@chwe@gprovost@aprayoga@5kft@JMCC@going@jeanrhum@dolphs @jock@belfastraven@TRS-80@Bozza@Rich Neese@sgjava@Mangix@tony013
 

 

 

 

 

 


Don't forget to subscribe to thread :)   

Link to post
Share on other sites

  • Igor changed the title to Armbian 21.08 (Caracal) Release Thread
06.06.2021 в 16:59, lanefu сказал:

I want this release to focus on upgrade stability.   That means we need to strongly focus on:

* kernel packages

* rootfs packages

* u-boot updates

 

To implement this very good strategic direction, we will have to operate only with apt\apt-get tools inside the build system to install the assembled packages.

We should refuse to install packages in a future image using a template search for it, for example, as here.

 

At the initial stage, we need to create the entire infrastructure of the future local repository, for example,

in the "output/local_repo" folder similar to the remote armbian repository and create it.
We need to clear the folder "${DEB_STORAGE}/ " before starting the build.

 

step one of building packages:
We make a list of packages selected for subsequent assembly
with the package name and version fields.

 

step two:
Let's check this list by the parameters package name and its version.
If the package does not exist in the local repository, we build it.
We will move all the files received after building the package to the folder " ${DEB_STORAGE}/ "

 

step three metapackage:

We will collect two or three metapackages and write down the hard dependencies package name version from the list that we received at the first step.
Let's check the version of the metapackage in the local repository.
If there is, add 1 and collect the metapackage.

 

step four:
We will add the packages that were built to the local repository.

At the image creation stage, we add a local repository and install two or three metapackages.
If the image is built successfully and it is a release, then everything collected can be added to the remote repository.
And that's all.

 

If something went wrong, we deal with the dependencies in a particular package and the process of building it.
Thanks for attention.

 

Link to post
Share on other sites

@tony013 I hope I didn't scare you with pointing out to our testing rig ;) I mean it serious. We can't afford to rely on manual testing. It needs a lot of coordinating and time. All serious developers have such tooling ... We have built this test system together from scratch, which is obviously a lot more efficient than manual testing, but driving routines are still immature and under development. We only have some quickly assembled bash scripting, network for test devices is more or less ready, netbox DUT inventory up2date, ...

 

On 6/24/2021 at 2:23 PM, going said:

we will have to operate only with apt\apt-get tools inside the build system to install the assembled packages.


If we are focusing to the bug fixing in this release, perhaps rather fixing bugs that are already on the table / known / short term? Do we have enough time to bring as proposed up, test well and push it into upcoming release? 

 

For many people it's also a start of a summer holiday, which could add delays.

BTW. I also started with a "Code cleaning" task, which anyone that feels bored enough is welcome to join. No functionality changes, just cleaning things out, rewriting things better, moving functions here and there.

Link to post
Share on other sites

vor 7 Stunden schrieb Igor:

 I hope I didn't scare you with pointing out to our testing rig

No worries. I am already an adult. To be more precise, I'm already over 60 years old. To use your words, I was scared by the tone and expectations of you developers. It's the first forum I've experienced that was designed for developers and not for users (3 of 18 sections are for users). A beginner has to come to terms with that first.
You constantly write about how much effort the development is and that you want support - but when one is ready to cooperate, he will be left out in the cold.


It is not yet 3 months since I bought my first rockpi4. Before that I had no contact at all with such small parts- and for so, I don't know anything about its requirements or handling.

 

From there - my question was meant seriously. But I also do not have to impose myself.

I have almost reached my goals, so I am quite satisfied.

Link to post
Share on other sites

3 hours ago, tony013 said:

I was scared by the tone and expectations of you developers. It's the first forum I've experienced that was designed for developers and not for users (3 of 18 sections are for users). A beginner has to come to terms with that first.


Users and developers perception can be far apart which is one source of communication troubles. We could explain politely on each request, how things are, but that is just far more expensive. Coaching and teaching is yet another big chunk of pure waste of our time which we have to avoid just to survive. (Sadly) Cold answer is saving us a lot of time and in most of cases stops river of additional questions I have absolutely no wish to deal with, certainly not on my private time expense. The problem is, time lost on that is extreme and it can easily cost more time than my daily job. A few days / weeks later, question is repeated.

 

From time to time a psycho user emerges and problem of time waste is escalated. All this generate pressure on people that generate value, people that needs to be protected from constant abuse of attention from people that have zero perception on how much work, time and cache expense, some problem needs.

 

We have an early design of solution for forum reorganisation (making distance based on users experience, so users will have certain areas read only access unless proven) on certain user experience levels, to minimize clashes, but its yet again a job that waits a dedicated person to coordinate that change.

 

3 hours ago, tony013 said:

but when one is ready to cooperate, he will be left out in the cold.

 

A project manager(s) and HR personality would be also nice to have around. But we don't have. We only have a few people that move this project forward and I cry for help. For them and for you. And at the end - it is you / users who need help.


As most of the time is eaten on helping users. Still. Perhaps we need to scale down this whole project before accepting new help. But this again can only be done on users expense.

 

Yes, we can only expect seniors involvement in this field. If newbie is willing to help, there is almost nothing we can do about. We don't have any person that would have enough time to work with that person and bring it up to the levels we need help. I am a bit younger than you, having a full time job and small kids. I am already having a feeling to neglect them. Other people are in similar situation.

 

3 hours ago, tony013 said:

It is not yet 3 months since I bought my first rockpi4. Before that I had no contact at all with such small parts- and for so, I don't know anything about its requirements or handling.


RK3399 boards are pretty matured from today's perspective. There are many vendors that are using it and chip can't be wired in many ways. You were spared most of the suffering.

 

Testing features - we must be focused on automated testings. So we can save some time for spending time with our families - our free time is usually a constant - and also to have an option to answer users questions. We - not just me - are deeply involved in making those boards usable for quite some time now (official since 2013, while many people are deeply involved since early days of Linux). It eats a lot of precious spare time which I simply won't allow to exchange for some bullshitting or demanding extra free services, which can be found daily on forums.

Link to post
Share on other sites

12 часов назад, Igor сказал:

Do we have enough time to bring as proposed up, test well and push it into upcoming release? 

What I wrote is a strategy task.

Given our resources, we will not be able to implement this even in six months.

Look at this as a technical task that I wrote for myself. :)

 

 

Link to post
Share on other sites

15 часов назад, Igor сказал:

BTW. I also started with a "Code cleaning" task, which anyone that feels bored enough is welcome to join. No functionality changes, just cleaning things out, rewriting things better, moving functions here and there.

Maybe it's not the same, but I'm currently working on simplifying the build process. Transferring most of the settings that are scattered in the build scripts (lib) to the BOARD.CONF settings files. This will significantly simplify the logic of the assembly scripts, they will not have confusing logical chains in which the assembly variables are reconfigured and redefined depending on the model. Yes, at the beginning this will increase the duplication of data (variables) in the board.config files, but then it is easily simplified by transferring the same settings to the group config for several devices. When the test sample is ready, I will try to create a separate branch for general analysis. :)

Link to post
Share on other sites

On 6/6/2021 at 9:59 AM, lanefu said:


Just another reminder... Planning meeting tomorrow! 

Release Planning meeting 2021-07-10 1400GMT  #armbian irc.libera.chat

Link to post
Share on other sites

As from today any testing on nightly (and RC when they will be ready) images helps on nailing down bugs. Our automatic testing procedures are happy, but they are not yet on the level we could fully trust them. We still need to see some random manual installations and this can only be done together :thumbup: Checking if we have done it well.

Link to post
Share on other sites

  • Igor unpinned this topic

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

4 4