Werner changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum/Twitter feed: #armbian-rss | Logs: -> irc.armbian.com
califax has quit [Remote host closed the connection]
califax has joined #armbian
archetech has quit [Quit: Leaving]
archetech has joined #armbian
califax has quit [Remote host closed the connection]
ArmbianHelper changed the topic of #armbian to: FYI (Meeting topic: Jade)
<IgorPec>
#topic FYI
<Armbian-Discord>
<Tonymac32> Mac late check-in
<IgorPec>
hi, we are still in the boot up stage
<IgorPec>
werner: do we have translateor in action? in case someone needs it
<Werner>
as late topic: maybe how to handle bug tracking forums. Either switch or leave it as it is
<Werner>
translation should work?
<lanefu>
..donde esta mi pantalones
<IgorPec>
note #1: IRC translator:
<Werner>
--hallo zusammen
<ArmbianHelper>
Hi, everyone [de~>eng]
<Werner>
use --
<lanefu>
--donde esta mi pantalones
<IgorPec>
rule #1: When you get a voice, please be quick and concise (1-2 min) and make it clear when you stop.
<ArmbianHelper>
where is my pants [es~>eng]
<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.
<IgorPec>
rule #3: Please highlight important information appropriately by putting a keyword in front of your message: #info #action #idea #help check tips below.
<IgorPec>
#topic development common
ArmbianHelper changed the topic of #armbian to: development common (Meeting topic: Jade)
<IgorPec>
here i would only expose few directions
<IgorPec>
- current kernels to 5.15.y
<IgorPec>
- edge to 5.17.y / 5.18.y
<IgorPec>
- u-boot 2022.04
<IgorPec>
i am only sceptical if we can manage with u-boot
<ArmbianHelper>
^ GitHub - Miouyouyou/python-tests: Random python tests for the moment
<IgorPec>
we are moving, but too slow. here some additional best effort is needed or we will run into serious troubles
<IgorPec>
success - mandatory review on merge request. How to implement / improve emergency merge? How are we satisifed otherwise?
<IgorPec>
speak up how you are seeing this and how to solve emergency situations best?
<lanefu>
how's armbian-next cutover play into this
<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
<Werner>
enforcing review is great improvement in general
<Werner>
sure it slows down but increases quality
<IgorPec>
amrbian-next cutover - we are getting there in a separate section / build system enhancement
<IgorPec>
in general it should follow the same procedure - review
<lanefu>
gotcha
<IgorPec>
just perhaps not just by one person
<lanefu>
trying not to be off topic, but biggest test will be seeing maintainers are formerlly testing RC images and communicating results
<IgorPec>
solution is then perhaps just trying to get even more people into this review process
<Armbian-Discord>
<ManoftheSea> I've appreciated the improvements made by code review, with no issue on speed.
<Werner>
maybe do a little briefing about github Pr reviewing, what is expected and what is not
<lanefu>
yeah we've been doing well with the review process.
<IgorPec>
it sparked development and raise quality, certainly
<Werner>
#idea do a briefing about how to review a pr, what is expected from reviewer, what is not
<IgorPec>
emergency will be needed if some bad code is merged that was not well verified. we need to predict such things
<IgorPec>
currenlty, still several hours can go by
<Werner>
if shtf repository owner can disable enforcement temporary?
<lanefu>
nah just escalate review more via irc/discord
<Werner>
yeah "need fingers asap"
<lanefu>
must be consistent
<IgorPec>
i can forced it but i would like that we have some sort of protocol
<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
<IgorPec>
lets think about this and move on. its not that critical
<lanefu>
sure
<Werner>
#idea tag maintainer on pr for review
<Armbian-Discord>
<ManoftheSea> 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
<IgorPec>
more important is that armbian-config gets some attention
<Armbian-Discord>
<Tonymac32> Agreed
<lanefu>
yeah teh armbian-config effort seems stalled... i got confused about who was working on it
<lanefu>
i have some folks i can recruit again, maybe we need to centralize documentation on that project a bit more?
<IgorPec>
myy started to code this now so we have something to start with
<IgorPec>
anyway, we need to find a way how to boost it
<IgorPec>
#help push armbian-config development
<IgorPec>
ok, lets move to hardware. build system is later
<IgorPec>
#topic development Allwinner
ArmbianHelper changed the topic of #armbian to: development Allwinner (Meeting topic: Jade)
<IgorPec>
anyone from this section around?
<Werner>
noticed in forums that some seem to have problems with SPI since switch from 5.10 to 5.15
<Werner>
*sunxi
<IgorPec>
yes, that got my attention too
<IgorPec>
is there a fix ?
<Werner>
reverting for now
<IgorPec>
workaround then ;)
<Werner>
yes ^^
<IgorPec>
#info investigate SPI related bugs in Allwinner 5.15
<IgorPec>
probably u-boot upgrade to 2022.04 is possible.
<IgorPec>
@martinayotte had time for any investigation?
<IgorPec>
i guess not many allwinner today
<IgorPec>
#topic development Amlogic
ArmbianHelper changed the topic of #armbian to: development Amlogic (Meeting topic: Jade)
<Werner>
whats vim4 status?
<IgorPec>
that's var far i think
<IgorPec>
very
<Werner>
ok
<IgorPec>
it's probably possible to generate legacy kernel build
<Armbian-Discord>
<Tonymac32> Ugh
<IgorPec>
but i haven't got into that and second vim4 is still waiting who would have it?
<lanefu>
is it rpardini who has vim4?
<IgorPec>
i have one
<IgorPec>
i mean two
<IgorPec>
anyway, for mainline expiriences we are 6-12m away
<IgorPec>
according to folks from Baylibre
<IgorPec>
i would focus to existing amlogic stuff now
<IgorPec>
like HC4
<IgorPec>
Radxa zero
<IgorPec>
N2+
<IgorPec>
do we have some info on latest status here? @rpardini @tonymac32
<lanefu>
yeah just need to embrace vendor kernel as option one for this things sadly
<Armbian-Discord>
<Tonymac32> I have to get set back up. The only newer Amlogic I have is the zero and some VIMs.
<Armbian-Discord>
<Tonymac32> I need to go through and make sure the older boards haven't suffered from all the "improvements" for the newer stuff
<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.
<Armbian-Discord>
<Tonymac32> Can we make it possible to compike extra kernels as "optional" so they show up in the Armbian config?
<Armbian-Discord>
<Tonymac32> Compile*
<IgorPec>
how do you mean?
<Werner>
enable more kernel branches as build targes for some boards I assume?
<Werner>
legacy current edge to say
<Armbian-Discord>
<Tonymac32> Right but not tied to images
<Armbian-Discord>
<Tonymac32> For example: media kernel
<Armbian-Discord>
<Tonymac32> If I want it I can switch to it later
<Armbian-Discord>
<ManoftheSea> something like the "regular kernel" vs. "real-time kernel"?
<IgorPec>
aha, got it
<Armbian-Discord>
<Tonymac32> Or that. Good example
<IgorPec>
#action define logic for stock and additional kernels (media, real-time, xxx)
<IgorPec>
this needs some cavets in armbian-config
<Armbian-Discord>
<Tonymac32> I figured
<IgorPec>
which is currently in some strange stage ... w
<IgorPec>
old is not updating, new is in too infant stage
<IgorPec>
ok, lets proceed
<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
<IgorPec>
#topic development Marvell
ArmbianHelper changed the topic of #armbian to: development Marvell (Meeting topic: Jade)
<Armbian-Discord>
<ManoftheSea> #info Espressobin: Current kernel is 5.15.y, edge is 5.17.y, u-boot is 2022.04
<Armbian-Discord>
<ManoftheSea> I was working on FIT images for distroboot support, but I broke my micro-USB console port, and can now not test u-boot.
<Armbian-Discord>
<ManoftheSea> Is there any larger group move to support FIT images or follow distroboot variable names?
<IgorPec>
we were trying to make something common for armbian, but at the end ... there are several ways
<IgorPec>
it is important that a person that have this hw, when it reads info at download pages
<IgorPec>
succeeds in booting things up. and that our regular tools (nand-sata-install) knows how to deal with
<Armbian-Discord>
<ManoftheSea> 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.
<Armbian-Discord>
<ManoftheSea> But, like I said, broke the console port, so can no longer develop that.
<IgorPec>
i can send you one ebin. have a spare one with no use case
<lanefu>
Ton
<lanefu>
`.
<Armbian-Discord>
<ManoftheSea> 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?
<Armbian-Discord>
<ManoftheSea> That's your v5? Okay.
<IgorPec>
send me PM and we will deal with this outside of this meeting
<IgorPec>
up to date and we are probably ready to roll. the text if there is something to remove (less is better)
<IgorPec>
#topic development Rockchip
ArmbianHelper changed the topic of #armbian to: development Rockchip (Meeting topic: Jade)
<IgorPec>
1st thing here is bumping u-boot
<Werner>
pbp seem to have emmc issues with 5.15 (read on forums)
<Armbian-Discord>
<Tonymac32> 32 bit, 64 bit?
<IgorPec>
64bit first
<Armbian-Discord>
<Tonymac32> Rockchip64 eMMC on multiple devices has seen some issues. I haven't been able to debug.
<IgorPec>
this is u-boot related?
<Armbian-Discord>
<Tonymac32> To verify is pbp still on main Armbian kernel?
<IgorPec>
yes
<IgorPec>
media is "only" what Oleg took over
<Werner>
firefly/station stuff
<Werner>
which is kind a the same but with a fancy case around
<Armbian-Discord>
<Tonymac32> 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
<IgorPec>
ok. so this remains unknown.
<IgorPec>
and workaround is 5.10.y kernel
<Armbian-Discord>
<Tonymac32> For now yes
<IgorPec>
what about more modern rockchips
<IgorPec>
any status on rockpi 3
<Armbian-Discord>
<Tonymac32> I don't have any of these
<IgorPec>
there is a lot of buzz on 3588 but i guess outside this meeting
<lanefu>
yeah that's outside.. RK3566/68 is what matters isnce more mainloine support
<IgorPec>
what about status of media with mainline withint rockhip
<IgorPec>
this is probably common from 3388 ->
<IgorPec>
3399
<Armbian-Discord>
<Tonymac32> Vpu should be common 3288 and up including 3328, just some features here/there.
<Armbian-Discord>
<Tonymac32> I think the kernel driver is more or less there, the userland stuff is trailing a bit
<IgorPec>
so to speak. 32bit. how is that last paolo merge. did you have chance to check it?
<Armbian-Discord>
<Tonymac32> Which was the last one? U-boot one worked like a charm, Bluetooth one as well
<IgorPec>
he manage to bump uboot to latest
<IgorPec>
from 2018.x something
<IgorPec>
ok, lets move on, otherwise it will be tied.
<Armbian-Discord>
<Tonymac32> Yes, he forward-ported the UMS mode logic, it works
<IgorPec>
#info Rockchip 5.15.y bugfixing
<IgorPec>
great
<IgorPec>
#topic development others
ArmbianHelper changed the topic of #armbian to: development others (Meeting topic: Jade)
<IgorPec>
Raspberry Pi, UEFI arm64 and x86
<IgorPec>
how much you use them and are we ready to move them to "supported" ?
<Werner>
I'd suggest to not do that. At least not yet
<IgorPec>
we would need a maintainer anyway
<Armbian-Discord>
<Tonymac32> I don't use them, but they boot on Phytium and La Frite, which is impressively different hardware (arm64 UEFI). I'm impressed
<IgorPec>
and x86 needs to have an installer, otherwise its pretty distant for normal people
<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
<IgorPec>
x64 perhaps not, but uefi arm64 should be
<Werner>
agree
<IgorPec>
and they are identical in term of support
<IgorPec>
or very close i would say
<Armbian-Discord>
<ManoftheSea> Hmm, I could try the UEFI on espressobin too.
<IgorPec>
try
<IgorPec>
perhaps we could merge those kernels into it
<IgorPec>
eg, drop special families, where this is not really needed
<IgorPec>
what about Rpi?
<lanefu>
I will try to drop a patch or two into UEFI to improve phytoium BTW
vpeter has quit [Remote host closed the connection]
<IgorPec>
#action check if ebin kernel can be merged into UEFI
vpeter has joined #armbian
<lanefu>
actually that would be kinda cool..
<IgorPec>
ok, we are late. Rpi would probably need some better attention.
<IgorPec>
build framework is what we should be focusing more and here its a potential
joshaspinall has joined #armbian
<IgorPec>
i recently purchaes pikvm and it would be nice to provide armbian ready image for it ... just an example
<IgorPec>
#topic buildsystem enhancements
ArmbianHelper changed the topic of #armbian to: buildsystem enhancements (Meeting topic: Jade)
<IgorPec>
i am thinking how to deal with this bug chunk of code?
<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.
<IgorPec>
and second - would that be possible by the end of 5/2022
<IgorPec>
What do you think?
<Werner>
Yes. If not possible merge after release
<Werner>
No need to put additional pressure on ourselves if next has flaws
<IgorPec>
our current system also have quirks
<lanefu>
yeah there's just gonna be some grumpy people that complain because of change
<IgorPec>
we need to decide and focus into that
<lanefu>
but really the point is to identify the flaws and fix
<lanefu>
really we need to merge next asap if we're gonna use it for this release
<IgorPec>
regarding build script, this is the only major things + adjusting CI. Which is already not in a very perfect state
<lanefu>
like merge this weekend
<IgorPec>
well, i planned next fastest ;)
<Armbian-Discord>
<Tonymac32> Next as soon as we can have a window to test it
<IgorPec>
richardo is preparing into that time - we do if matured enough
rpardini has joined #armbian
<lanefu>
speaking of ricardo
<Armbian-Discord>
<ramses> @here hey guys, i am new here. Does anybody know where I can find old Focal/Buster images to download?
<lanefu>
archive.armbian.com
<rpardini>
damn good day ladies and gentlemen
<IgorPec>
rpardini: speaking right about armbian-next
<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."
<rpardini>
I was unaware of this meeting today
<Armbian-Discord>
<ramses> i navigated archive.armbian.com yesterday but i couldn't find the images for rk3566
<lanefu>
ramses yeah those are CSC or beta things
<lanefu>
ramses can talk more later we're actually holding a release meeting at moment in here
<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
<lanefu>
plan has kind of been "big bang" for cutting over as far as I remember
<Armbian-Discord>
<ramses> sure thanks lanefu!
<IgorPec>
i know. just thinking what can be done to make less pain for maintainers
<rpardini>
ok so in my view there's no middle-road for armbian-next
<lanefu>
my only other thought would be we cutover to armbian-next IMMEDIATELY after RC branch is cut
<rpardini>
the single most important change is 1-line: `set -e`
<IgorPec>
i want to release images with it
<rpardini>
that in turn caused all the other changes, mostly...
<rpardini>
so there's not much point in splitting this.
<lanefu>
gotcha
<rpardini>
that said... I did mess up the first commit
<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?
<rpardini>
where a bunch of code file splits/copies/renames _and_ changes to their contents were done together
<lanefu>
and "how the sausuage is made" more than how a SBC dev interacts with it?
<IgorPec>
lanefu: end users are last problem here
<rpardini>
yes. -next shares 99% of non-"lib/" folder code
<lanefu>
IgorPec: explain
<rpardini>
there's some source/families changes... but somewhat minor, using functions and helpers and stuff
<IgorPec>
code maintainers and ci
<rpardini>
so patches, packages, desktop stuff, linux config, etc are all portable across master and -next
<IgorPec>
users has no pain if image is produced with one system or another
<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
<IgorPec>
lanefu: your perspective is users right now. and we don't worry about them yet
<lanefu>
ex: if moving to armbian-next doesn't totally mess up ManOfTheSea who's a newer maintainer... then we win
<Armbian-Discord>
<ManoftheSea> thanks
<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
<lanefu>
and send us in a backwards direction
<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
<rpardini>
yes. as you could see from the-Going right now armbian-next might create frustration due to huge size of git bundles downloaded
<IgorPec>
lanefu: when code is going to change, we are certainly ask developers and maintainers. not just users
<rpardini>
but awesome ppl like ManoftheSea can _try_ armbian-next and decide for themselves... it should not be too bad
<rpardini>
right now _users_ would be very frustrated, since I've not EXTRAWIFI working. that is in the works
<lanefu>
I don't think im making my point
<lanefu>
define: user i guess
<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
<IgorPec>
changing a lot of code is stressfull for some people and i am protecting that interest here
<lanefu>
anyway ManOfTheSea is our benchmark on whether not armbian-next is a graceful transition.. no pressure ManOfTheSea
<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.
<Armbian-Discord>
<ManoftheSea> haha, wow.
<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
<Armbian-Discord>
<ManoftheSea> 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"
<IgorPec>
#topic buildsystem desktop
ArmbianHelper changed the topic of #armbian to: buildsystem desktop (Meeting topic: Jade)
<IgorPec>
we have some imrovements here too
<IgorPec>
several bugfix improvemets by RichN, Queen Fiona made nice i3 variant which is still in the works
<IgorPec>
other thing was cleaning and making Debian builds operational
<IgorPec>
#topic Infrastructure
ArmbianHelper changed the topic of #armbian to: Infrastructure (Meeting topic: Jade)
<IgorPec>
- linking all IRC channels with Discord
<IgorPec>
#info linking all IRC channels with Discord
<IgorPec>
#info trying to get verified status for Discord and Twitter (failed both)
<Werner>
all channels tarting with #armbian are linked already
<IgorPec>
#info automated testings - We are working on enabling Lava test framework within hardware lab.
<Werner>
2nd verification attempt for discord is in review
<IgorPec>
here i would add that this will only cover hardware functions
<Werner>
aha. so chipset channels?=
<IgorPec>
this is implementing Lava framework to our hardware
<IgorPec>
this is done with cooperation with Baylibrew
<lanefu>
WHOA i was gonna aks who is helping iwth Lava.. it seems like a blackbox
<lanefu>
so thats awesome
<IgorPec>
currently we are just talking, checking if possible
<lanefu>
gotcha
<lanefu>
yeah i'll remain cautiously optimistic on LAVA
<IgorPec>
CI or better unit testing on build framework is TBD
<lanefu>
chipset channels seems sane
<lanefu>
to add
<Werner>
aight, will do that
<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
<IgorPec>
now this might be possible. which is better then my dirty bash scripting
<IgorPec>
anyway, this is an update whats going on.
<IgorPec>
# general infra - mainly we are working on redirector. New people on board: ccats, Giddy, 3to8-decoder
<ArmbianHelper>
AR-970 [Epic] "Infrastructure development and maintenance" reported by Igor Pecovnik at 2021-11-10. Status: In Progress
<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
<lanefu>
#action further integrate redirector with the mirror git repository for maintaining source of truth [currently in progress]
<lanefu>
oh damn it
<lanefu>
you gotta type it for me igor
<lanefu>
i dont think i'm bot blessed
<Werner>
is syncing already mentioned?
<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
<IgorPec>
#action further integrate redirector with the mirror git repository for maintaining source of truth [currently in progress]
<Werner>
automatically throw out mirros out of sync
<IgorPec>
this part needs to be automatised in some way.
<IgorPec>
anyway, i would propose to add ideas to that EPIC
<lanefu>
to me we still have too many mirrors in redireector and that makes it worse
<lanefu>
god point
<IgorPec>
dividing 1st class (our control) 2nd class mirrors like you proposed might work
<Werner>
#idea figure out how to get feedback from mirrors if sync or out of sync
<lanefu>
the tool could still provide the list of the 2ndary mirrors for armbian-config users, just not be part of rotation
<IgorPec>
so 1st day of release we are running on low capacity ... and gradually adding mirrors
<lanefu>
frankly our primary mirrors can easily handle all the load...
<IgorPec>
then enable secondary 2 days later and voila
<lanefu>
yeah
<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
<rpardini>
5.10.y being rock solid ;-)
<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
<IgorPec>
ok, leaving meson64 as is
<IgorPec>
infra, anything else (forum is separate=
<IgorPec>
#topic Infrastructure - planned/unplanned changes on forums
ArmbianHelper changed the topic of #armbian to: Infrastructure - planned/unplanned changes on forums (Meeting topic: Jade)
<IgorPec>
#info tags were added and enabled to one group i believe @werner
<Werner>
unsure TBH since the meetbot is mostly bound to the chair but we'll see if others work too after meeting ends lol
<IgorPec>
i mean forum tags
<Werner>
aha yes. every supported board got a proper tag
<Werner>
tags are enforced in bug tracker forums and p2p
<IgorPec>
how is this define, is it promoted in some way?
<IgorPec>
so we have forums defined, but not enabled for all forums and all users?
<IgorPec>
tags defined
<Werner>
all users can use these tags in the mentioned forums
<Werner>
or have to use them
<IgorPec>
ok, lets discuss that major forum changes
<IgorPec>
#action handle bug tracking forum
<IgorPec>
what are your ideas here, what do you propose?
<Werner>
new bug tracking forums are prepared. contributors or anyone with more provileges (moderators and so ) can see those at the very bottom.
<IgorPec>
yes, just the general idea - is it good?
<Werner>
some families are merged, some are dropped. forums are limited to supported boards by enforcing predefined tags
<IgorPec>
i am more concerned on top level design, not on that section
<Werner>
what exactly you mean?
<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.
<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 ..
<IgorPec>
then second and third forum section just divide into "Current/actuall/supported hardware" "Legacy below (all 32bit hw + some older 64b ATM)
<IgorPec>
like now we have Allwinner A20 in the prime section ...
<IgorPec>
while it should be somewhere at the bottom. Similar to Pine and Hardkernel forums
<IgorPec>
moving older stuff down
<Werner>
shifting stuff around is no big deal
<IgorPec>
i know, but it is important
<Werner>
also shrinking is possible by for example merging allwinner families
<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
<IgorPec>
that too, but this is user interaction
<IgorPec>
he has to find that button and press.
<Werner>
to find the correct forums all supported boards (with link to tag behind) Have been added to the preview
<IgorPec>
forum defaults are our job
<IgorPec>
ok, lets do this outside the meeting
<Werner>
ok
<IgorPec>
#action redefine top level forum design and rething its defaults
<IgorPec>
#topic Jira Backlog
ArmbianHelper changed the topic of #armbian to: Jira Backlog (Meeting topic: Jade)
<IgorPec>
#action Bugs / tasks that are resolved change field "Fix versions" to "22.05".
<IgorPec>
#action Claim authorship for tasks
<IgorPec>
#action open bugs and tasks that might need to be solved in 22.05
<IgorPec>
#topic board support status updates
ArmbianHelper changed the topic of #armbian to: board support status updates (Meeting topic: Jade)
<IgorPec>
any updates here?
<IgorPec>
can rock-3a be treated as supported?
<Armbian-Discord>
<ManoftheSea> I think we discussed already, but Espressobin as supported
<lanefu>
do we have a named maintainer for rock-3a? if so yes
<IgorPec>
yes, we have for both
<lanefu>
then yes
<IgorPec>
#action declare rock-3a and ebin as supported
<lanefu>
:)
ArmbianHelper changed the topic of #armbian to: release officer and meeting organizer and goverance (Meeting topic: Jade)
<IgorPec>
#topic release officer and meeting organizer and goverance
<IgorPec>
anyone
<IgorPec>
ok, will decide that later (again)
<IgorPec>
#topic misc / open discussion
ArmbianHelper changed the topic of #armbian to: misc / open discussion (Meeting topic: Jade)
<lanefu>
:)
<IgorPec>
speak up or this is it
<Armbian-Discord>
<ManoftheSea> nak
<montjoie>
lanefu: I am working on LAVA if you need more info, I need to show an armbian POC to IgorPec
<lanefu>
montjoie: sure would love more info.... mostly interested in it from a process/workflow level
<IgorPec>
montjoie: we can keep have some forum topic on that
<montjoie>
IgorPec: I will give you a meeting date soon, holidays end here, so no more child risk
<IgorPec>
yes, we'll catch up!
<IgorPec>
#endmeeting Jade
ArmbianHelper changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum/Twitter feed: #armbian-rss | Logs: -> irc.armbian.com
<ArmbianHelper>
Meeting ended Sat Apr 23 15:50:32 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
<Armbian-Discord>
<rpardini> Hey thanks all and sorry for lateness
* lanefu
claps
<IgorPec>
no problem. we manage to understand some problems and what can be done. usually we can't do many things
<Armbian-Discord>
<ManoftheSea> Hmm... I'm not in this log.
<montjoie>
lanefu: what do you means by process/workflow ?
<IgorPec>
due to lack of time and resources
<IgorPec>
ManoftheSea: oh, bug, discord user :(
<lanefu>
montjoie: X event trigger Y hardware, causes Z service to run etc
<Armbian-Discord>
<ManoftheSea> ah, and bridgebot?
<Werner>
yeah stuff from discord comes via bridge
<Armbian-Discord>
<ManoftheSea> ok.
<Werner>
meeting is set to be in irc anyway so #wontfix ;)
<lanefu>
lol yeah.. something must be oldskool
<IgorPec>
ok, we learned something the hard way again ;9
<Werner>
ah something totally forgot. deprecate focal in favor of jammy?
<Werner>
*officially
<IgorPec>
i would wait with that
<IgorPec>
next release perhaps
<Werner>
ok. hirsute as build environment is stil up to date or bump to impish?
<IgorPec>
if you are asking about building images, we can proceed to jammy
<IgorPec>
jammy is build env now
<Werner>
officially supported build environment to say
<Werner>
ok, need to adjust docs then
<IgorPec>
all what is building now is already in jammy for some time. we said to wait until jammy release ... and it was released this week officially
<Werner>
yes
<lanefu>
`NO_HOST_RELEASECHECK=NO` lol
<lanefu>
err ryes whatever
<Werner>
should try dapper drake :P
<IgorPec>
regarding forums
<IgorPec>
example
<IgorPec>
3 sections
<IgorPec>
top level
<montjoie>
lanefu: not sure to understand, but this is the example of armbian test: http://kernel.montjoie.ovh/239879.log this job flash an armbian on a potato reboot and login and do basic tests
<ArmbianHelper>
^ [text/plain] (23.9KiB)
<IgorPec>
1st level for general stuff and upcoming, 2nd level for regular and 3rd for Old / Legacy / Deprecated / CSC
<IgorPec>
this means proposed new design of bug reporting - We move "Marvell mvebu complete, Allwinner Bananapi ,,.... to 3rd level
<IgorPec>
UX perspective has to be clear. Our of 3 sections they should understand right away where their right topic is - is that possible to achieve?*
<Werner>
Should be. I have all forum names in a doc atm and shifting them around
<ArmbianHelper>
^ Error retrieving title. Check the log for more details.
<Werner>
tags is an issue by itself. in theory each board that get in touch with armbian needs a tag since having open tags create uncontrolled growth which was kind of painful to cleanup
<IgorPec>
we have a closed tag system, right?
<Werner>
yes since recently
<joshaspinall>
hello all, I'm new here, just followed through the meeting. I am wondering approximately the time requirement needed to support an unmaintained board needing a maintainer? Specifically I am looking at the Pine A64/SOPine. Happy to apply via the website, discuss offline; thanks!
<IgorPec>
ok, than this would be possible? just thinking
<Werner>
yes. needs continuing maintenance but other ways to as well so...
<IgorPec>
joshaspinall: ping @yang regarding the access
<IgorPec>
continuous maintanace like adding tags to new topics you mean?
<IgorPec>
older stuff - we expect not many new topics will be open. we could even close down opening topics and allow replying only
<Werner>
that is moderation maintenance. I mean administrating maintenance like adding new forums and shifting others around.
<IgorPec>
ok, what work we are talking about here? per yearly basis
<joshaspinall>
IgorPec: will do, my thanks
<IgorPec>
aha, you mean like we have a Khadas Vim4 comming, lets open a new forum for it?
<Werner>
like so for example, yes. to keep forum up to date with the board "trends"
<Werner>
(if armbian has intention to support it)
<IgorPec>
hmm
<IgorPec>
ok, but now it was the same
<IgorPec>
just its not very much up2date - there are several boards where everything sits in one huge topic
<IgorPec>
namely bring up forums
<Werner>
yeah these hugh topics are a big issue
<Werner>
nobody reads those
<Werner>
I guess having forums PER board has a major advantage here
<Werner>
and for UX it is also better than tags. latter are useful for search and things only
<IgorPec>
well, but again ... if we open a forum for Khadas vim4 and Odroid m1 ... will there be any activity there?
<Werner>
we can collaps to sub-forum if not
<IgorPec>
another idea ... we have a mid section aka "Supported" and aftter id "Deprecated"
<IgorPec>
but we have this entry part the same, just tags
<Werner>
deprecated is basically CSC?
<IgorPec>
yes
<IgorPec>
but i would also like to move lets say Bananapi there
<IgorPec>
if we could find some sane way to organise this
<Werner>
Hm not sure if this creates more confusion since boards mentioned in current/legacy are still supported
<IgorPec>
yes it will create more confusion, so not best way
<IgorPec>
so it has to be stricly three sections "WIP" "Supported" "Community supported"
<IgorPec>
and 4th section for general stuff
<IgorPec>
which somes 1st
<IgorPec>
wanna be / new stuff section is more interesting content then some very specific support status
<Werner>
Hm do we want an entire section for CSC or is a single forums enough?
<IgorPec>
It depends how much of boards we have there
<Werner>
topics with those can still be found if tags are defined for all of them
<IgorPec>
but until we can divide them at any time, this is not a problem
<IgorPec>
tags has to be defined before moving there and we are good to go i guess
<Werner>
yes they have but that is no big deal, just takes time to add them one by one
<Werner>
for now that would be 6 secions. general upcoming current csc community development
<Werner>
I think we can merge our ideas into the same tree in the doc
<IgorPec>
let me edit that docs ...
<Werner>
go ahead. I'll do some food processing in the meantime
<IgorPec>
ok
<Werner>
what do you think about ironsight theme as replacement for the more and more broken haze? https://invisionfocus.de/forums/ at the bottom select IRONSIGHT and try not to think about the background which can be replaced ^^
<ArmbianHelper>
^ Forums - InvisionFocus
<IgorPec>
need to involve some designer to adjust colors at least
<IgorPec>
color consistency adds some credibility
<Werner>
Maybe he's willing to do that for a few bucks. theme itself is free so...
<Werner>
I'll try to get in touch if that would be an option
<IgorPec>
yeah, ask him, we can cover that
<Werner>
message sent
alekksander has quit [Quit: Konversation terminated!]
Armbian-Discord has quit [Remote host closed the connection]
Armbian-Discord has joined #armbian
rpardini has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alekksander has joined #armbian
<Werner>
relay for chipset channels added
<IgorPec>
alright, werner ... how about this direction?
<Werner>
looking into
<IgorPec>
p2p. would it make sense to move it down to CSC ?
<Werner>
in theory yes but experience says need some kind of "collector" present at the top...
<Werner>
we can try though
<IgorPec>
right
<Werner>
if stuff goes to offtopic it is not an issue
<Werner>
s/offtopic/offtopic instead
<ArmbianHelper>
Werner meant to say: if stuff goes to offtopic instead it is not an issue
<IgorPec>
what is the diff between p2p and offtopic
<IgorPec>
from 1st look its the same ;)
<Werner>
xD
<IgorPec>
good ux has no confusions
<Werner>
well in theory offtopic is not board related while p2p is
<ArmbianHelper>
^ Khadas VIM1(Rev 14) Heatsink Fan - Off-topic - armbian forum
<IgorPec>
this clearly has nothing to do with sw support
<IgorPec>
ops, didn't read well, it haws
<IgorPec>
has
<IgorPec>
but its in offtopic. now, even this is outside "support". would it be better to keep in "supported" forums?
<Werner>
depends on how you want to use the support forums. as for my perspective they are only to report bugs in hw functions of specific boards
<IgorPec>
yes. the question is do we want to change the path?
<Werner>
if you collect software related stuff or 3rd party hardware (like heatsinks lol) then actual bugs are less obvious
<Werner>
I dont know tbh. both have advantages and disadvantages
<IgorPec>
but on the end we don't strictly use forum for collecting bugs
<Werner>
it makes sense from UX perspectibve
<Werner>
but it makes harder for us to dig through "unrelated" stuff
<IgorPec>
yeas, i also don't know what is the best, so lets try to figure out before chaning
<Werner>
we need to get a few more people to feedback on this topic
<IgorPec>
well, reality is that bug path has to be different
<IgorPec>
like forum is forum. developers read it and act
<IgorPec>
or not
<IgorPec>
we can't patch all bugs, that is so distant
<Werner>
yeah but we can provide platform to give people a chance to help each other
<IgorPec>
exactly
<IgorPec>
this platform can be improved
<IgorPec>
this p2p / offtopic has to be cut off to "beginners" perhaps?
<IgorPec>
here some manual work has to be done and I expect all moderators to participate in this. this should not be done only by you and me
<Werner>
what you mean cut of to beginners?
<IgorPec>
certain topics
<Werner>
i dont get it
<IgorPec>
we have now two general forums, p2p and off topic
<IgorPec>
probably we could move topics from there to "beginners"
<IgorPec>
or simply move p2p to "Begginers"?:)
<Werner>
ahaa. yes, sure
<Werner>
and move offtopic away so it is clear that this is a non-technical forum
<IgorPec>
but "feature req" are also technical
<Werner>
or maybe shift it all the way at the bottom. like iptables, everything that did not fall into a rule lands there :D
<IgorPec>
mmm, we would like to achieve something else here too - to divert beginners from asking stupid questions
<IgorPec>
in serious technical forums
<IgorPec>
as much as possible
<IgorPec>
this "Using Armbian" could perhaps take care of this to some degree
<Werner>
I guess beginners will catch. If we tell them "you have no idea where to start? go to beginner". I can understand that it is our job also to guide and move stuff from there
<Werner>
yes
<IgorPec>
and improve moderation there
<IgorPec>
like ask for some additional man power
<IgorPec>
or ask actual moderators to focus there most regarding moderation
<Werner>
yes.
<Werner>
do we need subforums for cli and desktops? not sure if that makes sense
<IgorPec>
no, just tags
<Werner>
ah ok
<IgorPec>
tagged below, "begginers is main forum"
<Werner>
what about this advanced users?
<Werner>
we have review forums which are moderation enforced
<IgorPec>
i would change that to normal forums
<IgorPec>
but keep tags
<Werner>
hm
<IgorPec>
and tag those that are still not tagged
<IgorPec>
you want to keep them as is?
<Werner>
Yes. we would have make a line to divide beginner/advanced user topics and what to do with topics that arent either reviews, hacks or tutorials or those who would have low quality?
<Werner>
latter and unrelated are currently filtered by moderation.
<IgorPec>
another idea is to divide users into groups
<Werner>
they are already
<Werner>
auto promotion is active for month in background
<Werner>
to get some numbers on activity and usage for later
<IgorPec>
ok, like disable moderation on those forums but allow write to certain group
<Werner>
I'd keep moderation there regardless. It is not much work and guarantees high quality topics in this section
<IgorPec>
that is correct. even now there are some topics that should be moved out
<Werner>
like everywhere ;)
<IgorPec>
otherwise in general in good shape, yes
<IgorPec>
but this means this forum will be as is, still tags can be enfored in any way
<Werner>
tags are forced there anyways I think but even if they are not neither adding them afterwards or simply adjusting the settings is no big deal
<IgorPec>
No, i mean that we add them to the description
<IgorPec>
now what is topic under "Advanced users"
<IgorPec>
that is not beginners and something from kernel space
<Werner>
so on the bottomline rename the forum to advanced users? since it makes not sense to add a whole categoriy for this to divide beginners from advanced
<Werner>
hm
<Werner>
yes. maybe put project advministration also there?
<IgorPec>
project admin can be anywhere
<IgorPec>
also here, yes
<IgorPec>
ok, i think we got somewhere
<Werner>
whats this news under WIP? kind a like board bring up?