board support - general discussion / project aims

[zador.blood.stained]

1 minute ago, Igor said:

I will migrate main build host to Bionic ASAP that it is possible to put out Bionic (nightly) builds.

I tested Bionic host (server image installed from scratch) and can confirm that at least all dependencies are correctly installed and at least sunxi-next u-boot from master builds without issues. Since my main build host is currently a remote machine I don't want to dist-upgrade it over SSH and will do this locally, maybe in 1-2 weeks.

 

We still have to split Bionic host support (should be relatively easy, though we will need to check Docker and Vagrant build methods too) and Bionic target support.

 

7 minutes ago, Igor said:

perhaps we should just merge the rest, dump development branch for a while and focus fixing bugs on master only.

IMO we should merge tested stuff in batches, not the whole branch, and then reset the "development" branch to purge what's left. I'm not sure if i.e. sunxi-dev/sunxi64-dev is worth merging given how much stuff there is broken or not tested.

[TonyMac32]

4 minutes ago, zador.blood.stained said:

IMO we should merge tested stuff in batches

19 minutes ago, Igor said:

The development branch is reinitiated for next development cycle?

Should we start branches per SoC/Family as briefly discussed earlier?  It would reduce the insanity perhaps, by adding another (more easily sorted) insanity. 

[Igor]

1 minute ago, zador.blood.stained said:

I'm not sure if i.e. sunxi-dev/sunxi64-dev is worth merging given how much stuff there is broken or not tested.

Currently is in a bad shape but you can at least build something while on master sunxi-dev is completely broken. IMO it's better to keep things in one branch. The diff, patches, are more tied to the upstream and not the build script itself.

 

8 minutes ago, TonyMac32 said:

Should we start branches per SoC/Family as briefly discussed earlier?

My first go is for KISS. Complexity is already high. 

 

To have family development parts in dedicated branches or having forks of main build script and merging upstream? 

[TonyMac32]

15 minutes ago, Igor said:

To have family development parts in dedicated branches or having forks of main build script and merging upstream? 

I agree KISS is best, but we might have to give up some for user stability.  The development branch demonstrated the stumbing blocks almost immediately, in not being granular enough. It makes maintaining the history of changes better to add a little granularity.   If similar problems happen in a family-specific fork or branch, it should be much easier to sort out, and can be done by the primary contributor to that branch/fork, and they can ask for a review of the merge if they have any concerns (IE, bootscript stuff, new/old/removed blobs, etc). 

 

It would add some extra work for upstream patches and the addition of drivers across all platforms (like wireless), but truthfully that could probably be implemented in a build-script-maintenance branch and then merged upstream, where everyone else can pull it down and see how their WIP reacts.

 

For forks vs branches, I think the result is the same, but if the working branch variable can be modified on the command line instead of only in the script that may be easier on the user of the script, rather than cloning a different repo if they want to do a PR they just need to go to the proper branch.

[zador.blood.stained]

4 minutes ago, TonyMac32 said:

The development branch demonstrated the stumbing blocks almost immediately, in not being granular enough.

It's not exactly that the branch is not granular enough, it's that commits in that branch are not granular enough so you can't do a cherry-pick or rebase without editing commits.

 

Example: https://github.com/armbian/build/commit/fef367e07d77ddf608affa6bb12bfb7b73258b27

This commit touches both mvebu64-default and rk3328-default families, so if one is tested and ready to be merged but the other is not then this commit needs to be split in 2 first.

 

Example: https://github.com/armbian/build/commit/96021fe5e6d1f5c0e8adf41872cac40e7494e8e3

Upstream patches for multiple platforms (tested at least for not breaking the compilation) can be merged straight to master since they usually bring more bugfixes than bugs . Same with enabling a useful option in multiple kernel configs.

[TonyMac32]

Well, you could consider it "enforced granularity". ;-)

[Igor]

Mainly mine commits are "practical"  Another problem contributing to the mess is mixing development, maintenance and bug fixing type of work. Sometimes goes like this: developed - fixed - 100% working fix - oh no, it's not working! - another fix  That should be sorted out locally first and then pushed up. I know.

Perhaps gaining commit consistency first is already good enough and we don't need per family branches? The only reason for using official branches and not private forks is to enforce common activities ... while on the other hand, one certain problem is usually done by one person. And this can be done in a private fork and merged upstream when ready.

[zador.blood.stained]

