Jump to content

upcoming release date - feature freeze ?

Tido

By Tido
in Advanced users - Development

 Share

Recommended Posts

Tido

Tido

Posted
Posted

Hi,

 

On the main site: https://www.armbian.com/  it says only 60 days to go for the next release :-)

Well, to have a good user experience and squash bugs I think we should do a feature-freeze from about day 50 onwards - what is your take on that ?

 

To do so, I was thinking about how you could handle this period on Github. Will “pull request’s” after feature-freeze be tagged for later integration?

 

Everybody is welcome in squashing bugs (only the ones in code) ;)

eg. updating or adding configuration file for armbianmonitor ?

eg. updating or adding information to the documentation ?

Last but not least, if you can help with some ‘stubborn’ code or improvement here or here ?

 

If you support this upcoming release just a little - it will become a great release for you too  :beer:

 

Did you already pick one from the above or do you know a dark corner in armbian you always wanted to do some clean up? Now is the time to do that.

Post your idea here, write on github or simply fork the project on github and submit your pull request

 

Tido

lanefu

lanefu

Posted
Posted (edited)
Spoiler

 

On 12.9.2017 at 11:26 PM, Tido said:

Hi,

 

On the main site: https://www.armbian.com/  it says only 60 days to go for the next release :-)

Well, to have a good user experience and squash bugs I think we should do a feature-freeze from about day 50 onwards - what is your take on that ?

 

To do so, I was thinking about how you could handle this period on Github. Will “pull request’s” after feature-freeze be tagged for later integration?

 

Everybody is welcome in squashing bugs (only the ones in code) ;)

eg. updating or adding configuration file for armbianmonitor ?

eg. updating or adding information to the documentation ?

Last but not least, if you can help with some ‘stubborn’ code or improvement here or here ?

 

If you support this upcoming release just a little - it will become a great release for you too  :beer:

 

Did you already pick one from the above or do you know a dark corner in armbian you always wanted to do some clean up? Now is the time to do that.

Post your idea here, write on github or simply fork the project on github and submit your pull request

 

Tido

 

 

how's the current versioning system work?     The codebase has always felt like a rolling release.   

Edited by Tido
added spoiler
Igor

Igor

Posted
Posted

Some of my thoughts.

 

We are trying to follow those directions. Roughly, very roughly and perhaps we should be more aligned to those plans - especially the date of feature freeze - since I believe some structure helps and this way it's less panic and compromises when the date of actual release come by. But where to draw the line? Can we afford to be strict? Does it make sense that major long term projects are broken to focus on bug hunting and code cleaning? I think currently, there are not enough developers to make two groups - one staying on the edge and the other staying on the stable edge. How many - for such organization - do we actually need for the project as it is today?

 

I saw people on this forum saying: "I want to help", "Can I help", ... Hands up! We need your help. Everything what @Tido already exposed plus armbian-config (https://github.com/armbian/config) also needs extensive testing and code cleaning to be ready on time. I will also find some boards for those who are willing to step forward. 

zador.blood.stained

zador.blood.stained

Posted
Posted
20 hours ago, lanefu said:

The codebase has always felt like a rolling release.

The codebase (build script, upstream u-boots and kernels) is a rolling release. But "feature freeze" marks a "stabilization" period before making stable packages and/or images when making significant migrations, changes and implementing new features should be avoided if it affects "stable" targets.

Tido

Tido

Posted
  • Author
Posted

Sounds good. I hope others also had a look into the 'open issues' or documentation, well and also the armbianmonitor for other SBCs can need a brush up, just installl it on your SBC with the command: armbianmonitor -r (to install RPi-Monitor)  it is a very small package.

Beside improving the script it is also good if you just test if it works on the SBC you have. Please report back if you find any issues.

tkaiser

tkaiser

Posted
Posted
1 hour ago, Tido said:

armbianmonitor for other SBCs can need a brush up, just installl it on your SBC with the command: armbianmonitor -r (to install RPi-Monitor)

 

Unfortunately you constantly confuse or mix up two totally independent tools:

 

1) armbianmonitor

 

This tool is (mis)used for various actions, it prints its capabilities simply by calling it without arguments and its monitor mode looks like this: 

root@clearfogpro:/usr/local/src/smartmontools# armbianmonitor -m
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU
13:26:31:  800MHz  0.40   1%   0%   1%   0%   0%   0% 70.8°C
13:26:36:  800MHz  0.36   1%   0%   1%   0%   0%   0% 70.4°C
13:26:42:  800MHz  0.33   1%   0%   1%   0%   0%   0% 70.8°C
13:26:47:  800MHz  0.31   1%   0%   1%   0%   0%   0% 71.3°C

There are two issues:

  • The '%cpu %sys %usr %nice %io %irq' values are wrong on some/many kernels: https://github.com/armbian/build/issues/728
  • Temperature reported might be wrong (since we use an exception for RK3288 legacy kernel now that will be wrong when running mainline) but this needs to be addressed in the prepare_temp_monitoring function in /etc/init.d/armhwinfo. I'm pretty sure this here needs an adjustment with mainline kernel running on RK3288 devices (though I would prefer a patch for legacy kernel and removing the exception)

 

2) RPi Monitor

 

This tool is not even part of Armbian (but an outdated version can be installed with armbianmonitor -r for convenience reasons and to ease supporting people that work on a new board and want to optimize thermal/dvfs settings). I simply threw the few templates I created the last years into the repo. Original idea was to make this work with armbianmonitor-daemon (a 3rd tool we better don't talk about since nothing happened within the last 18 months) but in the meantime this was more or less 'backing up to the Internet'.

 

If people want to contribute they could make the '%cpu %sys %usr %nice %io %irq' values displayed in armbianmonitor working everywhere, also a Tinkerboard or MiQi owner could try to address wrong temperature (I personally would prefer a fix for the legacy kernel so that this old kernel we won't deal in 2018 any more with uses same sysfs nodes as mainline kernel!) but that's not related to any release (policy). And anyone contributing should be aware that armbianmonitor is tweaked constantly while only being updated from time to time as part of 'board support packages' so before you even start replace the armbianmonitor script in your local installation with latest version on Github.

 

Tido

Tido

Posted
  • Author
Posted
On 16.9.2017 at 1:53 PM, tkaiser said:

you constantly confuse

Ähm, I see this different, you (TK) confuse the users by not using specific names for each tool - but I understand the complexity.

Instead of complaining here, why not simply change its naming schema so it makes sense in the next release.

in example:

  • armbianmonitor -text
  • armbianmonitor -html

but this would be still confusing, because the main name stays the same. I cannot come up with a good idea - anyone else ?

 

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept