[Example] Support proposal for ROCK64

[Bubba]

45 minutes ago, TonyMac32 said:

I do like the Wiki idea, however in a less ambitious sense:  We should list, with no "rose-colored glasses", exactly what the pros and cons are of each board supported, discrepancies between hardware specification and advertised capability, and recommended use cases for each board.  For those use cases, I would personally require a definition of minimum requirements and recommended requirements per use case, and those would live on their own pages.

 Yes

[gnasch]

Hi devs,

you are complaining about support nightmare. Microsoft had it much worse, with all possible shitty hardware being introduced without drivers and users expecting it to be supported. Their anwer: "Certified for Windows Vista" with a nice icon to be printed on the sales page. Conditions for the hardware vendor to include the icon was defined by Microsoft.

 

No hardware vendor will read the complaints in your forum. Armbian on the other side has quite the reputation. Do the same, define conditions for boards to be "Certified for Armbian" and push the vendors your way.

 

best,

gnasch

[pfeerick]

14 hours ago, tkaiser said:

If there would have been a rather clean 'board bring up' thread such findings would have been documented (adjusting post #1 in the respective thread), board support rating would have been adjusted and post #1 of the thread could act as something like a landing page for the specific device (moderators pushing newbies to this 'page' for example).

 

As a general lurker, and out of the loop outsider... I think this is at the heart of a lot of this discussion, and is a really good idea. Keeping that format, new thread for a new board proposal, top post giving the overview, current status, links to noteworthy posts, etc, would be a good thing. It ensures that everyone is on the same page, and knows what's going on. And if it is decided that the board should the EOL'd and shelved, it can become it's tombstone and rationale for why it was EOL'd. that's my 2c anyway

[hmartin]

6 hours ago, gnasch said:

No hardware vendor will read the complaints in your forum. Armbian on the other side has quite the reputation. Do the same, define conditions for boards to be "Certified for Armbian" and push the vendors your way.

 

The problem with these "certifications" is that then people expect everything to work perfectly. This simply isn't possible where someone can install any software with apt-get or compile it themselves. You'll say "Certified for Armbian" and then someone will say "but it doesn't work when I try to compile Firefox from source" which is obvious to anyone that there isn't enough memory, but you said "Certified for Armbian" so they assumed it could do anything.

 

It's too difficult to say "Certified for X" and then expect the user to A. have reasonable expectations, and B. read the list of limitations (e.g. minor software/hardware issues).

 

18 hours ago, tkaiser said:

Please remember situation with OPi Zero: we (some from the inner circle) were excited, added the board, improved settings like crazy. Later we discovered unfortunate Wi-Fi power management settings, then Wi-Fi here being somewhat crappy anyway. If there would have been a rather clean 'board bring up' thread such findings would have been documented (adjusting post #1 in the respective thread), board support rating would have been adjusted and post #1 of the thread could act as something like a landing page for the specific device (moderators pushing newbies to this 'page' for example).

 

I don't see any problem for people to add support for boards via git. The best solution to avoid dealing with angry users is to not provide stable/nightly builds. If you force someone to compile Armbian from source to support a board, it raises the level of effort and technical knowledge required massively. People who know enough to compile Armbian for a board from git are the kind of people you want to come here.

 

20 hours ago, tkaiser said:

I call it inner circle if only those who have access to the Private forum are allowed to join these discussions. Again: I propose a new subforum to discuss board bring up decisions. That's not meant for end users but for a developer starting with something as proposed in post #1 of this thread (that's why this thread title has the '[Example] in its name): an overview where we are, what's to expect, pros/cons. This is the most basic requirement for starting a thread. Then I looked through this thread again and found exactly one single post that was 'end user stuff', all the others were more or less focused on device discussion. Also @Kwiboojoined and IMO this is something Armbian forum should allow. Joining development efforts even if the end result is not Armbian but something else (at least that's my goal since the two years I joined now: stop people wasting their time moronically in vendor forums and let Armbian be a place of interchange and development)

 

If people misuse the 'Board Bring Up Discussion' subforum for stupid 'Hey, when is XY ready?!' threads or start to destroy such threads then posts have to be moved to somewhere else. Now that a few more people join moderator crew that shouldn't be that hard to achieve.

 

I disagree with having any private areas for board support. The reason is simple, it will keep out talented people who don't otherwise know about the hidden areas.

 

I understand you want to avoid having users pile on with "+1" support for cheap shit, but there are easy ways to handle that.

 

I think any discussion among developers about supporting a new board should be publicly visible, if not necessarily open for public comment. IMHO transparency is very important in open source. To have a closed section for making these decisions could potentially remove developers who want to support but are not part of any "inner circle"

 

I would propose that the section is open for all users, but people who abuse it by starting threads full of "+1" are blocked from posting further. If this proves to be too difficult to maintain, then posting is restricted to developers.

 

But my biggest concern is friction. It's hard enough to get developers, but if you make it harder for them to contribute, they simply won't come. Therefore we should be trying to make it as easy as possible for the next developers, who may not be known to us yet, to come and start developing for Armbian too.

 

22 hours ago, Igor said:

I thing we got the point. Not sure if we really behave exactly that way, but yes, we need to change pattern and not jumping up when boards arrive. Agree on that. It's in our own good. No doubts about that.

Well - what about community supported boards - which does not need our approval? It should be in our interest to provide opportunity for anyone who want's to bring board into Armbian and benefit from anything what build script offers ... but we have to make clear that there is no support within the build process, at first login, don't provide downloads, ... etc. One good example are balbes150 creations, which we even think to merge in once, but it's some work ...

 

I still stand by my previous statements: Developer(s) commit to supporting a board. If the developer is no longer able to support the board, then someone else takes over. If the board is already "mature" and well supported, then perhaps no one is needed, but this would need to be considered for each board depending on the status.

 

I go back to what I said earlier, I think Armbian should not build stable/nightly builds for "community supported" boards. Make it like the Android ROM scene: you provide the source for popular/well supported devices (e.g. Lineage OS "Official" devices), and other people are free to build their own image from source and post it here if they want (e.g. "Unofficial" builds). But make it more like XDA: there is a dev db listing the source/version/credits, and a big disclaimer that Armbian does not support these, WARRANTY VOID, etc.

 

I think this would actually make more people contribute. Outside of the core devices, someone actually has to build the image themselves, post it here, and maybe provide support. If it gains enough traction, then Armbian could consider officially supporting it.

 

I guess my point, and I don't make it very well, is this: make it easier for developers to contribute. Make it harder for users to download an image with half support. If someone cares enough to build an image from the source and post it here, then that shows some commitment from them.

 

You don't necessarily have to stop supporting every board a vendor sends you. If you just love getting Armbian to boot on the latest hot garbage, then go for it. Why should we stop you? But leave these changes in git. Don't provide users with images they can easily flash.

[zador.blood.stained]

34 minutes ago, hmartin said:

The problem with these "certifications" is that then people expect everything to work perfectly. This simply isn't possible where someone can install any software with apt-get or compile it themselves. You'll say "Certified for Armbian" and then someone will say "but it doesn't work when I try to compile Firefox from source" which is obvious to anyone that there isn't enough memory, but you said "Certified for Armbian" so they assumed it could do anything.

Agree. Categories like "Recommended by Armbian for building a medium level NAS", "Recommended by Armbian for building a powerful router" or "Recommended by Armbian as a low cost IoT node" would be better - still suggesting users (that decided to check the software situation before buying the board) what to choose without creating false assumptions regarding product quality and support.

Unfortunately even if we tag i.e. Orange Pi Zero as "Not a good choice for making a multimedia center" and "Not a good choice for making a wireless AP", it won't stop people from trying to use the board for exactly those use cases.

[hmartin]

3 hours ago, zador.blood.stained said:

Agree. Categories like "Recommended by Armbian for building a medium level NAS", "Recommended by Armbian for building a powerful router" or "Recommended by Armbian as a low cost IoT node" would be better - still suggesting users (that decided to check the software situation before buying the board) what to choose without creating false assumptions regarding product quality and support.

Unfortunately even if we tag i.e. Orange Pi Zero as "Not a good choice for making a multimedia center" and "Not a good choice for making a wireless AP", it won't stop people from trying to use the board for exactly those use cases.

 

I still have a problem with this. Because these devices are from China, and the manufacturer can change the board at any time. Maybe rev. 1 of the board was great, but they found a way to lower the cost (say, replace the WiFi module with a cheaper version, or replace EMMC with worse version) and rev. 2 is a pile of garbage.

 

Just look at the OpenWrt/LEDE wiki if you want to get an idea of all the stupid things companies will do to lower cost and raise profit. Reduce memory size, reduce flash size, change chipsets entirely.

 

I know this isn't very likely on these SBCs, because companies will just release a new version, but we have seen board revisions before (e.g. early Orange Pi Zero shipped without any SPI flash).

 

Saying "Certified/Recommended for X" is a trap, because as soon as the company revises the board and breaks something, people will come here and complain, so you don't want to go there. I would go so far as to say if a manufacturer releases a new revision of the board which breaks the build, then we stop supporting the board.

 

I would rather it go something like "Compatible with Orange Pi Zero Rev 1" or something which doesn't sound like a guarantee. Certified/Recommended to me says "it will work" instead of what Armbian should say, which is "it should work"

 

As we've said previously, the Orange Pi Zero should not even have stable/nightly builds, given the hardware issues. This is an example of a board I would say is only available to build from git for those who are very willing to try.

 

Edit: but this is getting pretty far from Rock64 topic... perhaps we can debate in another thread?

[tkaiser]

9 minutes ago, hmartin said:

but this is getting pretty far from Rock64 topic

 

No, this all is what I wanted to discuss here in the first place. The '[Example]' in the thread's title is there for a reason. Is Armbian willing and able to change some 'habits' or not? Is it possible that the inner circle allows other people to participate or not? Is the 'inner circle' aware how some stuff looks like from the outside (eg. taking decisions out of nowhere that should be result of a discussion process).

 

But I'm really too tired to continue...

[zador.blood.stained]

3 minutes ago, hmartin said:

I still have a problem with this. Because these devices are from China, and the manufacturer can change the board at any time. Maybe rev. 1 of the board was great, but they found a way to lower the cost (say, replace the WiFi module with a cheaper version, or replace EMMC with worse version) and rev. 2 is a pile of garbage.

 

Just look at the OpenWrt/LEDE wiki if you want to get an idea of all the stupid things companies will do to lower cost and raise profit. Reduce memory size, reduce flash size, change chipsets entirely.

They can change anything, but at the same time it's highly unlikely (I mean making significant hardware changes that may break software compatibility).

 

This problem can be clearly seen i.e. with Amlogic based TV boxes that come with Android preinstalled and software compatibility is solved by more complicated update logic (in case these boxes get software updates at all )

 

With SBCs so far I can remember those examples:

• Olimex changing Gigabit PHY on newer revisions of some Lime boards (requires differnet handling of RX/TX delays)
• FriendlyELEC and Xunlong changing voltage regulators on some boards, doesn't affect software but affects consumption and working temperatures
• Different vendors changing DRAM chips, affects only maximum DRAM frequency that can be achieved

13 minutes ago, hmartin said:

I would go so far as to say if a manufacturer releases a new revision of the board which breaks the build, then we stop supporting the board.

Agree, but, again, highly doubt that a manufacturer of a development board will shoot himself in the foot by breaking compatibility with their own software images.

 

3 minutes ago, tkaiser said:

No, this all is what I wanted to discuss here in the first place. The '[Example]' in the thread's title is there for a reason. Is Armbian willing and able to change some 'habits' or not? Is it possible that the inner circle allows other people to participate or not? Is the 'inner circle' aware how some stuff looks like from the outside (eg. taking decisions out of nowhere that should be result of a discussion process).

IMO we already reached the critical point (after the first H5 board - OPi PC2 - appeared) where adding new boards is not fun anymore, but is a waste of resources, often with no benefit to the project, so changes are to be expected.

[TonyMac32]

5 hours ago, hmartin said:

I think this would actually make more people contribute. Outside of the core devices, someone actually has to build the image themselves, post it here, and maybe provide support. If it gains enough traction, then Armbian could consider officially supporting it.

 

I guess my point, and I don't make it very well, is this: make it easier for developers to contribute. Make it harder for users to download an image with half support. If someone cares enough to build an image from the source and post it here, then that shows some commitment from them.

 

To be honest, I didn't need to talk to anyone before contributing/trying to contribute.  The Tinker Board is an excellent example of a board that has some pretty severe vendor-caused support issues in general, ticking off nearly every box from some of the earlier posts.  In this case I had one, I cloned the build system after following the proper documentation to set up a VM on my main computer, and got to work.  I then submitted pull requests on github with my changes.  I don't think a discussion about officially supporting a board is frictional to getting new devs, but I think seeing devs get dogpiled for support requests is.  That was my 100% biggest concern about getting involved, the questions I simply can't answer because I'm a low-level (firmware, micros, assembly, etc) programmer, not necessarily even a well-versed linux kernel guy (learning quickly, but there is a lot there to learn). 

 

4 hours ago, zador.blood.stained said:

Unfortunately even if we tag i.e. Orange Pi Zero as "Not a good choice for making a multimedia center" and "Not a good choice for making a wireless AP", it won't stop people from trying to use the board for exactly those use cases.

 

I'm afraid that's impossible to stop.  "Joe SBC" will invariably try to make a $8 device do the work of a $50 device.  Managing expectations is most likely more difficult than supporting hardware.  While it will upset the low-information DIY-er, I think you'll find collecting such requests/feedback into dedicated "rubbish threads" that link to the FAQ and disclaimers won't be detrimental to the project.  More moderator work.

 

For supporting new boards, as long as the user community (those with no intention to develop) understands and respects that the dev users (anyone willing to code/organize/troubleshoot/brainstorm/document have final say over supporting a board (their work, their decision), then all transparent discussion is of course the preferred method.  I do like the headstone method of having an OP of a thread contain the status/updates/issues of a board, then mark it as EOL and maybe lock the thread.  

 

@tkaiser, I like the OP in this thread, and considering improved moderation that would be a good way to get the information.  It can be done just as easily publicly as privately, getting the weigh-in of the typical dev, I just know that sometimes I have opinions of things that may offend vendors or even users, e.g. "Well if you're stupid enough to do that, I'm not going to be any help" .

 

I've been dabbling with websites and projects for almost 20 years now (I started young), the biggest problem I see with the free exchange of ideas that is the forum is burying data in clutter.  A 20 page thread will have, literally, 2 pages of useful content.  This is simply due to agreement, question, additional thought, etc.  This is why Forums are terrible archived documentation/reference sources.  It's very easy to blame it on the user when they re-pose questions, since a proper search can find the information, but often it turns into wading through pages of nonsense and unrelated tidbits to get the command, or parameter, or info you wanted.  I believe a more constructive method involves the Forum as an idea development/collaboration platform that said information is then culled from and formalized in some manner.  I would recommend something like below:

 

For a new Board, exactly as tkaiser opened the discussion, updating as new information becomes available.  Once a decision has been made by the team (I would assume a dev or two would have to more or less "adopt" the board in question for hardware support), close the thread, maybe clean it of extraneous info if mods haven't been doing that actively, and archive it as reference on a wiki, or transfer its information to a wiki and link to an archived PDF/html/whatever of the original, maintaining the conversation, but not allowing it to get buried or cause a huge amount of "pinned" topics you have to drill through to get to "live" discussions.

 

Upon officially declaring a board to be supported, have a subforum for the board (I know, huge effort organizing), then open a discussion/debugging thread for each release.  Lock that thread upon release and open a bugfixing thread, etc.  Keep the last release or two on the forum as immediate reference, archive the rest as HTML/PDF/Whatever available via a Wiki page for the board.  A "Hardware Support Status" table on a wiki would be ideal, just simple Green/Yellow/Red next to the supported bits per kernel, a simple visual aid goes a long way.  I would include an * or <- or some other mark with a note about special patching if it's needed (WiFi on Tinker Board Kernel 4.4 as an example)

"Official" Forum threads need to be consistently titled (example/proposal):

 

[Pre-Release 5.31] Hardware Feature Request

[Release Candidate 5.31] Bug Reporting

[Release 5.31] Continuing Support  

 

 

Now, boards may come about that initially seem like a great idea, check the boxes, but which later turn out to be piles of garbage.  I would recommend having a mandatory "trial period" for a board before committing to support it, no matter how perfect it might seem.  (Call it "Maybe-an"?  )  Again, personal experience here, the Tinker Board BT, SD power supply, and MAC address issues all require hacking up the kernel in a not easily supportable way or writing our own drivers.  Some of that wasn't obvious until the Rockchip/ASUS team released the source for their kernel.  In a situation like this, a discussion needs to happen concerning how to support and if/why to support moving forward.  I would personally wait another cycle for the next release and see if any more mainline work is done on the part of the vendor.  If not, we need to decide if something as ridiculous as making the board capable of rebooting properly is our responsibility/interest.  Other boards, I'm sure, are similar.

 

My apologies for rambling.

[hmartin]

2 hours ago, TonyMac32 said:

For a new Board, exactly as tkaiser opened the discussion, updating as new information becomes available.  Once a decision has been made by the team (I would assume a dev or two would have to more or less "adopt" the board in question for hardware support), close the thread, maybe clean it of extraneous info if mods haven't been doing that actively, and archive it as reference on a wiki, or transfer its information to a wiki and link to an archived PDF/html/whatever of the original, maintaining the conversation, but not allowing it to get buried or cause a huge amount of "pinned" topics you have to drill through to get to "live" discussions.

 

Upon officially declaring a board to be supported, have a subforum for the board (I know, huge effort organizing), then open a discussion/debugging thread for each release.  Lock that thread upon release and open a bugfixing thread, etc.  Keep the last release or two on the forum as immediate reference, archive the rest as HTML/PDF/Whatever available via a Wiki page for the board.  A "Hardware Support Status" table on a wiki would be ideal, just simple Green/Yellow/Red next to the supported bits per kernel, a simple visual aid goes a long way.  I would include an * or <- or some other mark with a note about special patching if it's needed (WiFi on Tinker Board Kernel 4.4 as an example)

 

Now, boards may come about that initially seem like a great idea, check the boxes, but which later turn out to be piles of garbage.  I would recommend having a mandatory "trial period" for a board before committing to support it, no matter how perfect it might seem.  (Call it "Maybe-an"?  )  Again, personal experience here, the Tinker Board BT, SD power supply, and MAC address issues all require hacking up the kernel in a not easily supportable way or writing our own drivers.  Some of that wasn't obvious until the Rockchip/ASUS team released the source for their kernel.  In a situation like this, a discussion needs to happen concerning how to support and if/why to support moving forward.  I would personally wait another cycle for the next release and see if any more mainline work is done on the part of the vendor.  If not, we need to decide if something as ridiculous as making the board capable of rebooting properly is our responsibility/interest.

 

Two things I want to bring up:

1. "Trial period" is a great idea, and this is what I was getting at: During the "trial period" nightly/stable builds are not available. Anyone wanting to test out the board during the trial period has to build an image from git themselves. This prevents devs from being mobbed by people for support when there are still lingering issues.
2. Forums suck for finding information, and no one ever uses the search feature. So, wiki software. MediaWiki is FOSS, but the syntax sucks. Confluence isn't FOSS, but it is free for Open Source projects, and they have a really excellent editor. I'm not affiliated with Atlassian in any way, I just think if you want a usable, low-friction wiki, Confluence would be a good choice. I realize since Confluence is not FOSS, this has some negative appeal in some corners. Also it's Java... 

 

 

2 hours ago, TonyMac32 said:

While it will upset the low-information DIY-er, I think you'll find collecting such requests/feedback into dedicated "rubbish threads" that link to the FAQ and disclaimers won't be detrimental to the project. 

 

We tried this already with the Orange Pi Zero. It just ended up pissing off everyone who was working on it (including me). No user seems willing to accept our explanations about performance and what is feasible. They think because the manufacturer says "WiFi" it will do the same things as their $1,200 laptop with dual-band 3x3 802.11ac.

 

Why should I sit here and take shit from people who expect perfect WiFi from a $9 SBC and pay nothing toward Armbian? Especially after we calmly explain what isn't possible, they say "well I was thinking about giving you money, but since you can't make magic unicorns out of thin air, forget it" Seriously?! Seriously?!!! No. Please go away.

[TonyMac32]

It is frustrating, it's also universal human nature.  I sold car parts while going to college, people always wanted to buy the generic parts instead of the original equipment and then got mad when they lasted 2 months instead of 5 years.  

 

Even now working with Automotive companies, sometimes I have to explain the laws of physics and why my products can't defy them.

 

So was it the need to moderate the posts, or the constant onslaught of said posts that caused the issue with the orange pi zero?  I was thinking of a garbage collection thread that would be slightly more polite than deletion, and less distracting for devs trying to answer real questions.

 

Example:. "Why can't my nanopi neo transcode 6 video streams simultaneously while cooking me breakfast?"

 

From moderator:. "post moved to "collection of insane and redundant questions.  See FAQ in OP of thread."

[hmartin]

9 hours ago, TonyMac32 said:

So was it the need to moderate the posts, or the constant onslaught of said posts that caused the issue with the orange pi zero?  I was thinking of a garbage collection thread that would be slightly more polite than deletion, and less distracting for devs trying to answer real questions.

 

In my opinion this is not limited to the Orange Pi Zero, and I am definitely not the only one to experience it. I know this is another Orange Pi Zero thread, but please see:

 

Someone answered the question asked, but with an answer the user did not want to hear and did not accept. This in my opinion is a "garbage thread" candidate. It adds nothing, and attacks the person who answered the question.

 

It would be great to trial, but I'm not confident it will stop people from just going back to the original thread and posting even more hostile responses because their previous reply was censored. Perhaps it's possible to have a moderation team who are separate from the developers?

 

Anyway, I still say that it would be good to have a separation between "official" support of a limited # of boards, and "unofficial" support where stable/nightly releases are not provided and people can build and provide "unofficial" builds from git if they are willing to deal with users like the above. This method has worked well for the Android scene, and I don't see why it can't also work well for Armbian.

 

Official boards can have forum sections dedicated to support threads. Unofficial boards have their own "unofficial" area. To avoid too much moderation work, only official area would be moderated. Unofficial area is more like "wild west"

[diaamant]

I want to say that the work of the developers of Armbian does not vanish in vain. Personally, I'm very grateful for the opportunity, thanks to your diligence, to use Orange Pi Zero as a multimedia streamer server. For a certain range of tasks, Orange Zero copes wonderfully, wi-fi I do not use. Thanks again to Igor, TKaiser and all developers supporting this project. I think that the feasibility of supporting a particular board should be based on your capabilities and the ability of boards to perform the required minimum of functions. For headless servers - this is a ethernet and work with usb devices. And I think that most people here understand that the main purpose of these devices is the Internet of things, and not a desktop PC replacement.

[zador.blood.stained]

Speaking of vendors changing hardware, we have Beelink X2 listed as a "supported" device even though if I remember correctly they changed wireless chip model in later revisions.

 

Getting back on topic, I received the Rock64 some time ago (thanks TL Lim), but current software situation to me looks like "blobs, blobs everywhere" + not a lot of low-level documentation + not a lot of mainlining progress, so I probably won't try to integrate it in Armbian for some time.

[tkaiser]

14 minutes ago, TonyMac32 said:

As a note to Mods, should this be put in the "Board Bring-up" sub-forum?

 

In my opinion NOT since this thread here contains a lot of confusing discussions that are Armbian internal and only reflect a specific situation now. I'll repost soon in new 'Board Bring Up' subforum, copy&paste the hardware part, the software support part and try to summarize dev thoughts on current situation as neutral as possible.

 

IMO it's important to keep 'Board Bring Up' threads focused on the board if we want to use this later as 'landing pages' for users (Google is pretty fast: 'armbian banana pi r2' search already lists new thread as hit N° 2)

[TonyMac32]

@Xalius If you would that would be great.  

 

@tkaiser Agreed, I just wanted to make sure nothing got shuffled under.  The banana pi R2 post was quite enlightening, I'm being quite serious I wish I'd have seen something like that for the Tinker Board, at least then I'd have been less surprised.  (The name stuck to it did it's job and I bought blindly)

[tkaiser]

On 23.6.2017 at 10:02 PM, tkaiser said:

I'll repost soon in new 'Board Bring Up' subforum, copy&paste the hardware part, the software support part and try to summarize dev thoughts on current situation as neutral as possible.

 

Given that this thread has now been moved to this subforum (which makes absolutely no sense) and how page 4 looks like...

[martinayotte]

5 hours ago, tkaiser said:

(which makes absolutely no sense) and how page 4 looks like

We should probably split that into 2 threads.

[pfeerick]

18 hours ago, martinayotte said:

We should probably split that into 2 threads.

 

Done. I had been avoiding this as I didn't want to edit the original post (in the new split thread) which was the only way I know of to contextualise the thread on this forum system. However, I've done that, and the new thread is here. I think I've pulled all the more board specific posts out, leaving this thread to focus on the proposal.

 

 

Edited June 26, 2017 by pfeerick
clarified the post which was edited