41 minutes ago, Igor said:

That should be sorted out locally first and then pushed up. I know.

Or it could be pushed into a separate branch, stay there while it needs testing, and then squashed into one commit and merged to master. While master is currently set to protected so it is not possible to change existing commits,  commits in other branches may be rebased, squashed or amended if necessary.

 

45 minutes ago, Igor said:

Perhaps gaining commit consistency first is already good enough and we don't need per family branches?

We could still create temporary topic branches on demand (i.e. sunxi-next-4.17) for large change sets.

[Igor]

On 4/29/2018 at 4:53 PM, zador.blood.stained said:

Instead of finding and cherry-picking specific commits it may be easier to just check out the "development" branch on top of the "master" without switching branches and then manually git add/git add -p and commit stable and tested changes for specific topics (i.e. rk32xx, rk33xx, mvebu64, cubox, etc.). When using a GUI application (i.e. gitg on Linux and git-gui on Windows) it's relatively easy to see and group necessary changes (i.e. config/sources/... + config/kernel/... + patch/kernel/... for any kernel related updates).

I am trying to use this approach but no luck. It looks like my Gitfu is not ready for proper advance Git manipulation. I only know dirty ways atm.

Perhaps it is better than you do this merge since for me all looks safe - "one big pull request"  Merge everything, except those Bionic hacks to the master and focus to make master as stable as possible and start with a new development(s) fork(s)? Not necessarily today but after a few more test builds.

[manuti]

Is totally off-topic, but someone can change the title of this post, because it says: "bordsupport general discussion ..." instead of "board support general discussion ...".

Thanks.

[Tido]

With the discussion over at ZRAM vs SWAP it was also mentioned this topic and some frustration having its roots in the current way of 'improvement'.

That made me think about how to solve this situation and going back having fun being here for all, especially the developers.

 

How to solve problems in general:

1. Break Big Tasks Into Smaller Pieces
2. Solve the ones that stress you the most first
3. Eisenhower matrix to support taking a decision where to start
4. make use of the power of the community, post about your problems, ask for help - especially testing

This is not to teach you, just a reminder - so please don't mind.

 

Beta-Branch:

there is no purpose in recently added "development" branch if "master" is completely abandoned as a result and suggesting to "switch to beta" to fix any issues defeats the purpose of "beta" - fixes should be immediately pushed to the stable branch and beta should be left for non-production ready stuff.

 This branch is 242 commits ahead, 42 commits behind master.

So this should be discussed and find a way how to go forward. Two things come to my mind:

1. What I just read here about Kernel Development (thank you @chwe)

Spoiler

Quote

With the release of the 2.6 kernel in December of 2003, the kernel developer community switched from the previous model of having a separate development and stable kernel branch, and moved to a “stable only” branch model. A new release happened every 2 to 3 months, and that release was declared “stable” and recommended for all users to run.

 

This change in development model was due to the very long release cycle prior to the 2.6 kernel (almost 3 years), and the struggle to maintain two different branches of the codebase at the same time.

 

2. To adjust current development to such a modell (link inside)

 

 

Multi-User  Build environment:

It's not set up for multi-user scenario yet (VM guests for different tasks and users instead of one shared space otherwise manual build tasks may conflict with automated ones).

Break Big Tasks Into Smaller Pieces - @Igor is there a way to improve ?

 

 

ZRAM vs SWAP:

Because zram-config package exists only in Ubuntu by default, and for reasons I don't remember (probably version numbering / potential repository priority issues?) we decided to not copy it to our repository to be available for all releases.

I guess it makes sense to continue this discussion in its Thread

 

 

log2RAM:

@zador.blood.stained, already has ideas in another thread... unfortunately, I cannot find it anymore but I am sure you remember. We could continue this development in this thread maybe:

https://forum.armbian.com/topic/5588-log2ram-issue/ and here

https://forum.armbian.com/topic/6444-varlog-file-fills-up-to-100-using-pihole and

https://forum.armbian.com/topic/7398-bsp-scripts-rfc/

 

 

 

PS: forgive me my straight words, I am everything else but a master of writing, even though I try ;-)

Edited June 9, 2018 by Tido
because of splitting log2RAM added Link

[Tido]

On 5/19/2018 at 11:33 AM, Tido said:

Multi-User  Build environment:

It's not set up for multi-user scenario yet (VM guests for different tasks and users instead of one shared space otherwise manual build tasks may conflict with automated ones).

