Jump to content

Nightly images?


Recommended Posts

18 hours ago, tkaiser said:
  • immediately think about no more releasing those absolutely useless 'nightlies' any more
  • prepare a board phase out process (to get rid of shitty hardware we started to support by accident, eg. Actions Semi S500 boards)
  • stop stupidly trying to convert Armbian project (good, secure and stable OS images) into a board bring up adventure (crappy and instable OS images adding more and more questionable hardware and frustrated users)

IMO this needs to be discussed separately, not in this (Banana Pi M2 Ultra) thread.

Link to comment
Share on other sites

1 minute ago, zador.blood.stained said:

IMO this needs to be discussed separately, not in this thread.


:)

Than let's find out how many useful feedback do we actually get? If usually made an image and test - almost don't use them, but I use repository.

 

Phase out process. Supported from me and S500 is the first on the list. I would only remove them from download section, where some note / link should be added - "deprecated / unsupported / .. or smth like that.

 

3rd point. Agree.

Link to comment
Share on other sites

So, as per @tkaiser's proposals we should:

  • Rethink nightly images concept
  • Prepare a list of boards that should be phased out and reasons for that (no HW samples, no vendor (BSP) development, no mainline development, no documentation, HW design flaws)

I'm also proposing

  • Prepare a list of configurations that can be phased out too (i.e. legacy kernel server images for A10/A20 boards)
Link to comment
Share on other sites

4 minutes ago, Igor said:

Than let's find out how many useful feedback do we actually get?

Well, we don't exactly ask for "useful feedback".

Most of the problems reported currently are for unsupported/development configurations and those problems are known already.

For problems reported for supported configurations - sometimes it helps, especially when logs are provided, and especially for new boards or after bumping u-boot and/or kernel versions.

Also we have assigned beta testers, so IMO we still need nightly images (unless we want to encrypt .7z files with passwords available only to beta testers :))

Link to comment
Share on other sites

7 hours ago, zador.blood.stained said:

Also we have assigned beta testers, so IMO we still need nightly images (unless we want to encrypt .7z files with passwords available only to beta testers :))

 

My apologies if I'm taking liberties by butting in here, but as a outside observer just starting to fiddle with Armbian in a more than lets-download-this-random-image fashion, but starting to look at the code and how all the scripts fit together, and using the build system, perhaps what you need is nightlies which are protected in some fashion, then beta / pre-release images. Thus the nighties don't get used by us ignorant needy users, and you can still access the nightly builds. And then when you feel the nighties are stable enough for 'public consumption' you flip it to the beta line... so three tier... nightly, beta, release. And anyone who wants a nightly image can suck it up and go download the build system and compile it themselves. Having support for vagrant takes all the argument out of "why doesn't it work on *insert-random-linux-flavour-here*" and "but I don't know how to compile it". You guys are wasting enough time as it is on these questions... so something needs to be done to put the checks and balances in.

Link to comment
Share on other sites

Mmmm... I guess I am one of the happy S500 (Roseapple Pi) Armbian users? It works fine for my purpose(s) like file sharing, torrent, Nextcloud, small Minecraft server.

 

Isn't it possible to freeze the current situation? I realize mainline is far off, but on the other hand: I am not missing it and Armbian works fine on the board. I've never had any issue with a default or self compiled image.
 

Apart from the micro-usb power and substandard USB3 transfer rates I cannot see what's wrong with it: IMHO it's not more or less crappy than some other boards that I own.... There are not many S500 boards on this planet, but I am sure there are some users like me who are happy with it. So a status quo for the next period (year or so?) is fine. Then it's becoming time to upgrade to a faster board anyway.

Link to comment
Share on other sites

I cannot complain about the price: I've received a free sample. If there's anything I can do (e.g. compile images) I am happy to help. I do have some basic knowledge, but that's it.

 

Maybe I should not complain because I got it for free, but on the other hand it works still fine for me.

Link to comment
Share on other sites

17 hours ago, zador.blood.stained said:

Prepare a list of boards that should be phased out and reasons for that (no HW samples, no vendor (BSP) development, no mainline development, no documentation, HW design flaws)

A good idea  AND in order not repeat the same bla bla bla again (but link to it), keep the decision in a little table within the documentation or such ?

