14:01:01 #startmeeting Armbian 21.11 (Sambar) 14:01:01 Meeting started Sat Oct 16 14:01:01 2021 UTC. The chair is Werner. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:01 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:01:11 #topic check-in 14:01:18 Hello. Am here. 14:01:20 me2 14:01:24 I'm where, who to? :) 14:01:31 s/to/too 14:01:31 Werner meant to say: I'm where, who too? :) 14:01:35 Hi 14:01:39 lo 14:01:50 So much fun today :) 14:02:44 Aight enough of the intro. I think late topics can be skipped too 14:02:46 #topic FYI 14:03:18 #info Release may - depending on decision - be shifted/skipped due to latest news and we are late with meeting anyways 14:03:45 yes. alternative is to produce a release, just as minimal as possible 14:04:04 most of linux distros do just that 14:04:20 build, check what was upgreaded and put that into the release files 14:04:48 I would go for skip. Other stuff can be just a dot release of the last one. 14:05:02 If we do full release ppl will expect changes to be in there 14:05:06 I vote skip 14:05:09 I'd go for skip as well. There is no need to put additional pressure on us 14:05:44 Skipping the release is the shot across the bow about our changes 14:06:27 ok. so how to communicate this efficently ? 14:06:40 like to use this as an advantage 14:07:06 #agreed 21.01 released be skipped 14:07:48 Well I think next step is to clean up and add the support plan / document I proposed and place in armbian documentation 14:08:06 Communication is pretty straight forward IMHO. Fixes come via regular update anyways and as further reason point to news 14:08:10 I'd say make announcement (on all channels) in form of: Due to the changes to supported board status we are skipping the 21.11 release. This will give us more time to make sure supported boards run fine and gives you a chance to become a maintainer for "YOUR" board before it gets CSC 14:08:13 ok, so we move the focus to make those changes right 14:08:24 Yeah 14:08:45 #topic board maintainer discussion 14:09:51 we probably need some unified action plan for removal 14:10:03 <- Will maintain mvebu family. Helios4, ClearfogPro/Base. 14:10:10 like asking out for a maintainer, explaining consequences, asking again, remove 14:10:43 There was a sheet somewhere with all boards and their designated maintainers... lanefu? 14:10:53 https://docs.google.com/spreadsheets/d/17O8X5FUxo8_567Xf0_V5ZcWC1IOcg5KSryTzKACegto/edit#gid=0 14:10:55 Yeah 14:11:06 Ah great 14:11:08 This is the list we already got maintainers 14:11:24 I would only ask once. Post announcement, include list, ask ppl to step up otherwise CSC, remove. 14:11:33 So we say what's going away and give people an opportunity to step up and be a maintainer 14:11:34 Asking twice gets us nothing except more work. 14:11:42 asking twice is because people doesn't look and read 14:11:49 IMHO we already asked and that's why we have that list 14:11:59 Yeah but ppl will always only say something once boards are gone. 14:12:07 To there's no reason to ask in advance s second time 14:12:08 #info each and every board needs a dedicated maintainer (person). Otherwise its support status will be changed to CSC 14:12:12 our communication is poor 14:12:24 I agree. 14:12:24 its not enough to write an article or make a twit 14:12:39 Include the info in releases at bootup? 14:12:41 We'd need bigger announcement directly on armbian.com 14:12:44 as well 14:12:49 The small article is not really visible 14:12:50 Doesn't matter reality is the "maintainers" we're involved in the contributor forum 14:12:59 we need to develop communication channel(s) 14:13:07 something like i have proposed in forums 14:13:32 it has to be some dedicated person for that job 14:13:59 Yeah "community organizer" I think is what we are recruiting for 14:14:21 if we don't have it, we should at least have a role which can be rolled to someone that says "i want to help" 14:14:51 More like communication organizer 14:15:02 instead of releasing, i would propose to focus on tasks that will help us 14:15:20 and this role is amoung those that helps us 14:16:31 #action add "community/communication organizer" role for those who want to help 14:18:10 I suggest adding a blog thing to our main website. Things like the recent newsflash get posted there and linked from twitter, forum, whatever. Needs better visibility. Newsflash is easy to overlook. Maybe add button between Download and Forum. 14:19:12 I don't think some kind a blog is necessary or good at all since it would need constant maintenance and filling with content. I think it would be sufficient to have news more visible on website 14:19:13 i am going to get some web / html experts to improve website content / ux wise 14:19:30 AR-909 is a collector of ideas 14:19:30 4AR-909 6[Story] "Website improvements" reported by 3Igor Pecovnik at 2021-09-13. Status: To Do 14:19:45 Yeah I did not mean blog as in "we write there periodically" but this is just not visible at all: https://ibb.co/PDCmxPW 14:20:20 Add a button in the navbar. Call it NEWS if you dont like blog. 14:20:34 Yeah we should make a formal post on forum referencing it and the other (new) documentation. And also on the download pages 14:20:35 well, that's why we need some media department 14:20:39 Haha 14:20:59 what we need is unified way of communicating 14:21:06 and use all available channels 14:21:36 only that provides real effect. mass comm is effective 14:22:02 Yeah. So you want to click button once and publish in many places? 14:22:08 Hi, sorry my user was marked as "away" but I was reading 14:22:33 if possible, but this is not a tecnical problem, more logistical / organisatial 14:22:48 Just one question: would the suppoprted-to-CSC also be possible the other way around if, for example, in the future someone steps in to support a board that has become CSC? 14:22:53 copy / paste from twitter to facebook is not a problem 14:23:21 CSC to supported, yes, why not? 14:23:21 JMCC, of course if somebody steps in as maintainer 14:24:21 Then probably communicating one time, when people complain take opportunity to suggest becoming a maintiner. Sometimes people only react that way 14:24:44 JMCC see https://docs.lane-fu.com/FvYqefTjQGq3TA6EYbz8bQ 14:25:32 also another idea to discuss ... making only one userland official? 14:26:17 I mean, ask for maintainers once, then trhow to when people complain for some board has become CSC, make another round of asking 14:26:21 Yeah I'm with you on that. Like only ship debian as stable 14:26:23 like providing only Ubuntu LTS builds and beta with latest Ubuntu, the rest, DIY 14:26:41 Yeah LTS Ubuntu works too 14:26:41 LOL. you debian, i ubuntu ;)= 14:26:48 I'm fine with whatever 14:26:55 Ubuntu require less fixing 14:27:11 Honestly debian people are more opinionated and can build their own 14:27:12 ok, Lane is with me. What about others? 14:27:37 So yeah I'm with you on headless Ubuntu LTS. Being only "stable" release 14:27:46 so it will only be Armbian OS 14:27:52 I abstain 14:27:54 So no more desktops? 14:28:06 desktop is different story. 14:28:15 We just added them one or two release back and now throw them out? 14:28:20 no, no 14:28:22 Lane said headless only stable 14:28:39 Desktops will be periodic / nightly 14:28:42 No stable 14:28:50 ok fine 14:28:50 See doc 14:29:05 nobody reads that 14:29:08 hehe 14:29:13 It's nicely outlined and heirarchical 14:29:30 I spent like 30 hours writing it 14:29:40 #action only one stable userspace 14:30:14 @lane where do i find it? 14:30:21 Scroll up 14:30:21 https://docs.lane-fu.com/FvYqefTjQGq3TA6EYbz8bQ 14:30:31 Or scroll down lol 14:31:02 even our internal comm needs improvements 14:31:10 ok. lets focus 14:31:13 Yeah. 14:31:21 Yeah sorry but I wont expect docs somewhere on lanes site. 14:31:31 this was not released yet 14:31:45 Ok but where in there is stuff about desktop? Am i blind? 14:31:48 Heisath: yeah it's there as a draft and linked in our contributor forum 14:32:00 ah great. Found it, was just blind 14:32:03 "Armbian will publish and distribute “periodic / nightly” CLI and Desktop images" 14:32:26 now we didn't specify which desktops. for xfce we don't need to explain 14:32:33 xfce stays default desktop 14:32:52 for others we need to discuss 14:33:24 So, according to the docs, no more downloadable images for WIP/CSC? 14:33:31 Correct. 14:33:31 Correct 14:33:46 WIP will get nightlies 14:33:54 But not CSC 14:34:07 To help only have ppl use WIP/CSC who might also contribute. Keep the noobs away from WIP/CSC boards. 14:34:12 CSC will get link to archive 14:34:36 *WIP will get nightlies of headless to be specific no desktop 14:35:00 what about if this is pinebook X? :) 14:35:51 Same. I'm realizing the people that go through the pain of making unofficial images are the ones that should do the desktops for most 14:36:02 They seek the attention and keeps the pain away from us 14:36:19 not sure about that. they do exactly nothing but wait 14:36:30 pain in term of support perhaps 14:36:54 but on the other hand, we should look forward with this. what are long term pros and cons 14:36:58 Anyway the difference is what we publish vs what is available in build tool 14:37:29 build tool will continue to have all crap, just as CSC / EOS 14:37:37 Yup 14:38:19 ok, any other have concerns about? 14:38:40 Big point of this besides workload and pain is to keep the quality level of our published images very high. And that's what will lead to gold and platinum support opportunities 14:39:12 yes 14:39:18 *besides minimizing 14:39:31 Regarding less support pain, we get tons of support requests for crap such as TV boxes or long unsuported boards, kile Rock64, so we must count on habving some of that still 14:39:43 *like Rock64 14:40:00 this role we should give to community 14:40:05 forum needs changes 14:40:19 we don't want to kill community support 14:40:43 just it has to be clear Armbian maintainers are not dealing with that thing 14:41:10 this part is actually more complicated then deciding which board to drop support 14:41:35 Yeah it's a good point really want to emphasize the forum is self-organzing and community serving community 14:42:37 yes. and if there are strong enough interest to foloow the rules of "supported" technically anything from EOS/CSC can become supported. But this process needs to be well known and polished 14:42:37 Then the bug tracker for boards that are actually supported should be removed from forums. This makes diving stronger 14:42:43 yes 14:42:50 *dividing 14:42:51 Werner: agreed 14:43:12 Where to got with bugtracking on supported boards then? 14:43:14 forum needs refactoring 14:43:16 *go 14:43:20 Jira 14:43:25 Or Github 14:43:37 Jira is more powerful 14:43:40 I'd rather jira be source of truth 14:43:57 Problem: Supported board bugs might be raised by not the supporter. Can / Should randoms post to Jira? 14:44:04 #idea removed official bug tracker from forums 14:44:27 random posts to jira is no go 14:44:32 yeah 14:44:50 So how would average joe report bug on supported board? Which we try to give good support to 14:45:13 now we have a big grey zone called foru 14:45:14 Github issues was meant to be problems with build script only if I am correct. 14:45:19 yes 14:45:26 and that should stays that way 14:45:49 We could create a new repository for supported images/boards that collects bug repots 14:45:52 one idea is to move board specific stuff into separate repository and have them there 14:46:12 i think tonymac32 proposed something similar in the past 14:46:33 I just don't think getting rid of an easy channel to report bugs on supported boards is a good idea, if we want high quality of support on those boards. 14:46:43 it would also produce less noise on main build system 14:47:32 move config/boards config/sources and patches to separate forum 14:47:39 sorry repository 14:47:40 I'd say using Github would be an even easier channel to report an issue rather than forum 14:47:47 See "criteria for supported" in my doc 14:48:35 "A named individual must commit to providing “Best Effort” support for their SBC on the Armbian forums" 14:48:36 so we don't need it? 14:48:53 and leave as it is now 14:49:11 Yeah idea is there's a trusted individual in forum space that triages true bugs that need escalating 14:49:27 ... and use jira for tracking it 14:49:31 Yeah 14:49:43 Just make maintainer forum mod for the bugtracking subforum. 14:49:53 Yeah 14:50:05 i am fine with that principle. 14:50:37 I would also suggest splitting peer to peer / community support more. If we have more boards in CSC in the future it might make sense to add subforums to Peer2Peer by board family 14:51:32 So basically have one category: "CSC" with per family boards for community support and one category "Official support" with per family boards for armbian support with maintainers. 14:51:34 #topic forum changes 14:51:56 #topic forum changes 14:52:01 Only thing is nobody understands family but us 14:52:15 yes. people are attached to board names 14:52:21 true 14:52:25 So I'd almost be inclined to structure more like pine forums 14:52:29 i have noticed a few people lately asking for "where is a forum for X" 14:53:12 Stuff that's a family related issue will be dealt with organically 14:53:37 have links on the download page to support forum category. 14:53:40 It's not like we dont know how to connect devs together 14:53:54 Heisath: AR-909 14:53:54 4AR-909 6[Story] "Website improvements" reported by 3Igor Pecovnik at 2021-09-13. Status: To Do 14:54:04 check if not already, otherwise add 14:54:35 well, people / we are just lazy often 14:54:47 And for us that is ok 14:54:50 we expect UX to think for us 14:55:43 AR-926 14:55:43 4AR-926 6[Sub-task] "Expose maintainers name with URL to forum / github" reported by 3Igor Pecovnik at 2021-09-21. Status: To Do 14:56:00 Added part about links not only to maintainer but also support forum. 14:56:27 yes. i'll try to get website changes within next 30 days 14:57:27 what else we need to do to roll faster? 14:57:40 You own user resources maintainers own machines:. YOUR MOM 14:57:49 Lol 14:59:31 Biggest thing is get doc site updated and I guess clean up maintainer list and setup a PR to change support status and we publish a date of when that change is applied? 15:00:04 Ex: Nov 1 15:00:06 Lol 15:00:21 PR is already there 15:00:24 Celebrate our unrelease 15:00:36 Oh 15:01:01 So I dont know how to communicate this 15:01:06 i think we should remove targert, not comment them 15:01:22 i have one idea 15:01:27 shoot 15:01:34 But literally the jethub people have set the standard on what it means to maintain as a vendor 15:01:37 to make a cycle and remove one board each cycle 15:01:49 And we should highlight that example 15:01:56 each time we do that, its an opporutinty to make a noise 15:02:18 we are removing X unless maintainer doesn't show up until Y 15:02:20 But then we need to do work each cycle. 15:02:23 Meh I'd say pull them all 15:02:25 then at Y, removing 15:02:41 i am building an media department along the way ;) 15:03:06 an idea, like i said 15:03:30 another one is to make a clear message out - what we will do 15:03:42 "here is the list of all unmaintained boards which will be removed on Nov 1. See doc. If you want to maintain see blah" 15:03:47 And really 15:03:47 i am sure most of people are not aware we are removing many boards 15:03:54 Yeah soooo idea 15:03:59 Meet you in the middle 15:04:05 We schedule 1 removal date 15:04:16 But we publish the removal list every week 15:04:19 with a list of orhpaned boards 15:04:33 And hopefily people will see list shrink 15:04:33 yes, then remove them in one go. also good 15:04:35 Yeag 15:04:37 Yep 15:04:48 wörks 15:05:08 And we can celebrate when someone commits to maintain as another thing to tweet 15:05:23 So negative and positive reinforcement 15:05:24 yes 15:05:24 Btw. where to add maintainer in board.conf? 15:05:47 ex. https://github.com/armbian/build/blob/master/config/boards/bananapi.conf 15:05:55 (I didn't solve for that figured it would be easy to figure out) 15:05:57 need to check how that first line is getting text out 15:06:20 first line goes into description 15:08:39 Completely different topic (sorry), but should we really accept these PRs? https://github.com/armbian/build/pull/3200 I mean I know balbes is working on armbian for some time and doing good job at tvboxes, but man some description of pr would be nice. 15:10:19 Heisath: yeah should probably push on that a bit more 15:10:52 1 liner at least saying what or why would be good 15:10:53 perhaps opening a topic on - lets improve our git history ? 15:11:04 and why this is important 15:11:17 Yeah repo practices and coding standards 15:11:29 show ppl good example prs and not this. IIRC correctly we somewhere had "no direct commit to master", all PR with description 15:11:42 All falls under "code quality" topic IMHO 15:12:06 * lanefu just likes to connect things to industry buzzwords for continuity 15:12:34 We have big PR template, should be enough. If ppl ignore it their choice. 15:12:41 yes. we could add some robots to kick submitter ass automatically when providing no description 15:13:05 Yep 15:13:09 Lots of great bots 15:13:16 now - i usually don't have time to start disscussions with submitters 15:13:20 Including ones to autoclose issues 🤠 15:13:35 all these robots working around. The uprising has begun 15:13:46 autoclose on time? 15:14:59 Just add bot that comments, "please add description" on empty PRs would be enough for the beginning. We do not have that many open ones. 15:15:02 if we divide build framework on framework and hardware specifics, it will be much better anyway 15:15:25 we can close 90% of issues right away. 15:15:44 IgorPec: yeah common is autoclose 30 day inactive 15:16:11 30 days is a bit too fast for our MO 15:16:26 more like 90 15:16:32 yeah, somewhere there 15:17:18 Yeah I agree was thinking 60 or so would be more forgiving. I like 90.too 15:17:38 69 days 🤠 15:18:16 AR-942 15:18:16 4AR-942 6[Task] "Adding 90 days autoclose action to the builds system issues" reported by 3Igor Pecovnik at 2021-10-16. Status: To Do 15:18:35 ok, what about splitting build system and hardware specific? 15:18:42 we probably need to discuss a bit 15:19:01 is this the right way to go? If yes, I open a story 15:19:36 this also helps to the changes we are on 15:21:03 * Heisath doesnt care. 15:21:18 IgorPec: I think we're 6 months to a year from being ready for that 15:22:08 ok, planning in a few months then 15:22:31 But we should def make it clear to e everyone it's on our roadmap to keep people from forcing the conversation over and over again 15:23:07 Which really if we were to have a single milestone for each quarter next year what would they be 15:23:19 Err goal 15:23:32 That's the stuff we do need to have published 15:23:40 So people see a vision 15:23:45 so we need to improve this roadmapping 15:23:50 Am I talking too much? 15:23:56 no no, keep going 15:24:23 we do have poor visualisation of planning. 15:24:36 jira is one thing, it help 15:25:15 Yeah. There's a level above epic I forgot what it's called tho lol 15:25:24 but yeah, we should improve planning. overall. not just for development. 15:25:28 story 15:25:42 Yeah. Just singular goal for project as a whole type stuff 15:26:02 or thgeme 15:26:03 theme 15:26:10 Sometimes those goals will be technical and sometimes they won't 15:26:11 https://scrumandkanban.co.uk/theme-epic-story-task/ 15:26:14 Yeah 15:26:19 Nice 15:26:29 Um kind a lost track. Was there a decision now how to handle bug reports for actually supported boards in forum/github/jira/whatever? 15:27:12 Werner: trusted community member k 15:27:13 they stays in forum as now. "bug tracker" name goes away from forums if i understand correctly 15:27:28 Or maintainer responsible for braiding gap 15:28:30 ok 15:28:46 We can ask maintainer to keep list of known problems 15:29:07 that would help and usually this doesn't represent a lot of additional work 15:29:29 s/braiding/bridging 15:29:29 lanefu meant to say: Or maintainer responsible for bridging gap 15:30:45 ok 15:31:17 anything else that needs clarification & discussion? 15:31:43 Next steps for next 2 weeks 15:33:21 keep collecting maintainers for boards and drop everything else (at once) 15:33:26 reinforce media department so we can communicate changes more efficient 15:33:37 keep onboarding 15:33:47 there are two in the line 15:34:00 K any order of operations for that or just get em done 15:34:19 Onboarding is important, not that they loose interest 15:34:42 yes, we have open #armbian-onboarding and i asked people to come here 15:34:49 then we have to talk with them 15:34:50 Yeah speaking of which are we good with bridging onboard irc to discord 15:35:04 not a problem for me 15:35:26 #action bridge onboarding with discord 15:36:35 i have asked yang if he can help with greetings. like this initial welcome 15:37:04 "hi ... please come to chat with us at #armbian-onboarding 15:38:04 Misc question: @Igor, what happened with Khadas offering support for the project? 15:38:11 I think there is a way to create individual forums for each supported board without stretching the forum index over multiple pages 15:38:31 igor, lane, check forum and scroll down, you should be able to see what i mean 15:38:53 jmcc: nothing out of that 10k they donated 15:39:05 and they send us a bunch of boards 15:39:16 Werner: yep that works for me 15:40:34 I see rpardini wants to support Khadas boards if he can get hardware. That won't be a problem then? 15:40:36 khadas boards were brought in and we will cover them. i promise them we will keep them in at least one year. 15:40:49 In theory we could add support for T-Firefly ROC RK399 PC-PLUS without any effort since it is the board used in the station p1 ^^ 15:41:06 i have some spare and probably we could get more. but we should also connect labs 15:41:20 i have all those boards online with serial console and some with a hdmi monitor connected 15:41:40 hdmi monitor will be KVM streamer soon 15:42:27 and if one covers bananapi, pro is also covered 15:47:39 Werner: nope balbes gotta put his name on each one 15:48:00 It is not even in the list (yet) 15:48:03 We can just delete the SBC if it's the same as p1 15:48:13 However we could ask. Under the hood its just c&p 15:48:15 so it can be supported with one image 15:48:40 well, there we will try to get some deals 15:55:46 so, is the meeting closed? 15:56:01 I guess most is spoken 15:56:10 yes, i think we can close it. 15:56:17 aight. have a great day 15:56:18 #endmeeting