This is meant to be a summary of concrete statements (not rhetorical questions) from board support / project aims thread. I'm only focusing on trying to capture formalities regarding:
- Mission Statement
- Definition of Boad Support
- Policy around release management
- Ownership and Roles
Note: I did a lot of pruning, but I did my best to be unbiased and to misrepresent the discussion
The need for this breakdown is probably best captured by Tido:
Captain Chaos, I don't have the time to read each time 10 posts and make notes to find out where we are standing form one post and topic to the next. https://forum.armbian.com/topic/6281-board-support-general-discussion-project-aims/?do=findComment&comment=64051
I see it as Ubuntu/Debian + bootloader with customizations + available kernel(s) with customizations + minimal OS (userspace) customizations and some optional tools/scripts like armbian-config
my opinion:
armbian is a 'base plate' so that everyone can build his own house on top of it. armbian tries to catch fixes to improve the support situation for the hardware a boardmaker provides
View Armbian as a base, reasonably minimal OS images. https://forum.armbian.com/topic/6281-board-support-general-discussion-project-aims/?do=findComment&comment=47987
(In response to Zador's view)
Yes, this is a good description, but how users see this? Each Linux distribution is nothing but a mix of just some packages. Some only mix and add a stamp, others do big changes.
Reasonable minimal OS images, exactly.
One of the major goals of the project is to achieve universality among big diversity. Which is good. Now, moving more toward IOT use case would be the way to go. IMO a desktop is good enough and doesn't need more attention. At least not from a primary team. If there are folks, who have the intention to tune this up, perhaps even fix some web acceleration within Chromium ... welcome to play around and fix that overbranding mentioned by @zador.blood.stained Perhaps I really went too far with it.
Armbian is a base OS platform for SBCs that other projects can trust to build upon.
Would it make sense that the generic armbian has no HW acc. decoding but in the buildscript there's a option to activate (where possible) it?
For getting 'full armbian support', would it make sense to define that for minimum X (X<1 in case someone drops out from the project or hasn't the time at the moment) of the maintainers have this board physically at home? Not only a pre-production sample but also the version which is sold to the customers. Doesn't mean that you have to test every build before deploying but in case something breaks someone (experienced enough to use proper powering, sd-card, networking etc.) can confirm/deny it.
If there's no (or only minor) interest from a developer and nobody from the community want to test things which are made for random board, I see no reason to keep support. Maybe this 'motivates' the owners of those boards to 'step in' and help with easy tasks (like testing basic function). When not, @TonyMac32s approach, "freezing", seems to be a good idea
Support proposals are IMO needed when we talk about a new SoCs.
In case there is enough interest in bringing up a 'board support' policy. I can offer to write this down to a readable text/document. But I only do it if you as devs actively peer-review it and if I get enough input from your side to make it happen. I don't feel comfortable to write a draft on without inputs from your side...
When a board can come to a support list:
- if there are not a lot of problems and most of the stuff already work. At least: network, (HDMI), thermal protection, to run as a server.
- if there is at least one stable kernel,
- if we got minimum of two boards/persons to cover, except special cases, where one board is stripped version of the one we already support
- [new] if we have chosen a responsible person(s), not necessarily a developer, for editing board status and to join perhaps with personal motives and spread responsibility. Technical part of editing is under rework and will be done in some simple manner within a Wordpress only (no more WP + github .conf + github. Putting to other words – if we, as a community, wanted to have longer support for certain boards or their less aggressive moving to »deprecated« section, we need people to take a part in this maintainer/tester role - to take responsibility. BTW: last week I throw out some obvious deprecated candidates, while I still have some left: Odroid C1, Bananapi+, Beelink X2, Lime1. From a kernel perspective: sun4i, sun7i, odroid1
In essence is all about a kernel, not boards. I would rather start talking from there, always. And what @zador.blood.stained already exposed - there is usually a personal motive to work on some board or type of problems and we have to consider that, when doing some plans or talking and organising the work around the project, but certain things, those which might not require a lot of time and energy, could be agreed upon.
Another unwritten rule is that test/beta/nightly downloads starts when basic board functions work. This exists. Download page should only tell them what to expect and inform them with a support status. t is also a possible window to welcome new developers if done properly.
on dropped boards to csc
My proposition is to write a clear conditions under which a board can come back. To the community supported configuration. This means we will update images, but that's all what can be done.
if the board satisfies the "to be supported" criteria (enough samples, no serious design flaws, good BSP or based on already supported platform) then it gets the WIP status,
if the board was added by a community contributor, if there is no interest in making stable/supported releases then it gets the CSC status,
anything else gets the WIP status that can be later changes to CSC.
- We have no requirement to support any board. If it is not in our personal interest or benefit it simply won't happen. I think some of the "regular devs" feel pressure and get frustrated that they can't satisfy the whims of the general public.
- We have too small of a team to deal with demands and general Linux questions.
- the code is all public and opensource, anyone can contribute/fork to do whatever they like board support wise.
"Supported" is not a gaurantee. "Supported" implies a particular SBC is at a high level of software maturity, and should perform well under normal circumtances. Supported Board do receive preferential treatment to bugfix, improve, or add additional functionality based on any of the following, non-excluse criteria:
- The discretion of the "Armbian Development Team"
- The availability of the "Armiban Development Team"
- The availability of sample boards and ease of testing
- The mainline kernel maturity for the particular SoC or SBC platform
- Paid engagements or long-term sponsorship to the Armbian Project or developers.
- Vendor or 3rd party has a designated resource providing support for a SBC or platform ON BEHALF OF THE COMMUNITY and is contributing to the project.
- [new] if we have chosen a responsible person(s), not necessarily a developer, for editing board status and to join perhaps with personal motives and spread responsibility. Technical part of editing is under rework and will be done in some simple manner within a Wordpress only (no more WP + github .conf + github. Putting to other words – if we, as a community, wanted to have longer support for certain boards or their less aggressive moving to »deprecated« section, we need people to take a part in this maintainer/tester role - to take responsibility. BTW: last week I throw out some obvious deprecated candidates, while I still have some left: Odroid C1, Bananapi+, Beelink X2, Lime1. From a kernel perspective: sun4i, sun7i, odroid1
Let's simply reuse this term and - at the new web - expose this as a non-technical necessity "maintainer wanted" to move from WIP to supported section.
Instead of telling people what to do. Let's ask people if they want to take responsibility as such:
source code maintainer - adjust kernel configurations, patches, ... help on what we do,
project manager: development and testings overview, samples redistribution
code cleaner - sweeping our build script code round the clock
documentation editor - as a title implies
marketing manager - to help communicate project specific services, new features, changes, ...
There was never a formal team. More like a strong common passion and interest to do something valuable, to push things forward, to help, to show how things should look like. IMO it worked very well until the level of self-fulfillment and happines was high enough and a mountain of problems low enough.
Armbian might not need major build script or infrastructure development, but both need regular maintenance. We are short already for that. Not hardware, not software but responsibility.
Personally, I need to look on a project from a distance and leave super (hardware) details behind. It might give me an opportunity to better see the problems we have.
Mainline u-boot and kernel (and some other projects) have "MAINTAINERS" files (example) to track who is responsible for specific files and directories in the repository and so who should ACK or NAK any changes that are about to be merged there, so we could have something similar - at least GitHub name + file/dir path + status and a list of things that can be added without unneeded discussions (i.e. activate kernel config options related to third party hardware support, make a repository-wide refactoring/rework which involves adding/renaming/removing variables, etc.).
in response to marketing manager role
or rather an "unmarketing manager" to reduce the attention to the project to help developers catch their breath
E.g. 'maintainership' includes proper testing of boards before each 'major' release (e.g. subversion kernel change for next, or u-boot change) testing and adjusting patches in dev after every sublevel jump.
The idea is marvelous, just how to get it up and rolling? I think we need a moderator/project manager for this section, something like @chwe is doing in this thread. Someone who transforms our ideas and babble into tasks? We are already under heavy load, I tend to be lazy when things jump outside of a primary goal and pessimistic that someone will just take and resolve some task.
response to tkaiser about bleeding edge kernel updates
No, we don't. Current Allwinner next branch has yet another problem. sun8i support was merged into sunxi and now it is a bit difficult to go back until upstream gets solved. The idea is to stay still on 4.14.y and apply bugfix patches only.
Regarding u-boot I vote for a conservative approach. We don't update it unless it's tested very well or necessary. This will require switching repository upgrading to semi-manual mode.
TonyMac32 agreed to above see https://forum.armbian.com/topic/6281-board-support-general-discussion-project-aims/?do=findComment&comment=50865
on kernel promotion
DEV becomes NEXT when the time is right.
on releases and updates
Can we agree on a definition - and once we have it outlined put it into the readme.md and documentation?
I suggest future upgrade procedure:
stable only receives security updates - low maintenance effort but high stability after 6,7,8,9,10 (to be defined) months a freeze in development -> beta.armbian.com the community does tests of the BETA (2 weeks), (still freeze in dev) report bugs bugfixes period for 3 weeks (devs cannot work day and night, family, job, etc.) = RC1 the community does tests RC1 (2 weeks), (still freeze in dev) report bugs another round as in 4. or ready for stable release updateUpdate Distribution:
Google first delivers new Android to 1-5% of the devices for us this could mean only one SBC per SoC (ie. OPi Zero H2+ | OPi PC H3 | BPi A20 etc.) for one week. We get information on different-update-scenario's (from us untested, who knows) and SBC usage, diverse/unforeseen feedback (as in my past the IBM AS400 welcomed me: No News - Good News)
on patch placement
I would argue that any patches going into the main kernel patch directory for a given kernel should be "board agnostic" and be things like device driver additions/updates, dtsi/dts bugfixes, etc. For a specific board then, come the "ugly" hack job patches, that would be a problem to maintain no matter where they were.
on update policy
The main area we should focus on IMO is 'upgrade experience' since while it's quite OK if new images don't work or are malfunctioning users get it that there's something wrong rather quick -- they might only loose some time. But with updates ending up with bricked boards it's a real mess since we destroy productive (server) installations.
Do we need to force bleeding edge mainline kernel always? There's a reason Debian and Ubuntu use their own kernels and backport fixes. That's not a solution for us
Paraphrase above: We do not need to force bleeding edge mainline kernels.
tracked by chwe and tido https://forum.armbian.com/topic/6281-board-support-general-discussion-project-aims/?do=findComment&comment=63065
tracked by chwe and tido https://forum.armbian.com/topic/6281-board-support-general-discussion-project-aims/?do=findComment&comment=63065