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