Break Big Tasks Into Smaller Pieces

 

 @zador.blood.stained did you discuss a change in that regard to ease the situation?

 

[ag123]

 

On 4/30/2018 at 1:57 AM, zador.blood.stained said:

I'm not sure if i.e. sunxi-dev/sunxi64-dev is worth merging given how much stuff there is broken or not tested.

 

On 4/30/2018 at 2:21 AM, Igor said:

Currently is in a bad shape but you can at least build something while on master sunxi-dev is completely broken.

 

i'm not too sure if the comments are still relevant for sunxi-dev kernel 4.18.8

but as i recently tested out armbian 5.59 transiting to 5.60, some of my findings with sunxi-dev kernel 4.18.8 are echoed 

 

here

and here

however, it do looks like linux kernel 4.19 release is rather close, it is already at 4.19rc4

https://www.kernel.org/

the commits on the main kernel tree is just as relentless

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/

 

perhaps we'd do sunxi-dev 4.19 when it is out of rc rather than 4.18.8?

and we'd perhaps leave 5.60 on 4.14.70 kernel? this is working very well on orange pi pc thanks for all that effort @Igor et.al

 

but i think it is a little early to hold out too much hope on 4.19, i think the various late development fixes in 4.18.y linux-sunxi by the kernel team 'out there' would be in 4.19

that is a good thing as more mainline support would be built in. however, many of that broken in 4.18.8 may remain broken in 4.19 e.g. the sunxi64-dev

 

[Igor]

8 hours ago, ag123 said:

perhaps we'd do sunxi-dev 4.19 when it is out of rc rather than 4.18.8?

Yes, that is planned, but we still have weeks - we also don't need to jump on v4.19.0 ... It's DEV kernel and the idea is that DEV becomes NEXT when the time is right. Which is even more distant. Since 4.19.y is the next LTS it will be worth to prepare it and port support from more recent versions. 4.19.y is for 2019

[ag123]

my apologies to have detoured from the topic, but yup no hurry to 'rush' into 4.19, it isn't 'born' yet , for now i think there is still the job of moving to 5.60 and actually fix issues found in 5.60

 

back on topic. one of those things is a 'modularised' build and deploy.

if we could imagine we have build environments : stable, next and dev

a 'development environment change flow'  may be pictured as simply the reverse

dev, next, stable (production)

the trouble with projects grown this large is there are x number of socs, y number of boards, and z sets of kernels with specific patches that is not in mainline (and to add to that applications issues e.g. firefox, chromium and their giant suit of plugins, video acceleration, open gl es etc)

at any one time a fix done for x soc, y board on z kernel, that may well be tested ok, but the rest of x socs, y boards, z kernels may well be still WIP and things are continuously happening

ideally we'd be able to deploy the fix for x soc, y board on a particular 'module' say into 'next' for more testing before committing the same fix to stable.

it isn't easy at all to manage that let alone even with git. git branches etc tend to take things 'wholesale', hence during a merge those WIP things say from other socs / boards get applied during the merge as well.