Link to comment
Share on other sites

4 minutes ago, makama80 said:

I cannot complain about the price: I've received a free sample.

 

As everyone else. This Roseapple Pi fail has been called 'Lemon Pi' in the beginning (the better name BTW) and has never been sold. Shouldn't matter. Phasing out support also doesn't mean that current OS images will stop to work. It's just clearly marking a board as not supported any more and not providing kernel and u-boot updates any more via apt.armbian.com so we can try to focus back on development and not dealing with crappy hardware. Stopping support for a board or linux family (S500) simply means we don't need to waste further time on testing (new releases, architectural changes and such stuff) or support.

 

I would move those boards from download page to 'unsupported' page listing them all and keep latest working OS image in archive directory or dl.armbian.com. The board's config file should IMO be renamed from .conf to .unsupported (just to document that there was support for this board once, a new line in config file should point to online ressource where reasons are explained why support has been dropped). So in case in maybe 2 years Actions Semi's S500/S900 mainline support evolves we might easily reconsider the decision and rename .unsupported back to .conf then and adjust sources.

 

BTW: This 'unsupported' page can also be used to announce no Armbian support (yet) for new hardware (eg. crappy BPi M2 Berry) using the same mechanism to display the reasons why this device is currently unsupported. So instead of dealing with 10 new threads a month asking for 'When Armbian cure my M2 Berry?!?!11!' users might pro-actively find the answer if they search for 'Armbian M2 Berry' already (partially kidding -- @Igorwould you mind trashing xforum.armbian.com since it pollutes google hits a lot?)

Link to comment
Share on other sites

10 hours ago, pfeerick said:

And then when you feel the nighties are stable enough for 'public consumption' you flip it to the beta line... so three tier... nightly, beta, release.

 

Board bring up is the less problematic part compared to board maintainance/updates. I still think Armbian needs a testing/beta branch so surprises like broken networking after just an usual 'apt upgrade' on a specific device (I would like to kick out of Armbian rather sooner than later) can be avoided.

 

But I don't see us moving into this direction at all. Quite the opposite.

 

 

Link to comment
Share on other sites

3 hours ago, tkaiser said:

This is the try to play through some sort of an approval process

WTF, you need a tool and responsible people a so called 'group' or team.

The number must be uneven or there is a leader with the power of 'two-votes-in-one' in case the number is even.

 

  1. So you introduce.
  2. discuss.
  3. finalize discussion - close it.
  4. decide.

Done

Edited by Tido
finished my sentence
Link to comment
Share on other sites

28 minutes ago, Tido said:

WTF, you need a tool and responsible people a so called 'group' or team.

The number must be uneven or there is a leader with the power of 'two-votes-in-one' in case the number is even.

 

  1. So you introduce.
  2. discuss.
  3. finalize discussion - close it.
  4. decide.

Done

 

 

I don't really think anyone disagrees with you. As I said in my previous post, this isn't a popularity contest of which boards are most popular (because that would probably end up being the cheapest, crappiest boards) but rather what Armbian developers are able to reasonably support.

 

So here we are having the discussion. It seems like people are receiving dev samples for testing. If they decide to put in the effort to add support to Armbian, then the board will be supported.


If later on, no one is taking care of the board and things are breaking, we can have a discussion to remove support.

Link to comment
Share on other sites

23 minutes ago, Tido said:

WTF, you need a tool and responsible people a so called 'group' or team.

 

'Armbian' is not a (commercial) entity. Just think about it. It's all about motivation.

 

We could try to revert back to 'Igor's image' but I don't think this works at that scale. It's about volunteers working together all of them with their own motivation and reasons (one example comes to my mind: @chradevand his product). Sometimes it seems things improve more if less people are involved and sometimes the opposite. It's difficult.

 

It's difficult for various reasons and what I want to address here is the problem that 'board bring up' is fun stuff while 'board maintainance' (especially with shitty devices or shitty user bases) is time consuming and also the reason why a project like Armbian might fail in the end (doing only stupid support jobs in the forum, no more fun developing stuff).

 

