lanefu Posted October 1, 2018 Posted October 1, 2018 There isn't a waiting list on bus accidents I hope?? We don't use busses, every American has a 4WD V8 truck with giant tires and American flags flying in the bed. . I could get hit by one of those... My 4x4 v8 truck doesnt have giant tires.....but oem is pretty big so... true statement 'Merica.Sent from my SM-G950U using Tapatalk 1
lanefu Posted October 1, 2018 Posted October 1, 2018 My 4x4 v8 truck doesnt have giant tires.....but oem is pretty big so... true statement 'Merica.Sent from my SM-G950U using TapatalkOhh. And there was the time i drove from Raleigh to Richmond like thisSent from my SM-G950U using Tapatalk
chwe Posted October 2, 2018 Author Posted October 2, 2018 19 hours ago, chwe said: - collecting wishes on a special web page or forum topic. When someone approaches with "I want to help" that it is appointed to 1. Check issues on GH, 2. Fixing sound ... 3. Creating this ... idea: a short tutorials series for a proper work-flow for 'small contributions' e.g. I need *random kernelmodule*: fork the project create a new branch change kernel config replace config/kernel/*.config send PR with some background that when ever possible it should be configured as module. I want to create a patch for *random kernel*: fork --> new branch --> create patch = yes --> change when you're prompted to do --> move it to patches --> test if all patches applies properly --> send PR It's just to explain better what our buildscript is capable to do without doing all this stuff by hand. And explain how our patchfolders are structured. 19 hours ago, chwe said: - improving testing protocols, automating what is possible. I'm low on ideas what more is possible to do. Let's see what the R2 is capable to to. It has some spare UARTS, ETH and some GPIOs to toggle relays to powercycle the boards. At least until it doesn't boot up anymore it should be possible to create some sort of an automatic upgrade tester..
Igor Posted October 2, 2018 Posted October 2, 2018 4 hours ago, chwe said: idea: a short tutorials series for a proper work-flow for 'small contributions' e.g. That is already written and it is used ad hoc or if a person bumps into:https://docs.armbian.com/Process_Contribute/ Instead of telling people what to do. Let's ask people if they want to take responsibility as such: - source code maintainer - adjust kernel configurations, patches, ... help on what we do, - project manager: development and testings overview, samples redistribution - code cleaner - sweeping our build script code round the clock - documentation editor - as a title implies - marketing manager - to help communicate project specific services, new features, changes, ... 1
tkaiser Posted October 3, 2018 Posted October 3, 2018 29 minutes ago, Tido said: https://www.armbian.com/pine64/ @Igor certificate for www.armbian.com expired. @Tido good luck with this sort of poll (no idea why contents of the 'board details' page is now part of download page -- but you might start similar polls for two other totally uninteresting boards: ODROID-C2 and C1)
Igor Posted October 3, 2018 Posted October 3, 2018 6 minutes ago, tkaiser said: certificate for www.armbian.com expired. Working on it (moving to another server on the way).
tkaiser Posted October 3, 2018 Posted October 3, 2018 2 hours ago, Igor said: moving to another server on the way Great way to communicate project details. I guess this (keeping this whole thing your private pet) is key to success.
Igor Posted October 3, 2018 Posted October 3, 2018 1 minute ago, tkaiser said: Great way to communicate project details. I guess this (keeping this whole thing your private pet) is key to success. I didn't have many choices - an urgent matter which didn't turn out well. Until this (and my many other duties) is not upgraded to something more pro, this remains as is. I would gladly not deal with this shit the whole day.
tkaiser Posted October 3, 2018 Posted October 3, 2018 41 minutes ago, Igor said: didn't have many choices What should change as long as you keep 'Armbian' your personal project?
Igor Posted October 3, 2018 Posted October 3, 2018 Just now, tkaiser said: What should change as long as you keep 'Armbian' your personal project? I am trying hard to push it away from my personal domain. Surely possible that not properly or right direction.
lanefu Posted October 3, 2018 Posted October 3, 2018 So i just checked out the ideas of role needs on the contributions thread.@tkaiser what's the biggest pain point that makes it indicative of "pet project" characteristics?[mention=1]igor[/mention] what's the most important part of the armbian project to you? Sent from my SM-G950U using Tapatalk
chwe Posted October 4, 2018 Author Posted October 4, 2018 Background: the last 7 posts came from: I think those discussions fit better here than elsewere... Some updates for the table: Quote There are still (many)some (short and) long-term questions which are scattered on the forum and in our heads which we would need to discuss. - release naming, 2018.10 or 18.04 + some RFC as shown on the pic, - collecting wishes on a special web page or forum topic. When someone approaches with "I want to help" that it is appointed to 1. Check issues on GH, 2. Fixing sound ... 3. Creating this ... - improving testing protocols, automating what is possible. I'm low on ideas what more is possible to do. - what to add to »end of support«? proposed: dropped kernels: cubox 3.14.y and Udoo, Meson 3.10.y default, SP6818-default 4.4.y (@igor) proposed: Allwinner 3.4 --> EOS (@chwe) proposed: dropped boards: Olimex Lime2 NAND, Bananapi PRO, Olimex Micro, Orangepi Pi2, Orangepi+, Nanopi M1, MiQi, NanopiM1+ (@igor) ODROID-C2 and C1 (@tkaiser) - secure project longterm survival, leverage maintenance costs to users or drastically limit down free support, proposed: TBD e.g. explain better what users can expect, how to find information (mostly @chwe) better communication of 'back-end' changes (e.g. serverchanges) @tkaiser source code maintainer - adjust kernel configurations, patches, ... help on what we do, (@igor) project manager: development and testings overview, samples redistribution (@igor) code cleaner - sweeping our build script code round the clock (@igor) documentation editor - as a title implies (@igor) marketing manager - to help communicate project specific services, new features, changes, ... (@igor) - enforce browser of choice for desktop images, Firefox and/or some lighter alternatives? https://forum.armbian.com/topic/8373-better-video-playback-with-vivaldi-browser-for-all-arm-sbcs/ just picked up and maybe it fits.. who knows.. - fix Bluetooth on all Broadcom AP62xx devices. Its the same on most boards, but we have it working only on a Cubietruck IIRC - sum most frequent problems under »The Ten Commandments« / FAQ and promote it as much as possible - does forum need structure update? if 3.4 goes EOS change order (mainline/bsp) for Allwinner H2 & H3 (@chwe) - add/remove moderators? Disable rights if not moderating content in past 6months? @Tido do we have a list of all mods? (I thought there's one but couldn't find it anymore, just highlight them all here to see if they're active) - enforce forum rules? Some very simple ones. - users are still seeking for help without providing logs. What to do about? Download UX: - make a bigger diff between nightly and stable, desktop and CLI (Gorazd) - add a warning when nightly is downloaded, (Gorazd) - tested devices lead to their test page where exists instead of Amazon affiliate, (Gorazd) - tested hardware have information to which kernel is attached to but not displayed, (Gorazd) - check other download option still no visible enough, (Gorazd) - add a support box with 1. Check common issues 2. Search for solution 3. Ask (with a link to the correct forum) (Gorazd) - add a button »alternative builds« with a link to dl.armbian.com/DEVICE (Gorazd) not 100% properly updated - feel free to enhance. 1
sfx2000 Posted October 6, 2018 Posted October 6, 2018 On 10/2/2018 at 6:48 AM, Igor said: That is already written and it is used ad hoc or if a person bumps into:https://docs.armbian.com/Process_Contribute/ Instead of telling people what to do. Let's ask people if they want to take responsibility as such: - source code maintainer - adjust kernel configurations, patches, ... help on what we do, - project manager: development and testings overview, samples redistribution - code cleaner - sweeping our build script code round the clock - documentation editor - as a title implies - marketing manager - to help communicate project specific services, new features, changes, ... Just to share a thought or two... Armbian is actually in a special place - and thru community consensus and working with the OEM/Chipset community can do a lot of good work... Not that much different than what the OpenWRT and FreeElectrons/Bootlin folks have done... I've read thru the threads - and that really stuck out was @tkasier and the GPIO mess that is... and yes, it's a mess. (along with uboot and dts, and then solve kernel and related stuff) - anyways, been there, done that. Armbian has great experience at bringing up boards, doing some tweaks to improve performance/compat as needed... So it's reach out to the community - the chipset guys, the board folks, work with the community - and there, it's the regular gatherings, and build the brand and set up BOF meetings to get some consensus across the community. I'm a former member of IETF - and one of the big deals is letting loose of ownership, but keeping a gentle hand on development, and that gains a lot of respect within the larger than armbian team... Hard to explain, but if the team has already solved hard problems, then those solutions are generally agreed upon, so the collective can move forward. Getting back to Igor's statement... Don't tell - rather be open and ask... Find the community gatherings, work the threads with OEM's and Chipset contacts... 1
Igor Posted October 7, 2018 Posted October 7, 2018 On 10/6/2018 at 4:29 AM, sfx2000 said: Hard to explain, but if the team has already solved hard problems, then those solutions are generally agreed upon, so the collective can move forward. There was never a formal team. More like a strong common passion and interest to do something valuable, to push things forward, to help, to show how things should look like. IMO it worked very well until the level of self-fulfillment and happines was high enough and a mountain of problems low enough. People perception on this is very colorful and even among inner circle, we have different views. No matter how good and super the project might be. We have more and more users, while most of them waste our time and energy, contribute nothing and ask for more. This is not sustainable. Armbian might not need major build script or infrastructure development, but both need regular maintenance. We are short already for that. Not hardware, not software but responsibility. If board support is extending and developing, then this will bring solving harder problems which are not possible to be solved by a few people in their free time. This calls for 20-30x size of the budget size. Where from? On the other hand, people expect that "we will solve all the problems they find out". Reality is that our main workforce is basically offline due to overload, mounted problems, life, ... We can talk about how to reshape the project, but first, you need someone that will execute what we brained out. Personally, I need to look on a project from a distance and leave super (hardware) details behind. It might give me an opportunity to better see the problems we have. 3
sfx2000 Posted October 7, 2018 Posted October 7, 2018 29 minutes ago, Igor said: There was never a formal team. More like a strong common passion and interest to do something valuable, to push things forward, to help, to show how things should look like. IMO it worked very well until the level of self-fulfillment and happines was high enough and a mountain of problems low enough. People perception on this is very colorful and even among inner circle, we have different views. No matter how good and super the project might be. We have more and more users, while most of them waste our time and energy, contribute nothing and ask for more. This is not sustainable. Armbian might not need major build script or infrastructure development, but both need regular maintenance. We are short already for that. Not hardware, not software but responsibility. If board support is extending and developing, then this will bring solving harder problems which are not possible to be solved by a few people in their free time. This calls for 20-30x size of the budget size. Where from? On the other hand, people expect that "we will solve all the problems they find out". Reality is that our main workforce is basically offline due to overload, mounted problems, life, ... We can talk about how to reshape the project, but first, you need someone that will execute what we brained out. Personally, I need to look on a project from a distance and leave super (hardware) details behind. It might give me an opportunity to better see the problems we have. Thanks for sharing... Looking in from the outside - I see strong alignment across different groups and teams that I follow... Armbian might not have a recognized "formal team" - but I do see more than that - with strong contributors, deep insight, and for what it's worth - a shipping product - which is a big deal. As my most recent foray into startups - the shipping product is a big deal, seriously, it is... Let's put together a biz plan, and Armbian can be that BSP for OEM's to work with... and that would benefit both the OEM's and the Users, and building a relationship with chipset vendors would take it forward.
TonyMac32 Posted October 12, 2018 Posted October 12, 2018 On 10/3/2018 at 2:26 PM, tkaiser said: but you might start similar polls for two other totally uninteresting boards: ODROID-C2 and C1) Just saw this one, honestly just throw away the vendor kernel and roll it into Meson64, it has extremely active upstream support and should soon have vdec support in mainline with Le Potato and K2. Then we've eliminated a kernel and uncluttered. The C1 is strangely also getting mainline support, but I have no idea the maturity, someone with one or Bay Libre would need to speak to that. I don't see too much logic behind throwing it away when it shares 95% of its self with 2 other boards we support (the C2 anyway). 1
chwe Posted October 12, 2018 Author Posted October 12, 2018 On 10/4/2018 at 1:25 PM, chwe said: There are still (many)some (short and) long-term questions which are scattered on the forum and in our heads which we would need to discuss. - release naming, 2018.10 or 18.04 + some RFC as shown on the pic, discussion happens here: https://github.com/armbian/build/pull/1129 - collecting wishes on a special web page or forum topic. When someone approaches with "I want to help" that it is appointed to 1. Check issues on GH, 2. Fixing sound ... 3. Creating this ... - improving testing protocols, automating what is possible. I'm low on ideas what more is possible to do. - what to add to »end of support«? proposed: dropped kernels: cubox 3.14.y and Udoo, Meson 3.10.y default, SP6818-default 4.4.y (@igor) proposed: Allwinner 3.4 --> EOS (@chwe) proposed: dropped boards: Olimex Lime2 NAND, Bananapi PRO, Olimex Micro, Orangepi Pi2, Orangepi+, Nanopi M1, MiQi, NanopiM1+ (@igor) ODROID-C2 and C1 (@tkaiser) proposed: merge BOARDFAMILY ODROOID-C2 with Meson64 and drop 3.1x kernel for it @TonyMac32 - secure project longterm survival, leverage maintenance costs to users or drastically limit down free support, proposed: TBD e.g. explain better what users can expect, how to find information (mostly @chwe) better communication of 'back-end' changes (e.g. serverchanges) @tkaiser source code maintainer - adjust kernel configurations, patches, ... help on what we do, (@igor) project manager: development and testings overview, samples redistribution (@igor) code cleaner - sweeping our build script code round the clock (@igor) documentation editor - as a title implies (@igor) marketing manager - to help communicate project specific services, new features, changes, ... (@igor) - enforce browser of choice for desktop images, Firefox and/or some lighter alternatives? https://forum.armbian.com/topic/8373-better-video-playback-with-vivaldi-browser-for-all-arm-sbcs/ just picked up and maybe it fits.. who knows.. - fix Bluetooth on all Broadcom AP62xx devices. Its the same on most boards, but we have it working only on a Cubietruck IIRC - sum most frequent problems under »The Ten Commandments« / FAQ and promote it as much as possible - does forum need structure update? if 3.4 goes EOS change order (mainline/bsp) for Allwinner H2 & H3 (@chwe) - add/remove moderators? Disable rights if not moderating content in past 6months? @Tido do we have a list of all mods? (I thought there's one but couldn't find it anymore, just highlight them all here to see if they're active) - enforce forum rules? Some very simple ones. - users are still seeking for help without providing logs. What to do about? Download UX: - make a bigger diff between nightly and stable, desktop and CLI (Gorazd) - add a warning when nightly is downloaded, (Gorazd) - tested devices lead to their test page where exists instead of Amazon affiliate, (Gorazd) - tested hardware have information to which kernel is attached to but not displayed, (Gorazd) - check other download option still no visible enough, (Gorazd) - add a support box with 1. Check common issues 2. Search for solution 3. Ask (with a link to the correct forum) (Gorazd) - add a button »alternative builds« with a link to dl.armbian.com/DEVICE (Gorazd) updated. Edit: just to be clear this is not my list.. Quote and edit it with blablabla not relevant anymore or proposed: blablabla @jane_and_joe_random is highly appreciated..
JMCC Posted October 12, 2018 Posted October 12, 2018 3 minutes ago, chwe said: proposed: merge BOARDFAMILY ODROOID-C2 with Meson64 and drop 3.1x kernel for it Well, it is true that Hardkernel's kernel has many features that meson64 lacks (like full GPU/VPU support, or overclocking), but I doubt many people use those features with an Armbian image. As a matter of fact, I experienced that my XU4 media script caught almost zero attention compared to the TinkerBoard. I guess that, since HK's images are quite good, people who want to use those special features just use them, since they don't need additional config like Armbian does (and there is no media script for C2). So I think that, if C2 works well enough with meson64, we can drop it as a separate board family. That way, we offer a real alternative to the official HK images, and may probably attract more attention (some people would want to use Armbian instead of HK's because they want "vanilla" meson64).
Igor Posted October 13, 2018 Posted October 13, 2018 10 hours ago, JMCC said: if C2 works well enough with meson64, we can drop it as a separate board family. There is no diff between OdroidC2 NEXT and meson64 next since the last update. Known problems: USB hot plugging and network initialisation on some C2 boards. I don't know if this latter happens on a stock 3.x kernel too. XU4 default 3.10.y could be also added to the EOS list. 11 hours ago, TonyMac32 said: The C1 is strangely also getting mainline support, but I have no idea the maturity Maturity is unknown to me as well. Back then I did a basic adjustment and made few tests. Known problems and shortcomings: no HDMI, no DVFS, halt on reboot, ... modern u-boot support? Not sure if this will change anytime soon. We can drop 3.x and wait with mainline for a few months else drop C1 completely? Allwinner 3.4 and 3.10/Pinebook should stay in the system. There are many users and projects such as H3Droid and Retroorangepi are dependent from it. Even there is no more development and support. Even code quality is so so ... Since we started to talk about changing u-boot update from auto to manual, which should have bigger impact on support pressure, we can lower threshold for EOS on only most obvious ones.
chwe Posted October 13, 2018 Author Posted October 13, 2018 2 hours ago, Igor said: Since we started to talk about changing u-boot update from auto to manual, which should have bigger impact on support pressure, we can lower threshold for EOS on only most obvious ones. or we trash them (EOS, not fully removal from the buildsystem yet at least for the 'not most obvious ones'), take a breath and start to do some housekeeping (e.g. in docs, buildscript source code, armbian-config). We still can make a call in the dedicated sub-forums that *board X* or *kernel Y* seeks a new maintainer so that interested people can step in before all patches get so outdated that nobody wants to deal with it anymore. As far as I understand you, you want to give away some 'backend' responsibility as well, On 10/3/2018 at 11:43 PM, Igor said: I am trying hard to push it away from my personal domain. couching someone else to deal with it needs also time. If you just get the 'minimum of time' back to 'work well oiled' again you might not have the time and energy to hand over some of your duties which then ends in a mess (house-keeping may not be as funny as board support work but I assume it saves us time in the long term).
zador.blood.stained Posted October 14, 2018 Posted October 14, 2018 On 10/8/2018 at 1:30 AM, Igor said: No matter how good and super the project might be. We have more and more users, while most of them waste our time and energy, contribute nothing and ask for more. This is not sustainable. Then the project should be scaled back to the point where it is sustainable? On 10/8/2018 at 1:30 AM, Igor said: If board support is extending and developing, then this will bring solving harder problems which are not possible to be solved by a few people in their free time. This calls for 20-30x size of the budget size. Where from? If a problem requires too much time to solve then it should be ignored until someone more knowledgeable or more resourceful solves it? On 10/8/2018 at 1:30 AM, Igor said: On the other hand, people expect that "we will solve all the problems they find out". Reality is that our main workforce is basically offline due to overload, mounted problems, life, ... Then maybe "we" should not try to satisfy everyone? This includes answering to topics if you don't know the answer or can't solve the problem right now, includes providing nightly images and images for community supported devices (let people build images by themselves and share them without using the project infrastructure (i.e. via MEGA or Google Drive) since disk space and traffic costs money that doesn't come from nothing). Also includes working on and especially providing any images already for H6 which is (IMO) > 6 months away from getting enough green squares in the sunxi status matrix for making images suitable for everyday use. Includes providing "better" wireless drivers if integrating and testing them takes too much time. On 10/13/2018 at 12:57 AM, chwe said: - enforce forum rules? Some very simple ones. I think this would help too, I don't want to wash my eyes with a soap after reading some threads. 2
chwe Posted October 15, 2018 Author Posted October 15, 2018 20 hours ago, zador.blood.stained said: On 10/12/2018 at 11:57 PM, chwe said: - enforce forum rules? Some very simple ones. I think this would help too, I don't want to wash my eyes with a soap after reading some threads. Something like this will do: Spoiler every old lab has susch a bottle... Not sure if it needs rules or just explanation. After a 'soap moment' I wrote once such a explanation but never published it: Quote # Welcome to the Armbian community Forum Cause maintenance of the community and developing Armbian to get an as much as possible reliable OS for your single board computer is often done by the same group of people we set up a few *rules* to keep community maintenance on a decent level. Keep in mind, the more time we need for solving your issues, the less time we have to develop Armbian. Bring up *random feature* to Armbian later might be related to the time we need to answer questions here. The following write up should give you some insights how our Forum is organized. ## Technical support Tech. support is splitted into SoC specific sub-forums (e.g. Allwinner A20/H2&H3, Amlogic S905 etc.). You have a hardware or kernel (e.g. missing a specific kernel module) related issue that's the place to report it. Ubuntu/Debian related questions (e.g why *random package* fails on installation) is likely not an board-specific question and should be asked Common issues. If you face any sorts of instabilities over time, please have a look in the SD card and power supply subforum of Common issues cause chances are high that your thread will also end there. Armbian is trimmed on performance, performance needs juice, not reliable PSUs and/or powering cables will avoid the juice Armbian needs to work reliable. The same counts for not reliable SD-Cards, some boards are prone to avoid working with slow cards and every board doesn't like if your SD-Card has bad sectors (getting started guide gives you a proper procedure how you check your SD-Card prior to use with Armbian). If your board isn't supported by Armbian (e.g. no Image is provided on our download page) means that your question should be asked in 'Peer to peer technical support' in the Community forums part of the Forum. We don't provide support for hardware which isn't supported by us. This counts for not supported boards and third party hardware. We simply can't test every third party hardware you probably want to use with Armbian cause we either don't own it or/and secondly don't have the time to test all the hardware people stick to their boards. A good support question includes the following: - Board you use - Issue you face - Description of your set-up (e.g. powering, connected hardware, used SD-Card) - 'sudo armbianmonitor -u' - this gives us some needed logs which makes debugging a way easier! We aren't 'SBC Whisperers' or mind-readers we need logs to work with, that's why 'armbianmonitor -u' was developed. If your board refuses to boot with a freshly prepared Image from our download page, please read again 'SD card and power supply' chances are high that this is a related to SD card and or insufficient powering! If your board refuses to boot after upgrade, try to provide at least a bootlog from serial console. USB-UART bridges aren't that pricey and worth every cent when you work with SBCs. Lastly, most of us aren't native English and it's not an issue if your language isn't polished. As long as you try to describe your system and your problem best, it doesn't matter if there are some small errors in wording. Further, we have docs.armbian.com mostly written by developers for users. A bunch of questions can be answered by reading the docs and or using the search-engine first. ## Community forums*P2P tech support* is mainly for boards where we didn't provide official support. E.g. boards marked as .csc/.eol in Armbians boardconfig. Those board get not the same amount of support cause they are .csc or .eol for a reason (e.g. nobody is interested in maintaining and testing them or we don't have enough samples to test them). There's a Reviews subforum where people with a good background review SBCs critically and Research guides & tutorials section. You built a fancy project on top of Armbian? We happily read your story how you get it working! From users by users, people might ask you how you solved parts or how you can enhance your project. *TV boxes*: we don't provide official Armbian support for most TV boxes. But we offer a buildscript which makes it possible to build images for TV boxes and we provide a subforum where people interested in Linux on TV boxes can dicuss the issues they face. *General chit chat*: Armbians water-cooler to discuss rumors towards shiny new toys and/or not Armbian related stuff - not always 100% serious here. ## Development A section mostly for more experienced users, for example for SoCs where Armbian support is currently not mature enough for full support, questions related to the build framework and 'Board Bring Up' for new boards we might consider supporting in the future. We can't provide the same level of support for WIP (work in process) SoCs cause kernels for those boards are simply not ready yet. Board Bring Up is mostly for experienced users which want to contribute in support for new boards/SoCs, a *please support random board* without any rational and no interest in contribution for such a support will simply be ignored. If you just want to point us to a new interesting board our watercooler (General chit chat) is the right place for it. Maybe sufficient? maybe it needs to be more strict? Something like this pinned on every subforum once again mighthelp.
chwe Posted October 15, 2018 Author Posted October 15, 2018 On 10/12/2018 at 11:57 PM, chwe said: There are still (many)some (short and) long-term questions which are scattered on the forum and in our heads which we would need to discuss. - release naming, 2018.10 or 18.04 + some RFC as shown on the pic, discussion happens here: https://github.com/armbian/build/pull/1129 - collecting wishes on a special web page or forum topic. When someone approaches with "I want to help" that it is appointed to 1. Check issues on GH, 2. Fixing sound ... 3. Creating this ... - improving testing protocols, automating what is possible. I'm low on ideas what more is possible to do. - what to add to »end of support«? proposed: dropped kernels: cubox 3.14.y and Udoo, Meson 3.10.y default, SP6818-default 4.4.y (@igor) proposed: Allwinner 3.4 --> EOS (@chwe) proposed: dropped boards: Olimex Lime2 NAND, Bananapi PRO, Olimex Micro, Orangepi Pi2, Orangepi+, Nanopi M1, MiQi, NanopiM1+ (@igor) ODROID-C2 and C1 (@tkaiser) proposed: merge BOARDFAMILY ODROOID-C2 with Meson64 and drop 3.1x kernel for it @TonyMac32 - secure project longterm survival, leverage maintenance costs to users or drastically limit down free support, proposed: TBD e.g. explain better what users can expect, how to find information (mostly @chwe) better communication of 'back-end' changes (e.g. serverchanges) @tkaiser source code maintainer - adjust kernel configurations, patches, ... help on what we do, (@igor) project manager: development and testings overview, samples redistribution (@igor) code cleaner - sweeping our build script code round the clock (@igor) documentation editor - as a title implies (@igor) marketing manager - to help communicate project specific services, new features, changes, ... (@igor) not provide images for SoCs for wich support is early wip (e.g H6 --> @zador.blood.stained) forum rules ( @Igor @zador.blood.stained) proposed: rescale project back to a smaller size (@zador.blood.stained) - enforce browser of choice for desktop images, Firefox and/or some lighter alternatives? https://forum.armbian.com/topic/8373-better-video-playback-with-vivaldi-browser-for-all-arm-sbcs/ just picked up and maybe it fits.. who knows.. - fix Bluetooth on all Broadcom AP62xx devices. Its the same on most boards, but we have it working only on a Cubietruck IIRC - sum most frequent problems under »The Ten Commandments« / FAQ and promote it as much as possible - does forum need structure update? if 3.4 goes EOS change order (mainline/bsp) for Allwinner H2 & H3 (@chwe) - add/remove moderators? Disable rights if not moderating content in past 6months? @Tido do we have a list of all mods? (I thought there's one but couldn't find it anymore, just highlight them all here to see if they're active) - enforce forum rules? Some very simple ones. - users are still seeking for help without providing logs. What to do about? Download UX: - make a bigger diff between nightly and stable, desktop and CLI (Gorazd) - add a warning when nightly is downloaded, (Gorazd) - tested devices lead to their test page where exists instead of Amazon affiliate, (Gorazd) - tested hardware have information to which kernel is attached to but not displayed, (Gorazd) - check other download option still no visible enough, (Gorazd) - add a support box with 1. Check common issues 2. Search for solution 3. Ask (with a link to the correct forum) (Gorazd) - add a button »alternative builds« with a link to dl.armbian.com/DEVICE (Gorazd) for the part which is now green.. It's around 2 weeks there and nobody insisted.. Should we announce in their subforums that those boards/kernels seek either a new maintainer or they get dropped? Or just for the bords? E.g. 'maintainership' includes proper testing of boards before each 'major' release (e.g. subversion kernel change for next, or u-boot change) testing and adjusting patches in dev after every sublevel jump.
Tido Posted October 15, 2018 Posted October 15, 2018 On 10/15/2018 at 4:59 PM, chwe said: It's around 2 weeks there and nobody insisted.. Captain Chaos, I don't have the time to read each time 10 posts and make notes to find out where we are standing form one post and topic to the next. Fazit: I never considered to take part in this discussion here - too inefficient. On the Excel you can write: @chwe to each topic and leave your comment to each topic and so can others. Where all agree we can solve it, where not we can discuss in the forum in a dedicated Thread, for example a series that starts with: AB improvements: xyz . Why you would drop: Bananapi PRO is a miracle to me.
Igor Posted October 16, 2018 Posted October 16, 2018 15 hours ago, Tido said: too inefficient Yep. Instead of colouring or transferring to xls/md, @chwe at least move tasks out to a clean b/w list of items which is more or less agreed upon and below a list where someone expressed concerns. Nothing else. KISS. 16 hours ago, chwe said: Should we announce in their subforums that those boards/kernels seek either a new maintainer or they get dropped? What about keeping this here https://docs.armbian.com/Release_Changelog/ when the time comes and some text remained on the specific download pages? It can be done generally inside some reddish box -> if BOARD=EOS; then echo "We don't support this board any more which means blablabla and if YOU want to take care of the board DO THIS. In this case, board can be moved to CSC, which means it will remain in the system but will not be officially supported" ? When this is done, forum announcement can follow. 16 hours ago, chwe said: I wrote once such a explanation but never published it: Good. I will check them and make a TL;DR; version at the beginning of the document and you check my babbling? -> a general join/contribute documentation: https://www.armbian.com/get-involved/ It's WIP and a current templates should be somehow incorporated. Then we again need a TL; DR; version at the beginning of the document following by a proper placement & linking.
chwe Posted October 16, 2018 Author Posted October 16, 2018 4 hours ago, Igor said: What about keeping this here https://docs.armbian.com/Release_Changelog/ when the time comes and some text remained on the specific download pages? I think the Forum is generally more read than changelog (I don't have stats to back this claim.. ). Our goal is more contribution and better communication. For me the change-log shows decisions already made. A 'Board seeks new maintainer' thread is an announcement. We plan to drop support for *random board/kernel* if you disagree you've to step in cause as soon patches related to it fail we will drop them (e.g. moving them to a EOS sub-folder or delete them) and new images are not longer provided (or images are not longer provided at all? - reduces 'infrastructure coast' keep them in 'seed our torrents' only could be a good idea. Community is responsible to keep them 'online'). 5 hours ago, Igor said: document and you check my babbling? I assume at least @TonyMac32, @lanefu and @martinayottes english is better than mine. But for sure, I can have a look. @Tido the discussion happens in public. Make your list public and I may fill in it there as well.. For me it sounds reasonable to only monitor one thread and Igors PR. As soon as we 'extract' actions out of it they get their dedicated threads (at least the bigger tasks/projects --> e.g. the release naming which happens on github). 21 hours ago, chwe said: There are still (many)some (short and) long-term questions which are scattered on the forum and in our heads which we would need to discuss. - release naming, 2018.10 or 18.04 + some RFC as shown on the pic, discussion happens here: https://github.com/armbian/build/pull/1129 - collecting wishes on a special web page or forum topic. When someone approaches with "I want to help" that it is appointed to 1. Check issues on GH, 2. Fixing sound ... 3. Creating this ... - improving testing protocols, automating what is possible. I'm low on ideas what more is possible to do. - what to add to »end of support«? proposed: dropped kernels: cubox 3.14.y and Udoo, Meson 3.10.y default, SP6818-default 4.4.y (@igor) odroid-c2 3.1x kernel @tonymac proposed: Allwinner 3.4 --> EOS (@chwe) proposed: dropped boards: Olimex Lime2 NAND, Bananapi PRO, Olimex Micro, Orangepi Pi2, Orangepi+, Nanopi M1, MiQi, NanopiM1+ (@igor) ODROID-C2 and C1 (@tkaiser) proposed: merge BOARDFAMILY ODROOID-C2 with Meson64 and drop 3.1x kernel for it @TonyMac32 - secure project longterm survival, leverage maintenance costs to users or drastically limit down free support, proposed: TBD e.g. explain better what users can expect, how to find information (mostly @chwe) better communication of 'back-end' changes (e.g. serverchanges) @tkaiser source code maintainer - adjust kernel configurations, patches, ... help on what we do, (@igor) project manager: development and testings overview, samples redistribution (@igor) code cleaner - sweeping our build script code round the clock (@igor) documentation editor - as a title implies (@igor) marketing manager - to help communicate project specific services, new features, changes, ... (@igor) not provide images for SoCs for wich support is early wip (e.g H6 --> @zador.blood.stained) forum rules ( @Igor @zador.blood.stained) proposed: rescale project back to a smaller size (@zador.blood.stained) proposed: u-boot update only upon request (@zador.blood.stained @Igor @g-provost [github] -https://github.com/armbian/build/pull/1129#issuecomment-429266397) - enforce browser of choice for desktop images, Firefox and/or some lighter alternatives? https://forum.armbian.com/topic/8373-better-video-playback-with-vivaldi-browser-for-all-arm-sbcs/ just picked up and maybe it fits.. who knows.. - fix Bluetooth on all Broadcom AP62xx devices. Its the same on most boards, but we have it working only on a Cubietruck IIRC - sum most frequent problems under »The Ten Commandments« / FAQ and promote it as much as possible - does forum need structure update? if 3.4 goes EOS change order (mainline/bsp) for Allwinner H2 & H3 (@chwe) - add/remove moderators? Disable rights if not moderating content in past 6months? @Tido do we have a list of all mods? (I thought there's one but couldn't find it anymore, just highlight them all here to see if they're active) - enforce forum rules? Some very simple ones. - users are still seeking for help without providing logs. What to do about? Download UX: - make a bigger diff between nightly and stable, desktop and CLI (Gorazd) - add a warning when nightly is downloaded, (Gorazd) - tested devices lead to their test page where exists instead of Amazon affiliate, (Gorazd) - tested hardware have information to which kernel is attached to but not displayed, (Gorazd) - check other download option still no visible enough, (Gorazd) - add a support box with 1. Check common issues 2. Search for solution 3. Ask (with a link to the correct forum) (Gorazd) - add a button »alternative builds« with a link to dl.armbian.com/DEVICE (Gorazd) 1
5kft Posted October 16, 2018 Posted October 16, 2018 Just "thinking out loud" as it were, but I am wondering if introducing some sort of "ticketing system" for Armbian could be useful for tracking things and helping add some structure around helping with the project (and for people to get help). At present now the forums can be great for discussion, but they are very ad-hoc as an engagement system. I find that for myself if I'd like to raise something I'm not sure what the best method is - e.g., post in a forum somewhere, submit an Issue for the project on github, or just push a fix into the project and explain the change in a commit comment, add a PR with a comment discussion, etc... Ticket systems can also be "black holes", but forum posts can be as well... This could help people structure engagement, communicate on a particular thread, using a more structured and trackable process...? I love to help the project, and I try to help when I can, but I'm not sure how I best could contribute, given my (unfortunate) sporadic availability. If I have some spare time on some weekend, it'd be great to look through tickets and see if I could fix something for someone, or help someone with something... Another example - my NEO4 comes today, and I'd like to play with it this weekend, and start fixing things, pushing changes, etc. but I also don't want to "step on anyone's toes" (I'm a Rockchip newbie, which is one reason I got the board ) - assigning tickets for areas could help focus discussion, coordinate work between people, etc...? Anyway just some quick thoughts...!
Tido Posted October 16, 2018 Posted October 16, 2018 5 hours ago, chwe said: Make your list public it is public since its first day just share the link. 2 hours ago, 5kft said: some sort of "ticketing system" for Armbian That would mean that you have to pay for support, that would mean that we feel guilty if we not answer on time. That could lead to burn out and that could lead to ..
5kft Posted October 16, 2018 Posted October 16, 2018 18 minutes ago, Tido said: That would mean that you have to pay for support... I'm curious why that would need to be the case...? I'm thinking that it could be as simple as using something like Bugzilla (https://www.bugzilla.org/download/) or any number of other ticket systems used by FOSS projects and initiatives. Just for issue/question organization and tracking. It's not much different than using a forum system - no pay needed, etc.?
Tido Posted October 16, 2018 Posted October 16, 2018 4 minutes ago, 5kft said: system - no pay needed Well, one system is not enough, you need a backup system = cost. Then you need to do backups = cost. You must maintain this software/service/device/troubles cost==time. Time is precious, we already suffer on having not enough time to keep armbian stable. So we would need more volunteers, but then it looks like you must do it because there are people waiting with their ticket, bump, bump, bump (but people do not like commitments) = not more volunteers. Whereas a forum is free you can come and go whenever you like - never change a running system, unless you can make money Last but not least, 50% of the questions are already answered, but many do not find documenation or search function.
Recommended Posts