14:00:17 #startmeeting Jade 14:00:17 Meeting started Sat Apr 23 14:00:17 2022 UTC. The chair is IgorPec. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:17 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:34 #topic check-in 14:00:56 Good day 14:01:01 hi 14:01:08 Good after-morning! 14:01:29 get your coffee ready! :) 14:01:37 Yeah tom 14:01:48 brilliant idea 14:01:48 Time for second cup 14:02:44 Good morning 14:03:00 <08W​erner> https://cdn.discordapp.com/attachments/857944478269702214/967425358578188379/PXL_20220423_140239978.MP.jpg 14:03:01 ^ [image/jpeg] (4.4MiB) 14:03:10 <08W​erner> Mug ready for filling 🙂 14:06:02 #topic late topics 14:06:26 any non regular topic to add for discussion at the end? 14:06:46 this is our regular agenda https://docs.armbian.com/Process_Release-Model/#release-planning 14:06:47 ^ Model - Armbian Documentation 14:06:55 #topic FYI 14:06:58 <08T​onymac32> Mac late check-in 14:07:14 hi, we are still in the boot up stage 14:07:37 werner: do we have translateor in action? in case someone needs it 14:07:41 as late topic: maybe how to handle bug tracking forums. Either switch or leave it as it is 14:07:49 translation should work? 14:07:50 ..donde esta mi pantalones 14:07:58 note #1: IRC translator: 14:08:00 --hallo zusammen 14:08:00 Hi, everyone [de~>eng] 14:08:04 use -- 14:08:08 --donde esta mi pantalones 14:08:08 where is my pants [es~>eng] 14:08:08 rule #1: When you get a voice, please be quick and concise (1-2 min) and make it clear when you stop. 14:08:19 rule #2: If meeting is going out of desired agenda, MC will use “STOP STOP STOP”, wait to get attention and then proceed with the meeting agenda. Please stop chatting and listen. 14:08:32 rule #3: Please highlight important information appropriately by putting a keyword in front of your message: #info #action #idea #help check tips below. 14:09:14 #topic development common 14:09:40 here i would only expose few directions 14:09:42 - current kernels to 5.15.y 14:09:42 - edge to 5.17.y / 5.18.y 14:09:42 - u-boot 2022.04 14:10:14 i am only sceptical if we can manage with u-boot 14:10:21 the rest is WIP / done 14:10:29 - armbian-config needs help https://github.com/Miouyouyou/python-tests 14:10:30 ^ GitHub - Miouyouyou/python-tests: Random python tests for the moment 14:10:58 we are moving, but too slow. here some additional best effort is needed or we will run into serious troubles 14:11:16 success - mandatory review on merge request. How to implement / improve emergency merge? How are we satisifed otherwise? 14:11:40 speak up how you are seeing this and how to solve emergency situations best? 14:12:33 how's armbian-next cutover play into this 14:12:39 I think there is not much to worry about emergency merge. From what I've seen in the past days always somebody is there that can approve 14:12:55 enforcing review is great improvement in general 14:13:10 sure it slows down but increases quality 14:13:19 amrbian-next cutover - we are getting there in a separate section / build system enhancement 14:13:37 in general it should follow the same procedure - review 14:13:42 gotcha 14:13:46 just perhaps not just by one person 14:14:45 trying not to be off topic, but biggest test will be seeing maintainers are formerlly testing RC images and communicating results 14:14:47 solution is then perhaps just trying to get even more people into this review process 14:14:52 I've appreciated the improvements made by code review, with no issue on speed. 14:15:26 maybe do a little briefing about github Pr reviewing, what is expected and what is not 14:15:36 yeah we've been doing well with the review process. 14:15:59 it sparked development and raise quality, certainly 14:16:24 #idea do a briefing about how to review a pr, what is expected from reviewer, what is not 14:16:54 emergency will be needed if some bad code is merged that was not well verified. we need to predict such things 14:17:20 currenlty, still several hours can go by 14:17:40 if shtf repository owner can disable enforcement temporary? 14:18:00 nah just escalate review more via irc/discord 14:18:16 yeah "need fingers asap" 14:18:20 must be consistent 14:18:26 i can forced it but i would like that we have some sort of protocol 14:18:49 another thought is that now that we have a maintainer list, we can actually make a tool to autotag folks based on files changed to a degree 14:18:58 lets think about this and move on. its not that critical 14:19:02 sure 14:19:15 #idea tag maintainer on pr for review 14:19:18 If it can be identified, a PR that serves as nothing more than a revert of a given merge seems like a reasonable "please get this in ASAP" structure 14:19:25 more important is that armbian-config gets some attention 14:19:33 <08T​onymac32> Agreed 14:19:56 yeah teh armbian-config effort seems stalled... i got confused about who was working on it 14:20:21 i have some folks i can recruit again, maybe we need to centralize documentation on that project a bit more? 14:20:29 myy started to code this now so we have something to start with 14:20:45 anyway, we need to find a way how to boost it 14:21:18 #help push armbian-config development 14:21:37 ok, lets move to hardware. build system is later 14:21:38 #topic development Allwinner 14:21:49 anyone from this section around? 14:22:09 noticed in forums that some seem to have problems with SPI since switch from 5.10 to 5.15 14:22:14 *sunxi 14:22:18 yes, that got my attention too 14:22:26 is there a fix ? 14:22:35 reverting for now 14:22:45 workaround then ;) 14:22:49 yes ^^ 14:23:12 #info investigate SPI related bugs in Allwinner 5.15 14:23:44 probably u-boot upgrade to 2022.04 is possible. 14:24:04 @martinayotte had time for any investigation? 14:24:57 i guess not many allwinner today 14:24:58 #topic development Amlogic 14:25:19 whats vim4 status? 14:25:28 that's var far i think 14:25:30 very 14:25:35 ok 14:25:51 it's probably possible to generate legacy kernel build 14:26:12 <08T​onymac32> Ugh 14:26:29 but i haven't got into that and second vim4 is still waiting who would have it? 14:27:04 is it rpardini who has vim4? 14:27:11 i have one 14:27:24 i mean two 14:27:59 anyway, for mainline expiriences we are 6-12m away 14:28:08 according to folks from Baylibre 14:28:24 i would focus to existing amlogic stuff now 14:28:28 like HC4 14:28:33 Radxa zero 14:28:44 N2+ 14:29:48 do we have some info on latest status here? @rpardini @tonymac32 14:30:05 yeah just need to embrace vendor kernel as option one for this things sadly 14:30:38 <08T​onymac32> I have to get set back up. The only newer Amlogic I have is the zero and some VIMs. 14:30:58 <08T​onymac32> I need to go through and make sure the older boards haven't suffered from all the "improvements" for the newer stuff 14:32:00 that's the idea of support here, yeah. Things might broke down, but we don't know. On automated testing which would partially answer on some question a bit later. 14:32:04 <08T​onymac32> Can we make it possible to compike extra kernels as "optional" so they show up in the Armbian config? 14:32:16 <08T​onymac32> Compile* 14:32:27 how do you mean? 14:32:55 enable more kernel branches as build targes for some boards I assume? 14:33:07 legacy current edge to say 14:33:12 <08T​onymac32> Right but not tied to images 14:33:22 <08T​onymac32> For example: media kernel 14:33:32 <08T​onymac32> If I want it I can switch to it later 14:33:39 something like the "regular kernel" vs. "real-time kernel"? 14:33:44 aha, got it 14:33:49 <08T​onymac32> Or that. Good example 14:34:14 #action define logic for stock and additional kernels (media, real-time, xxx) 14:34:29 this needs some cavets in armbian-config 14:34:38 <08T​onymac32> I figured 14:34:49 which is currently in some strange stage ... w 14:35:06 old is not updating, new is in too infant stage 14:35:14 ok, lets proceed 14:35:52 # amlogic needs some love for zero, checking vims and we will start vim4 with legacy since this will be the only way for a while 14:35:57 #topic development Marvell 14:36:00 #info Espressobin: Current kernel is 5.15.y, edge is 5.17.y, u-boot is 2022.04 14:36:12 I was working on FIT images for distroboot support, but I broke my micro-USB console port, and can now not test u-boot. 14:36:23 Is there any larger group move to support FIT images or follow distroboot variable names? 14:36:55 we were trying to make something common for armbian, but at the end ... there are several ways 14:37:23 it is important that a person that have this hw, when it reads info at download pages 14:37:45 succeeds in booting things up. and that our regular tools (nand-sata-install) knows how to deal with 14:38:33 Yeah. There's been a note saying u-boot update is mandatory coming from 5.93 for years. I'm trying to keep the old boot script functional while adding the ability to clear out the environment variables and function with distroboot method. 14:38:57 But, like I said, broke the console port, so can no longer develop that. 14:39:21 i can send you one ebin. have a spare one with no use case 14:39:22 Ton 14:39:24 `. 14:39:28 no more from me, and I believe I'm the only maintainer on the only Marvell board. Anything I need to do still to get it back to full supported status? 14:39:43 That's your v5? Okay. 14:39:58 send me PM and we will deal with this outside of this meeting 14:40:03 otherwise - get this https://www.armbian.com/espressobin/ 14:40:04 ^ Espressobin – Armbian 14:40:04 wilco 14:40:27 up to date and we are probably ready to roll. the text if there is something to remove (less is better) 14:40:48 #topic development Rockchip 14:41:13 1st thing here is bumping u-boot 14:41:20 pbp seem to have emmc issues with 5.15 (read on forums) 14:41:28 <08T​onymac32> 32 bit, 64 bit? 14:41:44 64bit first 14:42:09 <08T​onymac32> Rockchip64 eMMC on multiple devices has seen some issues. I haven't been able to debug. 14:42:20 this is u-boot related? 14:42:21 <08T​onymac32> To verify is pbp still on main Armbian kernel? 14:42:27 yes 14:42:47 media is "only" what Oleg took over 14:43:02 firefly/station stuff 14:43:22 which is kind a the same but with a fancy case around 14:43:25 <08T​onymac32> On the boards I've tested I haven't gotten predictable results to be certain where the issue lies, I haven't had much time either 14:43:41 ok. so this remains unknown. 14:43:57 and workaround is 5.10.y kernel 14:44:07 <08T​onymac32> For now yes 14:44:30 what about more modern rockchips 14:44:37 any status on rockpi 3 14:45:05 <08T​onymac32> I don't have any of these 14:46:05 there is a lot of buzz on 3588 but i guess outside this meeting 14:46:21 yeah that's outside.. RK3566/68 is what matters isnce more mainloine support 14:46:24 what about status of media with mainline withint rockhip 14:46:44 this is probably common from 3388 -> 14:46:49 3399 14:47:24 <08T​onymac32> Vpu should be common 3288 and up including 3328, just some features here/there. 14:47:42 <08T​onymac32> I think the kernel driver is more or less there, the userland stuff is trailing a bit 14:48:20 so to speak. 32bit. how is that last paolo merge. did you have chance to check it? 14:48:58 <08T​onymac32> Which was the last one? U-boot one worked like a charm, Bluetooth one as well 14:49:26 he manage to bump uboot to latest 14:49:32 from 2018.x something 14:49:59 ok, lets move on, otherwise it will be tied. 14:50:05 <08T​onymac32> Yes, he forward-ported the UMS mode logic, it works 14:50:19 #info Rockchip 5.15.y bugfixing 14:50:24 great 14:50:29 #topic development others 14:50:41 Raspberry Pi, UEFI arm64 and x86 14:51:06 how much you use them and are we ready to move them to "supported" ? 14:51:48 I'd suggest to not do that. At least not yet 14:52:01 we would need a maintainer anyway 14:52:30 <08T​onymac32> I don't use them, but they boot on Phytium and La Frite, which is impressively different hardware (arm64 UEFI). I'm impressed 14:52:34 and x86 needs to have an installer, otherwise its pretty distant for normal people 14:52:41 that and x64 is not our main focus. also RPi users probably have high expectations since their own OS supports all hw functions while armbian status is unknown 14:53:06 x64 perhaps not, but uefi arm64 should be 14:53:14 agree 14:53:16 and they are identical in term of support 14:53:23 or very close i would say 14:53:25 Hmm, I could try the UEFI on espressobin too. 14:53:32 try 14:54:02 perhaps we could merge those kernels into it 14:54:39 eg, drop special families, where this is not really needed 14:54:57 what about Rpi? 14:55:10 I will try to drop a patch or two into UEFI to improve phytoium BTW 14:55:59 #action check if ebin kernel can be merged into UEFI 14:56:30 actually that would be kinda cool.. 14:56:38 ok, we are late. Rpi would probably need some better attention. 14:57:03 build framework is what we should be focusing more and here its a potential 14:57:41 i recently purchaes pikvm and it would be nice to provide armbian ready image for it ... just an example 14:57:44 #topic buildsystem enhancements 14:57:59 merging armbian-next 14:58:36 richardo posted status report here https://forum.armbian.com/topic/20293-armbian-2205-jade-release-thread/#comment-138519 14:58:38 ^ Armbian 22.05 (Jade) Release Thread - Armbian Project Administration - armbian forum 14:59:06 i am thinking how to deal with this bug chunk of code? 14:59:18 Is it possible to break it down into 3 chunks? First part non-breaking changes, then something in the middle and last things which reqiure a lot of testing and CI adjustements. 14:59:50 and second - would that be possible by the end of 5/2022 15:00:15 What do you think? 15:00:48 Yes. If not possible merge after release 15:01:14 No need to put additional pressure on ourselves if next has flaws 15:01:35 our current system also have quirks 15:01:46 yeah there's just gonna be some grumpy people that complain because of change 15:01:56 we need to decide and focus into that 15:01:56 but really the point is to identify the flaws and fix 15:02:36 really we need to merge next asap if we're gonna use it for this release 15:02:38 regarding build script, this is the only major things + adjusting CI. Which is already not in a very perfect state 15:02:40 like merge this weekend 15:03:03 well, i planned next fastest ;) 15:03:30 <08T​onymac32> Next as soon as we can have a window to test it 15:03:37 richardo is preparing into that time - we do if matured enough 15:03:46 speaking of ricardo 15:03:48 @here hey guys, i am new here. Does anybody know where I can find old Focal/Buster images to download? 15:04:01 archive.armbian.com 15:04:17 damn good day ladies and gentlemen 15:04:18 rpardini: speaking right about armbian-next 15:04:35 "Is it possible to break it down into 3 chunks? First part non-breaking changes, then something in the middle and last things which reqiure a lot of testing and CI adjustements." 15:04:37 I was unaware of this meeting today 15:05:04 i navigated archive.armbian.com yesterday but i couldn't find the images for rk3566 15:05:24 ramses yeah those are CSC or beta things 15:05:36 ramses can talk more later we're actually holding a release meeting at moment in here 15:06:27 IgorPec: that sounds like a big ask :) i'd say he's got 1 branch he's rebasing... and uhhh breaking it out woudlb e rough 15:06:41 plan has kind of been "big bang" for cutting over as far as I remember 15:06:51 sure thanks lanefu! 15:07:07 i know. just thinking what can be done to make less pain for maintainers 15:07:18 ok so in my view there's no middle-road for armbian-next 15:07:20 my only other thought would be we cutover to armbian-next IMMEDIATELY after RC branch is cut 15:07:50 the single most important change is 1-line: `set -e` 15:07:54 i want to release images with it 15:08:00 that in turn caused all the other changes, mostly... 15:08:12 so there's not much point in splitting this. 15:08:16 gotcha 15:08:23 that said... I did mess up the first commit 15:08:39 so as far as being a board maintainer.. patches work the same, etc right? it's just the deep customizations and hooks that are new? 15:08:50 where a bunch of code file splits/copies/renames _and_ changes to their contents were done together 15:09:03 and "how the sausuage is made" more than how a SBC dev interacts with it? 15:09:16 lanefu: end users are last problem here 15:09:24 yes. -next shares 99% of non-"lib/" folder code 15:09:27 IgorPec: explain 15:09:43 there's some source/families changes... but somewhat minor, using functions and helpers and stuff 15:09:47 code maintainers and ci 15:10:27 so patches, packages, desktop stuff, linux config, etc are all portable across master and -next 15:10:36 users has no pain if image is produced with one system or another 15:10:50 IgorPec: well from my perspective... if their workflow is the same.. that makes it easier to cutover... then only the core dev team has to roll with the punches of the change 15:11:23 lanefu: your perspective is users right now. and we don't worry about them yet 15:11:25 ex: if moving to armbian-next doesn't totally mess up ManOfTheSea who's a newer maintainer... then we win 15:11:37 thanks 15:12:12 my perspective is maintainer's that we just recruited through a lot of marketing and advocating and winning trust.. dont' want to suddenly create a world of frustration 15:12:25 and send us in a backwards direction 15:12:50 so i care deeply about that part of the transition.. the hardcore devs liek balbes and the-going i dont care about cuz they dig deep 15:12:52 yes. as you could see from the-Going right now armbian-next might create frustration due to huge size of git bundles downloaded 15:14:05 lanefu: when code is going to change, we are certainly ask developers and maintainers. not just users 15:14:09 but awesome ppl like ManoftheSea can _try_ armbian-next and decide for themselves... it should not be too bad 15:14:53 right now _users_ would be very frustrated, since I've not EXTRAWIFI working. that is in the works 15:14:53 I don't think im making my point 15:15:02 define: user i guess 15:15:07 this discussion takes up quite some time. I suggest either come to conclusion if merge before or after release or shift the entire discussion outside of meeting 15:16:04 changing a lot of code is stressfull for some people and i am protecting that interest here 15:16:05 anyway ManOfTheSea is our benchmark on whether not armbian-next is a graceful transition.. no pressure ManOfTheSea 15:16:23 My opinion: armbian-next is not going away if not merged. I will keep it rebased. It should help/better life for maintainers _and_ users. 15:16:27 haha, wow. 15:17:04 TL,DR: I'd rather armbian-next merge is delayed as much as needed but most people are at least OK with it _before_ the merge 15:17:07 I'll try to find time to look and report how it affects me as a new maintainer. Hopefully, my report is "I changed nothing and it worked" 15:17:32 #topic buildsystem desktop 15:17:55 we have some imrovements here too 15:18:02 several bugfix improvemets by RichN, Queen Fiona made nice i3 variant which is still in the works 15:18:20 other thing was cleaning and making Debian builds operational 15:18:40 #topic Infrastructure 15:18:46 - linking all IRC channels with Discord 15:18:53 #info linking all IRC channels with Discord 15:19:01 #info trying to get verified status for Discord and Twitter (failed both) 15:19:12 all channels tarting with #armbian are linked already 15:19:25 #info automated testings - We are working on enabling Lava test framework within hardware lab. 15:19:37 2nd verification attempt for discord is in review 15:19:45 here i would add that this will only cover hardware functions 15:20:04 aha. so chipset channels?= 15:20:36 this is implementing Lava framework to our hardware 15:20:50 this is done with cooperation with Baylibrew 15:21:01 WHOA i was gonna aks who is helping iwth Lava.. it seems like a blackbox 15:21:11 so thats awesome 15:21:23 currently we are just talking, checking if possible 15:21:29 gotcha 15:21:49 yeah i'll remain cautiously optimistic on LAVA 15:21:53 CI or better unit testing on build framework is TBD 15:21:56 chipset channels seems sane 15:22:09 to add 15:22:18 aight, will do that 15:22:39 LAVA is huge and complicated tool, but its at least on some level. early ideas was to implements something like that if someone would be abel to deal with 15:22:55 now this might be possible. which is better then my dirty bash scripting 15:23:11 anyway, this is an update whats going on. 15:23:26 # general infra - mainly we are working on redirector. New people on board: ccats, Giddy, 3to8-decoder 15:23:33 here lanefu might add more 15:23:40 (add #info or #topic) 15:24:20 I have open an EPIC on the topic of infra improvements https://armbian.atlassian.net/browse/AR-970 15:24:22 ^ [AR-970] - Jira 15:24:23 4AR-970 6[Epic] "Infrastructure development and maintenance" reported by 3Igor Pecovnik at 2021-11-10. Status: In Progress 15:24:36 #info new redirector is reliable.. working with ccats and team to an automated deployment process. redirector currently running on a temporary node.. will move to multiple hosts in a HA-like configuration 15:25:28 #action further integrate redirector with the mirror git repository for maintaining source of truth [currently in progress] 15:25:45 oh damn it 15:25:48 you gotta type it for me igor 15:25:57 i dont think i'm bot blessed 15:26:00 is syncing already mentioned? 15:26:00 #info new redirector is reliable.. working with ccats and team to an automated deployment process. redirector currently running on a temporary node.. will move to multiple hosts in a HA-like configuration 15:26:08 #action further integrate redirector with the mirror git repository for maintaining source of truth [currently in progress] 15:26:14 automatically throw out mirros out of sync 15:26:31 this part needs to be automatised in some way. 15:27:00 anyway, i would propose to add ideas to that EPIC 15:27:07 to me we still have too many mirrors in redireector and that makes it worse 15:27:11 god point 15:27:33 dividing 1st class (our control) 2nd class mirrors like you proposed might work 15:27:39 #idea figure out how to get feedback from mirrors if sync or out of sync 15:28:11 the tool could still provide the list of the 2ndary mirrors for armbian-config users, just not be part of rotation 15:28:11 so 1st day of release we are running on low capacity ... and gradually adding mirrors 15:29:17 frankly our primary mirrors can easily handle all the load... 15:29:32 then enable secondary 2 days later and voila 15:29:35 yeah 15:29:36 Ok sorry but quick flashback to amlogic / meson64 from my side: I've done no real work on meson64 since last meeting. Still consider 5.10 stable, and everything else very experimental. I've seen other people sending patches to half-fix 5.15, but that was lost since 5.17 was merged on top. I did not test 5.17 yet. Reports from HomeAssistant declare 5.15+ unstable on N2+, even with fixes. Sincerely apologize for lack of involvement, but that is due to 15:29:37 5.10.y being rock solid ;-) 15:30:24 yeah i still want to have LTS kernels avaiable longer.. but thats for another topic.. kind of aligns iwth tony's thing from earlier about current or media kernel being an easier user choice 15:30:53 ok, leaving meson64 as is 15:31:12 infra, anything else (forum is separate= 15:31:29 #topic Infrastructure - planned/unplanned changes on forums 15:31:44 #info tags were added and enabled to one group i believe @werner 15:32:11 unsure TBH since the meetbot is mostly bound to the chair but we'll see if others work too after meeting ends lol 15:32:39 i mean forum tags 15:33:05 aha yes. every supported board got a proper tag 15:33:18 tags are enforced in bug tracker forums and p2p 15:33:20 how is this define, is it promoted in some way? 15:33:49 so we have forums defined, but not enabled for all forums and all users? 15:34:21 tags defined 15:34:25 all users can use these tags in the mentioned forums 15:34:34 or have to use them 15:34:44 ok, lets discuss that major forum changes 15:34:58 #action handle bug tracking forum 15:35:11 what are your ideas here, what do you propose? 15:35:37 new bug tracking forums are prepared. contributors or anyone with more provileges (moderators and so ) can see those at the very bottom. 15:36:02 yes, just the general idea - is it good? 15:36:07 some families are merged, some are dropped. forums are limited to supported boards by enforcing predefined tags 15:36:22 i am more concerned on top level design, not on that section 15:36:39 what exactly you mean? 15:36:57 refactoring forums completly into tree main sections, first should have more recent things like new hardware introduction. HW designers now make a lot of noise a lot before hw becomes interesting. 15:36:57 6-12months or more, before we can put some serious Linux on it. First section of forums should be more toward user oriented. Like easy chatting, wondering how this new devices will be working for something .. 15:36:57 then second and third forum section just divide into "Current/actuall/supported hardware" "Legacy below (all 32bit hw + some older 64b ATM) 15:37:53 like now we have Allwinner A20 in the prime section ... 15:38:15 while it should be somewhere at the bottom. Similar to Pine and Hardkernel forums 15:38:23 moving older stuff down 15:38:36 shifting stuff around is no big deal 15:38:46 i know, but it is important 15:39:14 also shrinking is possible by for example merging allwinner families 15:39:16 so i would like we discuss what would be best to set that up. once set, we are not going to move it around for awhile 15:39:28 that too, but this is user interaction 15:39:37 he has to find that button and press. 15:40:15 to find the correct forums all supported boards (with link to tag behind) Have been added to the preview 15:40:16 forum defaults are our job 15:41:20 ok, lets do this outside the meeting 15:41:37 ok 15:41:49 #action redefine top level forum design and rething its defaults 15:41:59 #topic Jira Backlog 15:42:15 here i will only invite all of us to take some time here https://armbian.atlassian.net/jira/dashboards/10000 15:42:16 ^ Dashboard - Jira 15:42:43 #action Bugs / tasks that are resolved change field "Fix versions" to "22.05". 15:43:00 #action Claim authorship for tasks 15:43:44 #action open bugs and tasks that might need to be solved in 22.05 15:43:52 #topic board support status updates 15:44:03 any updates here? 15:44:27 can rock-3a be treated as supported? 15:45:12 I think we discussed already, but Espressobin as supported 15:45:17 do we have a named maintainer for rock-3a? if so yes 15:45:53 yes, we have for both 15:46:01 then yes 15:46:02 #action declare rock-3a and ebin as supported 15:46:03 :) 15:46:09 #topic release officer and meeting organizer and goverance 15:46:29 anyone 15:47:28 ok, will decide that later (again) 15:47:33 #topic misc / open discussion 15:47:33 :) 15:48:21 speak up or this is it 15:48:28 nak 15:48:35 lanefu: I am working on LAVA if you need more info, I need to show an armbian POC to IgorPec 15:49:29 montjoie: sure would love more info.... mostly interested in it from a process/workflow level 15:49:40 montjoie: we can keep have some forum topic on that 15:50:08 IgorPec: I will give you a meeting date soon, holidays end here, so no more child risk 15:50:25 yes, we'll catch up! 15:50:32 #endmeeting Jade