There's no one except Igor who could define rules (and if Igor does it would affect motivation of others for sure). So this here is just the try to discuss a process that is able to be accepted by as much devs and supporters as possible. Important note: devs and supporters are currently more or less the same people. Think about. 'We' deal with a motivation problem currently.

Link to comment
Share on other sites

You probably have to start at a higher altitude: What does armbian want to be ?

 

Main page says:

  • Lightweight Debian Jessie or Ubuntu Xenial based Linux distribution.
  • Make boot image from sources with our advanced but easy-to-use tool chain.
  • Become a part of our vibrant community, contribute ideas and have fun!

Which means to me open-end, but as resources are not endless and one huge problem of every OSS-Project is to attract new developer and so MythBuntu died.

Not only is some kind of guidance missing, there is no community manager either.

 

So, does your thread address the somewhere in flight instead of pre-flight checks?

Link to comment
Share on other sites

13 minutes ago, Tido said:

So, does your thread address the somewhere in flight instead of pre-flight checks?

 

"If later on, no one is taking care of the board and things are breaking, we can have a discussion to remove support."

 

Does this not address "in flight" ?

 

If the board is added and builds are failing, or people are complaining that things are broken, and no developer is fixing it, then we drop support.

Link to comment
Share on other sites

Rules or protocols saves time and helps us to cope with problems regardless if this project is powered by this or that motivation. Well, we can't hire people, since our budget is on "let's go for a beer level", but we have to be more creative. We can talk about and I am sure, we have enough smart people around to come up and go with the plan.

 

  • nightly images. If they are moved "somewhere back", we solved the other half of the problem. We already added lot's of warnings and we can add them more to the download page. Do we really need nightly images? If not, let's cut them down to minimum and focus to beta images, images build a week before major release? This way the testing protocol get's somehow simplified - there will be no question "where is the image which i need to test" -> "test last image from download", little less confusions, than using nightly images. 
  • support. If we already dropped the idea of commercial support, we could at least limit it to validated users / images and provide commercial support - as option. Since this is not mandatory it's more like a yet another donate button, but can help funding the project. Some cash will always be needed. This way we also cut off supporting 3rd party builders, which they have to take care of support on their own.
  • config files and download page for unsupported / old creations. There were few ideas exposed, but I have some doubts on implementation. Build script .unsupported is good, but for download page I am not sure. Two examples - I would like to add new board to download page, we want users to try out and to see that we started to work on, but we don't provide end user support and on the other end we have some exotic board, which we want to move out from download page. We have one on without support and one off without support. This way?

 

Quote

doing only stupid support jobs in the forum, no more fun developing stuff


We need to limit support. Agree, but how not to make damage?

 

My personal involvements are going above fun stuff sometimes - bigger the project, more comm and more coordinating. This can be fun, but it's usually dealing with people, where no schematics is available :D 

 

Just saying.

 

Quote

There's no one except Igor who could define rules

 

I can take veto, where and if needed, but I would prefer not to play part in every decision process, which is/will be going on. If core decision / active group expands more, than we might need to think about changing rules again. So far - in a small group - exposing a problem, talking about and making consensus is the way to go. IMHO Areas, where we all know what to do, we anyway do and no talk is needed. Here, probably we don't have unified standpoints and we shall clear them out, before any action is taken and resources wasted. Yes.
 

Quote

 but as resources are not endless and one huge problem of every OSS-Project is to attract new developer and so MythBuntu died

 

I understand your concern, but usually there are many reasons involved. In any case, we are developing and attracting people, but the speed of overall development and users is faster / bigger.

Link to comment
Share on other sites

13 minutes ago, Igor said:

.unsupported

Will you open a section in the forum '.unsupported' - so there is a place where those Threads can be put as well ?

 


What about this: https://forum.armbian.com/index.php?/topic/4378-nightly-images/&do=findComment&comment=32670

 

Template for evaluation (like TK just did) can be like a readme on github?

 

With preparation above we had a starting point.

Link to comment
Share on other sites

On 28. 5. 2017 at 8:52 PM, zador.blood.stained said:

Prepare a list of boards that should be phased out and reasons for that (no HW samples, no vendor (BSP) development, no mainline development, no documentation, HW design flaws)


My proposal for removal:

https://www.armbian.com/orange-pi-mini/ (limited edition, no samples, never sold)