one of those thoughts is say even with development branches that perhaps it may be possible to split the branches into the distinct groups. e.g.by socs/boards/kernels (i'd think at least soc & kernel) and even an 'application' branch. i'm not too sure if doing something like this could help to ease efforts when it comes to merging the fixes.

of course the other way is to think of the main armbian build repository as 'master', and the development and next in separate repositories so that changes to armbian build 'master' comes as pull requests. and in the development repository there could be several branches say for groups of soc / kernels so that they are rather distinct to ease merging efforts

well just thinking aloud, i'm not sure if this solve anything at all and may instead simply add complexity

 

 

[Igor]

 

There are still (many)some (short and) long-term questions which are scattered on the forum and in our heads which we would need to discuss.

 

- release naming, 2018.10 or 18.04 + some RFC as shown on the pic,

- collecting wishes on a special web page or forum topic. When someone approaches with "I want to help" that it is appointed to 1. Check issues on GH, 2. Fixing sound ... 3. Creating this ...

- improving testing protocols, automating what is possible. I'm low on ideas what more is possible to do.

- what to add to »end of support«?

- secure project longterm survival, leverage maintenance costs to users or drastically limit down free support,

- enforce browser of choice for desktop images, Firefox and/or some lighter alternatives?

- fix Bluetooth on all Broadcom AP62xx devices. Its the same on most boards, but we have it working only on a Cubietruck IIRC

- sum most frequent problems under »The Ten Commandments« / FAQ and promote it as much as possible

 

- does forum need structure update?

- add/remove moderators? Disable rights if not moderating content in past 6months?

- enforce forum rules? Some very simple ones.
- users are still seeking for help without providing logs. What to do about?

Download UX:

- make a bigger diff between nightly and stable, desktop and CLI (Gorazd)

- add a warning when nightly is downloaded, (Gorazd)
- tested devices lead to their test page where exists instead of Amazon affiliate, (Gorazd)

- tested hardware have information to which kernel is attached to but not displayed, (Gorazd)

- check other download option still no visible enough, (Gorazd)

- add a support box with 1. Check common issues 2. Search for solution 3. Ask (with a link to the correct forum) (Gorazd)

- add a button »alternative builds« with a link to dl.armbian.com/DEVICE (Gorazd)

 

To keep things in place, I would like to ask @Tido and @chwe  to help keep this 2do list up2date according to with our decisions.

[chwe]

3 hours ago, Igor said:

- improving testing protocols, automating what is possible. I'm low on ideas what more is possible to do.

I did some testings with DVFS and USB.. USB is possible with mass-storage. DVFS tests weren't that reliable.. needs some adjustments to be sure. (had false negatives..  ) pci will be needed in the future.. maybe usb2/usb3 not only USB.. 

 

3 hours ago, Igor said:

- what to add to »end of support«?

- Allwinner 3.4  as soon as 4.19 is ready to go.  (drop some 'boring' H3/H5 boards? especially most/some microUSB powered boards - they just generate a way more support questions than the barrel plug boards)

- If I've time I'll write a summarize script (e.g. how often images for *random board* was downloaded in the last month/6month). This should give us some insights  which boards we can drop. 

3 hours ago, Igor said:

- secure project longterm survival, leverage maintenance costs to users or drastically limit down free support,

- split patches (all csc patches to subfolders) and 'actively' not maintain those patches..  If csc users don't adjust them alone it's simply not done anymore. I don't know how much time you waste for adjusting all those patches with every kernel update.

- drop as many BSP kernels as possible and stick all next to LTS kernels? I assume that LTS upgrades don't break patches that often or am I wrong here? 

- For rk3288 @TonyMac32 and I had a 'cheatsheet' (outdated now https://github.com/armbian/build/blob/master/patch/kernel/rockchip-default/00_cheatsheet.md) but I would suggest that we implement this for every feature we have implemented before it reaches mainline. E.g. I had a look into sunxi 4.19 last week just to realize that more or less the whole a64 drm patchseries can be killed cause it will be mainlined in 4.19. IMO it would make sense to have such infos on a 'cheatsheet'.  

- Limit support is somehow complicated, we should maybe split 'not armbian related' stuff out of the tech. support forums more aggressively. E.g. (specific post, not the whole thread.)

- maybe minimal requirements for desktop images (e.g. >= 1gb ram)? I'm not that experienced with desktop, probably I shouldn't suggest ideas here..  

 

it somehow becomes a trend that forum.armbian.com is the 'place to be' for everything 'SBC related'  I like some rules from mailing lists e.g. (https://www.freebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/etiquette.html)

Quote

It is always considered bad form to ask a question that is already answered in the above documents. This is not because the volunteers who work on this project are particularly mean people, but after a certain number of times answering the same questions over and over again, frustration begins to set in. This is particularly true if there is an existing answer to the question that is already available. Always keep in mind that almost all of the work done on FreeBSD is done by volunteers, and that we are only human.

 

4 hours ago, Igor said:

- enforce forum rules? Some very simple ones.
- users are still seeking for help without providing logs. What to do about?

well a rather drastic one: if [ question != armbianmonitor]; then; post > /dev/null; fi 

explain that every question in technical support must contain armbianmonitor even when you don't think it's needed otherwise we'll delete (or less drastic hide) your post. This will need some additional work in the beginnings but I hope that people get it over time.. 

 

4 hours ago, Igor said:

- make a bigger diff between nightly and stable, desktop and CLI (Gorazd)

provide everything except stable only on dl.armbian.com? We've IMO many support questions for allwinner H6 but besides you, nobody seems to be interested to push H6 support (my orangepi one plus never booted armbian  but it's a good dust collector.. ). 

 

4 hours ago, Igor said:

- add/remove moderators? Disable rights if not moderating content in past 6months?

do we have inactive moderators? Do we have people who want to do some moderator stuff? e.g. @TonyMac32? 

[Igor]

We have to get to some action plan on a broader scale. Not going too much into the details. That should be done elsewhere.

 

1. Shall we switch to minor version? Any concerns?

2. Dropping Allwinner default is still questionable. There are still many users of it for various reasons. Not just video acceleration. I would rather proceed with switching NEXT and DEV as it was already made, but too soon. AW support in 4.14.y is far from the best and is not getting any improvements. Beside upstream changes unrelated to Allwinner support. 

3. Collecting wishes on a special web page or forum topic. This is a very important issue. Whenever we talk about that we don't have people. Yes, we don't have. I can only work less in the future since I have family duties and plenty of other things to do. If there will be just a few random people fixing/hacking things here and there, you can forget to plan any topic related to development. We don't have developers and until this point is not improved, we can stop talking about what to do. Planning and organizing included. Let's focus on how to attract people, how some random person with know-how and wish to help can start working on. He needs guides or personal assistance. Remember that I more often don't have time even to reply to their emails and opportunities go to /dev/null. It already happened a few times.

4. Improving testing protocols should be a guide backed with additional automation. A manual how to and how not to start with testings to get things done. Summary of what we learn so far. We need to find a way to eliminate border cases as such? This means pushing thing to another level. I think we simply lack resources.

5. What to add to »end of support«? My proposition: Olimex Lime2 NAND, Bananapi PRO, Olimex Micro, Orangepi Pi2, Orangepi+, Nanopi M1,  MiQi, NanopiM1+ Any concerns? Another idea to add here. Instead of moving to EOS, we could put a counter. "3 months until going to EOS. Seeking for maintainer". In case someone steps up, a board is getting CSC status. We need a person to communicate this and that will not be me.

6. Secure project longterm survival is not a technical question but ... what if major project contributors leave the project, completely lost interest or is run by a bus. A project is developed openly, but infrastructure is not. It is scattered all around.

10 hours ago, chwe said:

drop as many BSP kernels as possible

Valid at least by the end of this year:
 

Pine64 3.10.y is not ready to be dropped.
RK3288 ???

3328 and 3399 is not ready to be dropped,
cubox 3.14.y and Udoo can be dropped,
Meson 3.10.y default ???

SP6818-default 4.4.y was never finished and nobody works on it and can be dropped,

 

10 hours ago, chwe said:

maybe minimal requirements for desktop images

This raises a question to provide 32bit userland as a matter of choice. This is especially needed for 64bit boards and not much memory. It would be nice to have but I really don't know how much work will this bring. 

Since the desktop upgrade is now simple and functional, providing desktop images is IMO not critical. But we lack the promotion (=repeating things over and over) that this is possible. That a desktop image is exactly the same as CLI + armbian-config way of setting the desktop. With one exception. Legacy desktop builds which have video acceleration support. This part was not implemented and not sure if it will be in the state.

 

10 hours ago, chwe said:

I like some rules from mailing lists

They have to meet one crucial rule: KISS

 

10 hours ago, chwe said:

well a rather drastic one: if [ question != armbianmonitor]; then; post > /dev/null; fi

Not the best way to welcome people  You don't need to be a technical person to answer to such post. This should be one of the top 5 moderator duties. With exception of @tido, all can make use of ready-made templates for a topic answer: "Please provide this because... "
 

10 hours ago, chwe said:

provide everything except stable only on dl.armbian.com? We've IMO many support questions for allwinner H6 but besides you, nobody seems to be interested to push H6 support

 

People test and play with them, sometimes we don't.  Some people are interested in those boards, other doesn't even try to look. Because we have different interest, no time or simply because support is not matured enough for any real-world usage. But they will eventually become usable. H6 has potential in the (biggest) cheap section. 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.

 

10 hours ago, chwe said:

do we have inactive moderators?

Don't know. We can find that out by pinging them.

[chwe]

2 hours ago, Igor said:

13 hours ago, chwe said:

maybe minimal requirements for desktop images

This raises a question to provide 32bit userland as a matter of choice. This is especially needed for 64bit boards and not much memory. It would be nice to have but I really don't know how much work will this bring. 

do we have resources for such additional feature? this somehow doesn't fit with:

2 hours ago, Igor said:

We don't have developers and until this point is not improved, we can stop talking about what to do. Planning and organizing included.

 

As you've explained, desktop can be installed via armbian-config.. so no need to provide desktop images for those boards. If people want it, armbian-config is their way. 

For the 32bit userland, this seems to be interesting but there aren't really open resources for such a project. I suggest that someone writes proposal like:

Quote

We assume that a 32bit userspace can be beneficial for 64bit boards with low memory. This will need adjustments in the buildscript and testing.

A starting point would be: xxx

In case you're interested to bring up this feature @.. will help you for buildscript related questions @.. will help you for testing and benchmarking it to see if there's a performance gain. We would prefer to bring up this feature in public but you can get some 1 to 1 training during this process. 

I've no idea if this works. I tried it once with GbE on H6 were it doesn't work that well. Maybe it was just 'no luck' or it wasn't that easy that I expected. I simply didn't test it on my own to see if it is possible to give some guidance without doing the work on my own in the back to be sure that it will work. Maybe it was me who was the wrong person, well, we will never find it out.  

 

We might consider bringing 'mainline kernel people' together with patch submitters. E.g. https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-nanopi-duo.patch is in armbian since Oct 31, 2017 but as far as I see, no attempts were made to mainline the Nanopi duo (I can be wrong on that). With @Icenowy we've someone who is familiar with the whole mainline patch submit process.  So if we can now bring patch-authors and @Icenowy together to bring up the the duo in mainline, we've at least one patch less to maintain (and Maxime Ripard doesn't blame us for *not contribute* https://lkml.org/lkml/2018/5/11/107 ). This will only work when @Icenowy wants to help others submitting patches to mainline and if the original patch submitter wants to deal with kernel people.  (I just picked this patch as en example, we've sure some other patches which might be possible for mainline e.g. BPi-M2-Zero got its SY8113B node, whereas the OPi lite didn't - looks like a low hanging fruit to me if you want to be a mainline contributor).

 

2 hours ago, Igor said:

2. Dropping Allwinner default is still questionable. There are still many users of it for various reasons. Not just video acceleration. I would rather proceed with switching NEXT and DEV as it was already made, but too soon. AW support in 4.14.y is far from the best and is not getting any improvements. Beside upstream changes unrelated to Allwinner support. 

4.19 will be an LTS kernel and will support a way more in mainline that 4.14 did. As soon as we switch with armbian next to 4.19 we might consider dropping 3.4. We can still provide 3.4 images for download but don't provide u-boot updates anymore for them. Keep them 'AS IS' and rearange the forum so that https://forum.armbian.com/forum/13-allwinner-h2-h3/ directs you to mainline and a subforum for 'legacy' is there for those who still want the BSP kernel for what ever reasons. The debian/ubuntu packages will still get updates from upstream for the 3.4 kernel images but the kernel won't get updates anyway cause EOL and personally I don't see a reason to deliver u-boot updates as well for such an old kernel, it needs testing and resources which we don't really have. If this helps to avoid:

2 hours ago, Igor said:

We need to find a way to eliminate border cases as such?

so be it. Break updates --> frustration --> less contribution. Whereas: less things to care --> some breath --> hopefully such stuff doesn't happen that often anymore..

For me our workflow in updates looks wrong. 

We have: beta --> stable (apt.armbian.com - do testing/break working images) --> provide images on https://www.armbian.com/download/

Whereas it should be IMO: beta --> provide images on https://www.armbian.com/download/ (do testing) --> stable (apt.armbian.com)

It's a way less frustrating when a new image doesn't work as expected - you didn't waste that much time in setting up *random stuff*. Whereas it is frustrating  if *random user* spent a bunch of time to set up his board and an update breaks it (and 'we' have to guide him through all recover processes to bring back the image). This won't avoid break for every update but hopefully less than the current workflow.

Edited October 1, 2018 by chwe
some typso etc. (I'm sure there are still typos.. :P )

[chwe]

2 hours ago, Igor said:

6. Secure project longterm survival is not a technical question but ... what if major project contributors leave the project, completely lost interest or is run by a bus. A project is developed openly, but infrastructure is not. It is scattered all around.

well, let's forbid buses in Ljubljana, Munich & Russia at all...  Hope that @TonyMac32s truck is heavy enough to survive a bus hit and the Canadian health care system seems to be good enough that @martinayotte would fully recover even when he was hit by a bus. 

And now a bit more serious, we don't have a 'plan b' if/when a top maintainer disappears. We will lose knowledge and contribution which we can't replace. I don't trust in 'everyone can be replaced' (at least not for 'small projects'/spare-time projects). Let's find a way to keep the frustration level for our top maintainers as low as possible even if this means that we've to shrink the project slightly to keep it more healthy. 

[Igor]

3 hours ago, chwe said:

together with patch submitters

Yes. Now we have many patches that are either our origin or changed from the 3rd party. We ("only") need to define a protocol ... like we need a better/more polished protocol for testing.

 

3 hours ago, chwe said:

This raises a question to provide 32bit userland as a matter of choice.

We have resources for something but not for all. We also need to create or find resources for the current state of the project. Without doing anything extra! I don't know what will be possible to do and when from a current perspective. Let's keep things on the list even we might not solve them. This is nothing new.

 

3 hours ago, chwe said:

As soon as we switch with armbian next to 4.19 we might consider dropping 3.4.

 

At least this is not exactly urgent. A default branch can be 1st pushed under EXPERT/unsupported but not removed. Yet.

 

3 hours ago, chwe said:

spent a bunch of time to set up his board and an update breaks it

 

Current update logic is as follows. When its time for the update, when nightly builds run fine ... we test images and push out a 1st stable images (we could call them RC). The update follows after a while (few weeks) when second test force - users installing a system from new images, which should at least boot up to 99% - report those few remaining issues. This was the core idea in a last major update and there was actually an extremely low reported failures. I am actually very happy, but the price was higher than I am willing to accept. If this is once per year, ok, but if we start pushing out updates more often, this is not sustainable.
 

3 hours ago, chwe said:

Let's find a way to keep the frustration level for our top maintainers as low as possible even if this means that we've to shrink the project slightly to keep it more healthy. 

 

 

 

If just a few people are aware of problems while the rest have no idea how hard is to make things happen, they will continue to push on us with full force (until we break down). We need to communicate properly that support is as is and there is nobody here waiting for users complains. Sometimes we solve things promptly, sometimes we file them for the future, some are ignored. More later ... life is calling.

[chwe]

1 hour ago, Igor said:

... life is calling.

who gave you a permission to have a life?  Just kidding here.. 

 

23 hours ago, Igor said:

There are still (many)some (short and) long-term questions which are scattered on the forum and in our heads which we would need to discuss.

 

- release naming, 2018.10 or 18.04 + some RFC as shown on the pic,

- collecting wishes on a special web page or forum topic. When someone approaches with "I want to help" that it is appointed to 1. Check issues on GH, 2. Fixing sound ... 3. Creating this ...

- improving testing protocols, automating what is possible. I'm low on ideas what more is possible to do.

- what to add to »end of support«?

• proposed: dropped kernels: cubox 3.14.y and Udoo, Meson 3.10.y default, SP6818-default 4.4.y
• proposed: Allwinner 3.4 --> EOS
• proposed: dropped boards: Olimex Lime2 NAND, Bananapi PRO, Olimex Micro, Orangepi Pi2, Orangepi+, Nanopi M1,  MiQi, NanopiM1+ 

- secure project longterm survival, leverage maintenance costs to users or drastically limit down free support,

• proposed: TBD  e.g. explain better what users can expect, how to find information

- enforce browser of choice for desktop images, Firefox and/or some lighter alternatives?

- fix Bluetooth on all Broadcom AP62xx devices. Its the same on most boards, but we have it working only on a Cubietruck IIRC

- sum most frequent problems under »The Ten Commandments« / FAQ and promote it as much as possible

 

- does forum need structure update?

• if 3.4 goes EOS change order (mainline/bsp) for Allwinner H2 & H3

- add/remove moderators? Disable rights if not moderating content in past 6months?

• @Tido do we have a list of all mods? (I thought there's one but couldn't find it anymore, just highlight them all here to see if they're active)

- enforce forum rules? Some very simple ones.
- users are still seeking for help without providing logs. What to do about?

Download UX:

- make a bigger diff between nightly and stable, desktop and CLI (Gorazd)

- add a warning when nightly is downloaded, (Gorazd)
- tested devices lead to their test page where exists instead of Amazon affiliate, (Gorazd)

- tested hardware have information to which kernel is attached to but not displayed, (Gorazd)

- check other download option still no visible enough, (Gorazd)

- add a support box with 1. Check common issues 2. Search for solution 3. Ask (with a link to the correct forum) (Gorazd)

- add a button »alternative builds« with a link to dl.armbian.com/DEVICE (Gorazd)

 

To keep things in place, I would like to ask @Tido and @chwe  to help keep this 2do list up2date according to with our decisions.

 

hope I got the most important points up to date. Otherwise people are allowed to edit and/or point me to stuff I missed. 

 

Edit: color convention orange porposed, if nobody disagrees in an reasonable timeframe (I'm thinking about 1-2 weeks) --> green, if there's more to discuss --> red. People can quote the part and clearly say that they disagree and I'll mark it red. But "I thought from my statement it is obvious that I disagree" doesn't count. 

Edited October 1, 2018 by chwe
give it a bit of color

[5kft]

5 hours ago, chwe said:

We might consider bringing 'mainline kernel people' together with patch submitters. E.g. https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/add-nanopi-duo.patch is in armbian since Oct 31, 2017 but as far as I see, no attempts were made to mainline the Nanopi duo (I can be wrong on that). With @Icenowy we've someone who is familiar with the whole mainline patch submit process.  So if we can now bring patch-authors and @Icenowy together to bring up the the duo in mainline, we've at least one patch less to maintain (and Maxime Ripard doesn't blame us for *not contribute* https://lkml.org/lkml/2018/5/11/107 ). This will only work when @Icenowy wants to help others submitting patches to mainline and if the original patch submitter wants to deal with kernel people.  (I just picked this patch as en example, we've sure some other patches which might be possible for mainline e.g. BPi-M2-Zero got its SY8113B node, whereas the OPi lite didn't - looks like a low hanging fruit to me if you want to be a mainline contributor).

 

It would be wonderful to upstream some of our changes into the mainline.  E.g., the sunxi-dev/next patchset is huge now, and it can be difficult to modify/fix existing patches because of patch order dependencies, which then will introduce even more patches...if we could simply fix the original source in the mainline then everyone benefits.  Is the process simply a matter of posting the changes into LKML?

[martinayotte]

15 minutes ago, 5kft said:

Is the process simply a matter of posting the changes into LKML?

If it would be that simple, most of our patches would be already present there ...

[martinayotte]

5 hours ago, chwe said:

the Canadian health care system seems to be good enough that @martinayotte would fully recover even when he was hit by a bus. 

I'm crossing my fingers and praying that it will never occur ...

[5kft]

2 hours ago, martinayotte said:

If it would be that simple, most of our patches would be already present there ...

 

Then Maxime Ripard perhaps shouldn't complain and should help make it easier for us?   Could @Icenowy shed some light on the process?  @Igor and @chwe are right in that we can't have any single points of failure.

[Icenowy]

8 hours ago, chwe said:

BPi-M2-Zero got its SY8113B node, whereas the OPi lite didn't - looks like a low hanging fruit to me if you want to be a mainline contributor

Yes, quite low -- BPi M2-Zero gets it just because I have that board. I just do not like to write patches for boards I don't own ;-)

[Icenowy]

4 minutes ago, 5kft said:

 

Then Maxime Ripard perhaps shouldn't complain and should help make it easier for us?   Could @Icenowy shed some light on the process?  @Igor and @chwe are right in that we can't have any single points of failure.

Read `process/submitting-patches.rst` in kernel source tree;

 

and don't hesitate to try ;-)

[chwe]

2 minutes ago, Icenowy said:

I just do not like to write patches for boards I don't own ;-)

understandable..  (working on hardware you don't have is something I could never do). But it is/was en example for a low hanging fruit where we could reduce our patch load and mainline could benefit as well. Maybe people are less afraid to ask you if their patch looks okay than sending it directly to lkml.  We won't be able to mainline all our adjustments and it's likely that some of our patches may need adjustments to be 'mainline compatible'.

Could be a project (like 32bit userland for low memory 64bit boards) to go through our patches and see what has chances to get mainlined.  

 

[TonyMac32]

6 hours ago, martinayotte said:

I'm crossing my fingers and praying that it will never occur ...

There isn't a waiting list on bus accidents I hope?? 

 

We don't use busses, every American has a 4WD V8 truck with giant tires and American flags flying in the bed.  :lol:.  I could get hit by one of those...