https://www.armbian.com/orange-pi/ (limited edition, no samples, never sold)

https://www.armbian.com/lemaker-guitar/ (no development for some time, design flaws, no mainline)

https://www.armbian.com/roseapple-pi/ (no development for some time, design flaws, no mainline, never sold)

Link to comment
Share on other sites

12 hours ago, Tido said:

Will you open a section in the forum '.unsupported' - so there is a place where those Threads can be put as well ?


What about just removing unsupported board(s) from forum description & closing new topics with "no more active support"? I don't expect much if any activity on those boards.

 

If no objections pops out, those four will get last update with 5.30 and will be moved our from armbian mainline support.

Link to comment
Share on other sites

14 hours ago, Igor said:

config files and download page for unsupported / old creations. There were few ideas exposed, but I have some doubts on implementation. Build script .unsupported is good, but for download page I am not sure. Two examples - I would like to add new board to download page, we want users to try out and to see that we started to work on, but we don't provide end user support and on the other end we have some exotic board, which we want to move out from download page. We have one on without support and one off without support. This way?

 

To elaborate on this only for now. My main concern is 'communicating clearly to end users what to expect'. On our download page only devices should be listed that receive 100% full support.

 

All other devices should be moved to completely separated 'Unsupported' page. The devices listed here fall into the following 3 categories:

 

  • 'Phased out': support has been removed for documented reasons (applies to those A20 Orange Pis and the two S500 devices now). Latest OS images are still accessible but behind a nag screen where people have to accept that support requests are ignored and support threads even deleted without replying (at least they clicked 'I agree' once).
  • 'Work in Progress': these are the boards we're currently working on but that are not ready, where every question 'why not worky?!' is just useless and a waste of time. Preliminary or even nightly OS images are accessible but behind a nag screen where people have to accept that support requests are ignored and support threads even deleted without replying (at least they clicked 'I agree' once, we should add the 'nightly' motd disclaimer to .wip boards too)
  • 'Not supported': these are the boards people would think will be supported by Armbian (soon) but won't. This is the process of a short discussion in development forum which ends up in a file below https://github.com/armbian/documentation and a link to the initial thread. This page clearly documents the reasons why there's no support for the board (not worth the efforts since support nightmare due to crappy Micro USB, vendor not releasing complete schematic, only crappy BSP available and so on

 

The last category is the most important one for me since it allows us to document decisions and maybe even to change vendor behaviour (providing schematics earlier, becoming more cooperative).

 

How do we do today? A hardware vendor sends out a bunch of dev samples and we start like brain damaged retards immediately to work on getting all these boards supported in Armbian even if it makes no sense at all. For example OPi Zero Plus H5. For Xunlong it makes no difference to feed the reel with H3 or H5 SoCs and to push out boards with a slight price difference all running a 32-bit Android they already have from Allwinner. For whatever reasons (desktop replacement the only possible on this design) people buy these boards. But running a 64-bit distro especially with X on this limited device is just stupid with only 512 MB DRAM. So at least three reasons against: Armbian support would be stupid, Micro USB and high expectations combined with unreliable powering create a support nightmare. No thanks.

 

Since while supporting such devices might be absolutely wrong but board bring up could be fun we could treat these devices simply as 'WiP forever'. They just remain on the unsupported page marked 'Work in Progress' so software can be improved, support requests happily ignored and once something changes we could rethink and move the board to supported section (BTW: Having download statistics from dl.armbian.com as well as torrent tracking would be great to help with decisions regarding user acceptance)

 

To me it's really important to list devices we'll most probably never support on a page just to document this clearly, list requirements (so vendors looking this up could improve eg. providing schematics earlier) and maybe even educate users (what to look for prior to an impulse buy). We'll soon get more H3 boards with H5 instead (since it's that easy to exchange the SoC) and I really don't see why we should automatically support them since software support for H3 and H5 is somewhat different and higher memory requirements of a 64-bit distro render use cases useless.

 

Also we face SBC customers who were tricked into believing they buy 'upgrades'. This applies to eg. 'Cubieboard 6' (Actions Semi S500 --> no way at least for now) or the so called 'BPi R2' many users believe would be just an enhanced R1 version eliminating the many design flaws of R1 and being somewhat compatible. But it's a whole different product using a new SoC from a manufacturer that started just recently to become somewhat open (MTK guys now even send patches upstream so maybe in 2018 we can talk about R2 again then running with mainline only). But R2 customers have not the slightest idea how crappy software situation for R1 was in the beginning and that unlike R1 they can't expect any improvements with R2 since there's no community around this time. This needs to be clearly documented so people might get actual results when doing a web search for 'bpi r2 armbian'.

Link to comment
Share on other sites

 

Quote

WIP - where people have to accept that support requests are ignored and support threads even deleted

This is not feasible eg. tinker board, there are nightly images and people develop on it.

 

Quote

This page clearly documents the reasons why there's no support for the board

A good idea, what columns, section or titles shall this template (SBC crap yard) carry?
ie: missing documentation/schematics, problematic HW design, Kernel below 4.x as of 'date', Chip Manufacturer no Mainstream support, postponed ?


LOL: and we start like brain damaged retards :o

 

Not to go into details like sunxi, but this table with green, yellow, red .. I like that;  armbian has "Known issues" below download-buttons.

Which kind of represent green, yellow, red, right?

Can a color be used to somehow reflect whether this known issues are 'big' or minor ?

 

Quote

BTW: Having download statistics from dl.armbian.com as well as torrent tracking would be great to help with decisions regarding user acceptance

If it was me, I already had a reporting setup that tells the device name, armbian version and uptime.
Via armbian-config it can be switched off.


Will we now begin with frist steps of the agreed points ?

Template's we need:

  1. SBC introduction
  2. SBC crap yard
  3. else?

 

Link to comment
Share on other sites

Yeah, I like it.

What do you want to express to the reader

-- Function  versus  Support ?

work in progress / beta / preview / incoming: limited support

or in other words what do we want to say or make the reader to understand?

 

I come back with the traffic light or color green, yellow, red.  Could there be a 2-3pixel wide green, yellow, red, border around the section   or place a traffic light inside the box.

So without reading: aha, it is not green.

 

Link to comment
Share on other sites

22 hours ago, tkaiser said:

Since while supporting such devices might be absolutely wrong but board bring up could be fun we could treat these devices simply as 'WiP forever'.


What about having yet another section with "Limited support". This means they are still getting updates, but no end user support exists for those?

"No support" section will need some extra work for now and for the future - if we want to have it solved in same design as those boards. If only a link to some .md or forum post, than this is no problem.

Link to comment
Share on other sites

1 hour ago, Igor said:

Disaster. Why not start to look at this from the outside?

 

If we want to prevent people using this and that OS image that's not ready yet why do these appear at the top of this page?

 

I was talking about TWO separate pages to clearly communicate what's supported and what not.

 

12 hours ago, Tido said:

 

We don't need this. We neither need tables nor colors, it's about one page collecting all those devices that do NOT receive full support (and another one that looks like the download page from days ago that holds the devices that are fully supported). On the first page all that's needed is a simple link to a text file created on github which contains a link to the original discussion thread in developer forum. If people are not able to read through 4 to 5 lines of text they are retards anyway and you can't help them any more.

Link to comment
Share on other sites

A disaster is something else, this is WIP !

work in progress, alpha's, beta's: expect problems You have to resolve

deprecated, no more development and support

current stable builds (this says enough)

 

34 minutes ago, tkaiser said:

If we want to prevent people using this and that OS image that's not ready yet why do these appear at the top of this page?

I was talking about TWO separate pages to clearly communicate what's supported and what not.

 

I also thought about it, that it is not so good to have it on top, I also thought about collapse, but TWO pages seem a better way to me too.

Where do you want to place the link to the WIP and Deprecated site ?

 

-- Function  versus  Support ?

work in progress / beta / preview: limited support

TK what do you think about that, I mean armbian does not support everything (full support (as you say)) on SBCs ie. GPU VPU HDMI-CEC, Audio and so on,  if not you,  but many users are looking for it.

Should we have a section in armbin-Docs where we highlight the limitations of the OS  and where to find options, like sunxi and such?

 

Edited by Tido
Quote box, was on the wrong place
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines