Jump to content

Nightly images?


Recommended Posts

I apologize for intrusion, but here are some ideas:

 

* You may like to open ONLY COMMUNITY SUPPORT forums for not officially supported boards (old or new) and owners of these boards can help each other - instead of deleting, just move the topic there.

 

* Low end boards and X : It is not always a desktop replacement. If the board has HDMI or other display output, but not enough memory, one can use it as a video looper/player or an IoT device with touch support. No more office, no more mail etc...

 

Link to comment
Share on other sites

Search Before Posting!

On 08.06.2017 at 9:59 PM, Igor said:

Do we really need nightly images?

We don't need them, though our beta testers most likely are using them (as expected) and other people are using them for everything including production usage and making 3rd party images based on them.

 

On 08.06.2017 at 9:59 PM, Igor said:

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. 

To conserve resources we could rebuild packages daily but rebuild nightly images only once a week, and we could significantly cut down the number of nightlies.

 

On 08.06.2017 at 9:59 PM, Igor said:

This way we also cut off supporting 3rd party builders, which they have to take care of support on their own.

We can leave this part as is - third parties are fully responsible for providing support to their users, but we can accept requests like adding options to kernel configuration since this will be beneficial to Armbian users too.

 

On 08.06.2017 at 9:59 PM, 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.

I'm in favor of separating all images in groups: stable, WIP (with notes why this hardware is not stable yet), phased out (with notes when this hardware was discontinued and why). I'm not sure if grid is the best way to solve this, I would prefer a table list with one board in a row)

And creating separate lists for each group IMO is the best way to go, adding switches like "show WIP" and "show obsolete" and mixing stable boards with everything else will create unneeded confusion and complication.

 

On 09.06.2017 at 0:43 PM, tkaiser said:

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'.

I am against adding any info for the hardware that we don't plan to support anytime soon. Who will maintain those lists and how? Who will spend time to search through kernel sources, BSP packages and schematics to find all the "red flags" for possible "disaster boards" (especially since some things are subjective)?

 

20 hours ago, Tido said:

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.

Some board makers will do anything to promote and sell their boards, and you won't be able to make an analyitcs/statistics system protected from cheating.

Link to comment
Share on other sites

Quote

To conserve resources we could rebuild packages daily but rebuild nightly images only once a week, and we could significantly cut down the number of nightlies.


OK, once per week and interessant only. I'll clear them out during this week. Will also push 5.30 updated images out.

 

Quote

We can leave this part as is - third parties are fully responsible for providing support to their users, but we can accept requests like adding options to kernel configuration since this will be beneficial to Armbian users too.

 

Fine with me.

 

Quote

And creating separate lists for each group IMO is the best way to go, adding switches like "show WIP" and "show obsolete" and mixing stable boards with everything else will create unneeded confusion and complication.

 

I made a third and I hope last adjustements. Now each one has it's own page, accessible from menu, below "Download". In /download, we only have stable, nothing else. I was only thinking to add links from there to WIP and deprecated section? Also some more explanation needs to be added to WIP and deprecated.

 

Quote

I am against adding any info for the hardware that we don't plan to support anytime soon. Who will maintain those lists and how?

 

Specific is to big waste of time for us ... no, perhaps some general infomation that users will understand get some ideas / hints, why we don't support just every board on the market and that shitty boards exits and there is nothing much we can do about.

Link to comment
Share on other sites

7 hours ago, Igor said:

perhaps some general infomation that users will get some idea / hints, why we don't support just every board on the market and that shitty boards exist and there is nothing we can do about

TK already wrote some stuff about this in the previous postings - shall a make a little collection :)

Link to comment
Share on other sites

On 10.6.2017 at 5:48 PM, zador.blood.stained said:

I am against adding any info for the hardware that we don't plan to support anytime soon. Who will maintain those lists and how? Who will spend time to search through kernel sources, BSP packages and schematics to find all the "red flags" for possible "disaster boards" (especially since some things are subjective)?

 

Ok: how to define a process to decide whether we want to support a new device or not?

 

Current situation: a hardware vendor sends out dev samples worth 50 bucks and we waste our time worth tens of thousands of bucks on these devices without even starting a discussion whether it's worth the efforts or not. Or someone with commit rights simply adds a board since... no idea. That sucks.

 

Can we agree on a process like https://forum.armbian.com/index.php?/topic/4451-example-support-proposal-for-rock64/ and if not what are your ideas?

 

Current situation: We support way too much boards to deal with, we scare away potential contributors (IMO due to lack of clear communication and the feeling for 'externals' there's an 'inner circle' or something like that) and we always just talk and talk and talk but nothing happens. This also sucks.

 

Using Armbian and having to fear an 'apt upgrade' really sucks. There was a lot of babbling about what has to happen prior to releasing major releases ('team testers' and stuff) but... today we're on 5.30 for whatever reasons (maybe I just missed discussion, call for testers and announcement?)

 

If we're not able to test through all those boards we claim to support why do we provide upgrades that break the most important things? This is not the first time and if we don't start to think about why we update all the time without most basic testing more of these situations will follow. If we don't have the resources to test through every f*cking u-boot update every two months everywhere why do we roll out these updates? We have devices where u-boot is from 2013 or maybe even older and that's just fine. Using 'latest and greatest' without even testing is quite the opposite of the distros we put on top of this (horribly outdated AKA stable Debian variants). 

 

This is how I would sum up Armbian engagement today: https://github.com/armbian/build/issues/512#issuecomment-269476270

 

(sorry for this rant but I consider current situation extremely discouraging)

 

Link to comment
Share on other sites

19 minutes ago, tkaiser said:

Can we agree on a process like https://forum.armbian.com/index.php?/topic/4451-example-support-proposal-for-rock64/ and if not what are your ideas?


I support the idea of protocol - if this is meant that way - but honestly I haven't been able to catch up - only quick scan. 

 

44 minutes ago, tkaiser said:

and we always just talk and talk and talk but nothing happens.


My impression is different. A lot has been done, but also a lot can be done. The question is, what do we want and can we afford? Some things were made wrong, but in general we don't waste that much time either (if we rule out supporting Orange Pi zero wireless, similar pointless cases and perhaps support in general). We are already at a limit of what we can do with resources we have and that is one of the primary reasons, why all things weren't done yet. Even we cut off half of the board support ...


There is more than just clear comm and few rules to achieve greatness.

20 tools, each covering one aspect of a community or group by Pieter Hintjens:

 

Quote

Strong mission -- the stated reason for the group's existence
Free entry -- how easy it is for people to join the group
Transparency -- how openly and publicly decisions are made
Free contributors -- how far people are paid to contribute
Full remixability -- how far contributors can remix each others' work
Strong protocols -- how well the rules are written
Fair authority -- how well the rules are enforced
Non-tribalism -- how far the group claims to own its participants
Self-organization -- how far individuals can assign their own tasks
Tolerance -- how the group embraces conflicts
Measurable success -- how well the group can measure its progress
High scoring -- how the group rewards its participants
Decentralization -- how widely the group is spread out
Free workspaces -- how easy it is to create new projects
Smooth learning -- how easy it is to get started and keep learning
Regular structure -- how regular and predictable the overall structure is
Positivity -- how far the group is driven by positive goals
Sense of humor -- how seriously the group takes itself
Minimalism -- how much excess work the group does
Sane funding -- how the group survives economically


 

21 minutes ago, tkaiser said:

We support way too much boards to deal with, we scare away potential contributors

 

It could have impact or not. Perhaps our way of doing is too good, strict or perfect? It depend from which perspective do we look. I know that current scenario of engagement is not ideal and needs change if we don't want to get crazy and to level things up. This takes time and energy and we are going from one large project to another without stop. I see that more problematic than we failed to implement some protocol or feature.

 

Quote

Using Armbian and having to fear an 'apt upgrade' really sucks. There was a lot of babbling about what has to happen prior to releasing major releases ('team testers' and stuff) but... today we're on 5.30 for whatever reasons (maybe I just missed discussion, call for testers and announcement?)


Actually we did testings, but this kind of issue could be found only if all boards were tested. We are not on that level, even 5 people (we have 8 people in total for testing from last call, but theirs board diversity is another problem) responded to assigned tasks. Testing protocol was not fixed yet, since we need few real world experiences, before we know what is important and to wrote all this down.

 

We need to divide stable and latest builds, freeze non critical stuff (u-boot), ... yes. 

I'll fix recent upgrade problems, when I'll fully understand them, but first I would need to get some sleep and recharge. I removed failed u-boot from repo but images for bananas are failed too.

Link to comment
Share on other sites

Put up a "bounty" have those who wish to have a board supported or a feature added, have them put up some funds, plus the boards.

I donated because I find the process entertaining, gives my brain something to do, but if I had a project I could see paying for a feature or 2.

 

You guys need to offer more "fun", ...more projects which will draw in programmers and end users.

I see a bunch of folks hoping to do projects that are really pushing these boards, how about some IOT projects, Magic mirror, leggo bots an so on.

 

Igor's menu is a good start for those just starting out (reminds of Doug's menu for IBM DOS).

 Maybe offer access to the scripts, so folks can alter / add to it.

Link to comment
Share on other sites

12 hours ago, Igor said:

I support the idea of protocol - if this is meant that way - but honestly I haven't been able to catch up - only quick scan. 

 

Ok, I'm now only answering to the question 'board support decision'. We support already too much boards, a lot has changed in 2016 and in 2017 again and we just ignore this until Armbian project will collapse.

 

Who decides whether a new board will be supported? Is it you? Is it 'us'? If the latter who are 'we'? Is it a random hardware vendor just shipping some dev samples and trusting in 'Armbian morons' doing his job for free?

 

We're acting like the latter today.

 

We work on boards for which ZERO Armbian use cases exist (Orange Pi Zero Plus 2 H5 or however this unbelievable f*cking stupid name is written exactly, at least it's absolutely STUPID to bring Armbian to this board since the only possible use case is 'Desktop Linux' since this board unfortunately has HDMI but just 512MB DRAM which is simply not enough for a 64-bit Linux running a Desktop environment, for H5 we've only mainline kernel since H5 BSP is such an INSANE crap so not even video acceleration will work here. It's STUPID to bring Armbian to this device but we do it).

 

We work on boards that are not even supported by the hardware vendor. For example this BPi M2 Ultra thing, those SinoVoip folks only provide incorrect information (see DRAM timings, they write 733MHz, use 648 MHz but the SoC's memory controller supported 576MHz maximum --> reference, reference, reference look at the 'Technische Daten' PDF there, those irresponsible morons advertise this board with CPU @ 1.5GHz, DRAM at 733 MHz, Mali GPU at 500 MHz while in reality all numbers are way lower. Do we want later 'bug reports' that tell us 'Great Banana Pi M2 Ultra is able to run at 1500 MHz, Armbian is broken since allows only 1200 MHz'?!), those morons as usual do not even care about schematics being correct ('In schematic you can see two uart2 ports.'), they never release schematics timely, they're known to send out defective developer samples and they're either too stupid or too ignorant to get that this is a real problem.

 

And what do we do? We ignore that and play morons happily working on bringing support to their boards so they are ensured their behaviour is totally OK and nothing needs to be changed. We behave like the greater morons than them since they succeed with their irresponsible behaviour since some community idiots are doing their job for free even if they actively hinder us all the time (incorrect information/schematics, defective board samples, no changelog for hardware changes).

 

That's the whole purpose of a 'board bring up' DISCUSSION (that was the Rock64 example). Weighing pros/cons, benefits for users and developers, documenting what's missing (eg. incorrect information/schematics -- maybe even the most stupid board maker will get the idea he has to improve in this area if all his boards are rejected for the same simple reason: him behaving like an irresponsible asshole)

 

Board bring up is fun, board support is boring but more important depending on how we look at the Armbian project (playground vs. providing a distro able to run serious stuff). We have to reduce the number of supported boards but instead we add more and more. Unless such discussions start all babbling is useless anyway (eg. whether to differentiate .playground boards from .wip boards that will at least get support eventually since we came to the conclusion that it's worth the efforts in the beginning).

Link to comment
Share on other sites

12 hours ago, Igor said:

Actually we did testings, but this kind of issue could be found only if all boards were tested

 

In other words: You think this has to happen: 

I'm out for now. Or maybe I just missed 5.30 release discussion? Is there a(nother) private subforum where open issues and needed testing efforts were discussed before 'we' (or you?) decided to push the button and roll out just another update that bricked devices (servers without network connectivity any more can be considered bricked IMO)?

Link to comment
Share on other sites

15 hours ago, Igor said:

20 tools, each covering one aspect of a community or group by Pieter Hintjens:

Quote

Strong mission -- the stated reason for the group's existence
Free entry -- how easy it is for people to join the group
Transparency -- how openly and publicly decisions are made
Free contributors -- how far people are paid to contribute
Full remixability -- how far contributors can remix each others' work
Strong protocols -- how well the rules are written
Fair authority -- how well the rules are enforced
Non-tribalism -- how far the group claims to own its participants
Self-organization -- how far individuals can assign their own tasks
Tolerance -- how the group embraces conflicts
Measurable success -- how well the group can measure its progress
High scoring -- how the group rewards its participants
Decentralization -- how widely the group is spread out
Free workspaces -- how easy it is to create new projects
Smooth learning -- how easy it is to get started and keep learning
Regular structure -- how regular and predictable the overall structure is
Positivity -- how far the group is driven by positive goals
Sense of humor -- how seriously the group takes itself
Minimalism -- how much excess work the group does
Sane funding -- how the group survives economically

 

 

Thank you for this... This is a quite valuable resource...

Link to comment
Share on other sites

IMHO. For me 3 boards are the minimum to be supported : desktop, NAS - LAMP and IoT server. 

And maybe 2 options for each purpose : cheap and optimal. 

A sane portfolio of 6 maker and professional boards with top notch OS. 

But, I'm only a moron user and sometimes tester. 

But guys at the end you have to know you are amazing, including the rude comments, the moron questions and everything. 

Link to comment
Share on other sites

Firstly, I wanna thank to the hole 'team armbian' for spending so much effort in this project. You did, and still do a great job. The reason why I moved from RPi to an OPi zero is Armbian. When I noticed that there is a Linux which is state of the art and a community which gives so much support, I saw no reason to spend more time playing around with my RPis.

I follow this thread for a while when it started arround nightly images and moved now to a more basic discussion about armbian and what it should be. My strenghts are definitely not in software engineering nor software support (if you ever have questions about chemistry or biology, let me know cause thats things I understand :P).  But I saw a lot of projects failing cause of people loss the spirit spending their time to explain the same questions again and again and I don't want to see that armbian also fails. 

Support via Forum is important and let the community grown but it needs a lot of time.  Questions like: Why does "random function" does not work on my "random board" are annoying. Maybe some additional information to each board and some basic question rules can help to avoid this. 

 

Additional Information:

A lot of customers are driven by the specs that the vendor gives what should be possible with this board. Having a wiki-page to each supported SBC that shows if the vendor claimed features are supported by armbian or not or if there is some known projects where someone works on this feature could help to avoid people from buying false boards. 

Also if the community brings something (e.g kodi etc.) to work on a specific board, a small how-to could be written there to help less experienced users start their project. I know this needs some time especially due to the fact that a lot of boards are supported but once the basics are there, you can push people to read the wiki before asking stupid questions.

Basic Question Rules:

Define some basic forum rules for what is important (e.g. board type, armbian version, what was tried, logs of errors etc. )before someone can give support should also shorten your time for support. Something like a "how-to ask questions so that you improve your chance to get an answer".  So that a moderator can close every question that doesn't follow this rules.

 

For the roll-out of armbian 5.30 which leads in a brick of the network connectivity on some boards keep in mind that even big players like microsoft broke their DHCP service on windows 10 by an update :D. It should not happen but it can. I'm thinking of whenever a major update is planed an announcement thread should be pinned to each subforum that  testers are needed to check if everything works properly. If you get the respond that it works, the update can be rolled out for the boards you get these  test replies. And if no owner of a specific board feels responsible to do this tests, I dont's see any reason why the development team should feel responible to improve armbian for this board. 

 

Link to comment
Share on other sites

IMHO a release scheduled is always a good practice. I know you guys want to minimize releases because of the number of builds (your time and CPU time). But if you want to well define things like the above, this can be one of it.

 

Something like (i.e. for downloadable images)

Armbian releases come out every first monday of a month.

Armbian beta relases come out 1 week before that.

 

Plus a better detailed changelog is a must. Forum searches or the one on the documentation are not sufficient. Just as an example, I wrote lots of install scripts in v5.25 and some are failed in v5.27 I downloaded last week. I don't know what changed in motd modification for example, I have to fish it.

 

Link to comment
Share on other sites

On 29/05/2017 at 4:16 PM, tkaiser said:

 

 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.

 

Network manager breaks and user has no control to hardware because the user interface use notifications from the software layer below. That is the same shitty redhat/gnome software as pulseaudio and gnome3. Use wicd, alsa and gstreamer. Chromium is better than Iceweasel that did not play audio with alsa and current Firefox uses only pulseaudio. Iceweasel plays youtube videos so slow that it is really garbage. Updated Armbian jessie Xfce to Debian testing Xfce where is Chromium and Sunvell T95Z Plus works much better now.  I have used many years Debian testing Xfce in many PCs and it can be stable, fast and easy to use rolling release os for arm64 users too. 

 

Link to comment
Share on other sites

Conclusions:
 

- nightly kernel and BSP building yes, nightly images once per week

- focus more to provide simpler way for new developers to get in

- nightly images should be carefully picked to provide best "price performance" ratio

 

and another proposed actions:

 

- moving another three boards (Lamobo R1 / Cubieboard 1 / Lime A10) into deprecated sessions. All those boards get one last update with last known working configuration and frozen kernel packages

 

Quote

- I still think Armbian needs a testing/beta branch so surprises like broken networking after just an usual 'apt upgrade' on a specific device

- IMHO a release scheduled is always a good practice

- Is there a(nother) private subforum where open issues and needed testing efforts were discussed before 'we' (or you?) decided to push the button and roll out just another update that bricked devices (servers without network connectivity any more can be considered bricked IMO)?

- It should not happen but it can. I'm thinking of whenever a major update is planed an announcement thread should be pinned to each subforum that  testers are needed to check if everything works properly. 

 

This a current project overview, which we try to follow. Is this time span perfectly o.k. ? Not sure. We will need to adjust it in the future, but it’s something to go with and stick to it, when and if we agree:

 

UPCOMING MILESTONES

Milestone               Responsible Person Due On
Feature developement                   --- Due in 81 Days
Feature freeze                         --- Due in 90 Days
Beta testing and bug fixing            --- Due in 130 Days
Writing release documentation          --- Due in 142 Days
Launch                                 --- Due in 149 Days

Withing project management we manage to establish fully operating testing system – a person get’s an email, when and what to test – his report is clicking few check boxes + adding a note when necessarily. Technology was tested twice and it works, methodology needs broad discussion. Project manager is the one, who has overview and drive (volunteer) developers to fix this and that. In reality this means I was driving myself and Michael was assisting in this and solving problems which are out of my league. Since we were also testers, most of bugs were saved already on the way ...
 

Quote

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

 

Project management is yet another full time position, which waits to be filled developed and filled in. We deliberately use this hidden, because I was not sure if it’s the right way to go, because not everybody needs to  be involved in everything and because not finished products are better to hide. Check email.

 

Until there is no somebody who will take a full lead on this, I am moving it forward with (my) highest possible speed. Well, in fact it's already we. Tido is helping in this beta trial process.

 

Quote

You may like to open ONLY COMMUNITY SUPPORT forums for not officially supported boards (old or new) and owners of these boards can help each other - instead of deleting, just move the topic there.

 

We can add text to forum description, which board are officially supported – I know people will still fail to see.

 

Quote

IMHO. For me 3 boards are the minimum to be supported : desktop, NAS - LAMP and IoT server. 

 

Yes. This is at least much simpler to support and is to consider.
 

Quote

But I saw a lot of projects failing cause of people loss the spirit spending their time to explain the same questions again and again and I don't want to see that armbian also fails. 


Yeah. At least we are highly motivated to end / limit at best as possible.
 

Quote

Questions like: Why does "random function" does not work on my "random board" are annoying. Maybe some additional information to each board and some basic question rules can help to avoid this. 

 

We would certainly need more moderators, which would take care of such questions appropriately. Technical knowledge about those boards is not a requirements. If @chwe wants to take care of general moderator duties, he is one click away :)
 

Quote

Having a wiki-page to each supported SBC that shows if the vendor claimed features are supported by armbian or not or if there is some known projects where someone works on this feature could help to avoid people from buying false boards. 


This is fine, but very hard to maintain.

 

The rest elsewhere. This one is already off topic.

Link to comment
Share on other sites

4 hours ago, Igor said:

This a current project overview, which we try to follow. Is this time span perfectly o.k. ? Not sure. We will need to adjust it in the future, but it’s something to go with and stick to it, when and if we agree:

 

UPCOMING MILESTONES


Milestone               Responsible Person Due On
Feature developement                   --- Due in 81 Days
Feature freeze                         --- Due in 90 Days
Beta testing and bug fixing            --- Due in 130 Days
Writing release documentation          --- Due in 142 Days
Launch                                 --- Due in 149 Days

I would prefer to adjust milestones to kernel and u-boot releases so we can migrate with the mainline and still have enough time to test and fix possible issues.

 

4 hours ago, Igor said:
Quote

Having a wiki-page to each supported SBC that shows if the vendor claimed features are supported by armbian or not or if there is some known projects where someone works on this feature could help to avoid people from buying false boards. 


This is fine, but very hard to maintain.

The wiki idea was discussed before, having a wiki means spending time in updating it, fixing possible issues from other people edits, managing access permissions, etc.

And regarding supported features - this example is far from complete but is already almost unreadable for an average user: https://linux-sunxi.org/Table_of_Allwinner_based_boards

And this is only Allwinner based boards.

 

And regarding the 5.30 networking issue - the problem exists in mainline u-boot since April, at least 2 people missed this issue completely, and we are talking about u-boot with more or less strict review procedures for patches and basic automated testing set up AFAIK. So even strict rules don't save from (kind of obvious to me) failures. And now we will be sitting on top of the fix (and another fix for H3/H5 I2C copy-paste issue in the DT) because we don't have a person who is willing to relay these bugs upstream or has a proper environment set up to send a patch.

Link to comment
Share on other sites

42 minutes ago, zador.blood.stained said:

we don't have a person who is willing to relay these bugs upstream or has a proper environment set up to send a patch.

I can sent patches to mainline U-Boot for H3/H5/A64. I have never sent patches to Linux (but soon), but that shouldn't be a big problem to set up.

 

However, I would rather see that original author of the patch is the one who sends it. It is very uncommon to send a patch of another person unless it is a serie of multiple patches where at least one is signed-off by a person who sends it. patman (tool in U-Boot) makes it easy to send a patch and it can be used for mainline Linux too.

Link to comment
Share on other sites

2 hours ago, zador.blood.stained said:

I would prefer to adjust milestones to kernel and u-boot releases so we can migrate with the mainline and still have enough time to test and fix possible issues.


Every or every second release? Should "Feature freeze" milestone match U-boot release date?

 

 

Link to comment
Share on other sites

Quote

If @chwe wants to take care of general moderator duties, he is one click away :)

As you can imagine, my time & know how (in this area) is somehow limited, but if it helps you and other developers to do the hard stuff that I'm for sure not able to do, we can give it a try. 

 

8 hours ago, Igor said:
Quote

IMHO. For me 3 boards are the minimum to be supported : desktop, NAS - LAMP and IoT server. 

Yes. This is at least much simpler to support and is to consider.

3 hours ago, zador.blood.stained said:

The wiki idea was discussed before, having a wiki means spending time in updating it, fixing possible issues from other people edits, managing access permissions, etc.

And regarding supported features - this example is far from complete but is already almost unreadable for an average user: https://linux-sunxi.org/Table_of_Allwinner_based_boards

And this is only Allwinner based boards.

I see the point, maybe something to consider as soon as more important issues are solved. I'm still impressed by the FriendlyArm wiki, but for sure the have much more man power to do that.  

Link to comment
Share on other sites

4 hours ago, zador.blood.stained said:

IMO every release. U-boot has ~2 months release cycle, kernel has ~2-2.5 months release cycle and current Armbian release cycle is much longer, so we may have to adjust it on the fly.


OK, than next release should be planned for Sep 11, 2017, followed by Nov 13, 2017, ... the same dates as u-boot release date.
 

26 minutes ago, zador.blood.stained said:

Also should we hide "dev" kernel target in the build script unless EXPERT=yes is set and move all boards which only have a dev kernel target to WIP section?

 

Yes, why not. 

Link to comment
Share on other sites

On 17.6.2017 at 11:40 AM, Igor said:

- moving another three boards (Lamobo R1 / Cubieboard 1 / Lime A10) into deprecated sessions. All those boards get one last update with last known working configuration and frozen kernel packages

Really R1 ?

I know TK smashes on it by every chance, but

- no one ever beside TK complained about the design problem (just some speed junkies how want to have real Gigabit)

- short cable and IKEA PowerSupply I still power mine via MicroUSB - works like a charm other can use battery adapter explained on sunxi.

- it runs an A20  which is better supported than any other (which is the greenest in the table H3, H5??    NOOOO  it is the A10 A20)

- nowhere you find this 'smart design' HDD attached on the board.

- Igor ran the forum on an A20

I have no clue, why it didn't turn on the network properly after the changes, but it always did in the past.

 

And you want to kick this board - beside me there are many who use it and willing to test. Btw, even a customer of TK is having an R1 running, unless he replace the HW.

The loudest is not necessarily right.
 

Link to comment
Share on other sites

On 17.6.2017 at 11:40 AM, Igor said:

UPCOMING MILESTONES


Milestone               Responsible Person Due On
Feature developement                   --- Due in 81 Days
Feature freeze                         --- Due in 90 Days
Beta testing and bug fixing            --- Due in 130 Days
Writing release documentation          --- Due in 142 Days
Launch                                 --- Due in 149 Days

 

Launch --- Due in 149 Days (or when it is ready)

 

and please put that somewhere were we can see that, like here (it is already written just needs a link to the lines above) 

    Countdown instead of frozen numbers ?

 

Link to comment
Share on other sites

A20 boards are generally just fine, while R1 ... we all know it's shitty by design and If we had EOS section since start, it would be already long gone simply because it sucked so much of our time, more than any other board, without any point & value.

 

There are four images for R1 for download - all are working now - I remake last image with last working mainline kernel (4.9.7) and that's all. EOS means we will officially not deal anymore with the board, but this does not prohibit anyone to make moves. Kernel updates will continue to run out so their is still hope for the board.

I also added two A10 boards there too. Why? They are working O.K., they are stable, but make just enough troubles on upgrades. Do we need to deal with them? No. They are rare and we don't have more than one sample around.

 

9 minutes ago, Tido said:

no one ever beside TK complained


Well, I would complain too, but it doesn't make any good :)

 

Quote

Launch --- Due in 149 Days (or when it is ready)

 

and please put that somewhere were we can see that, like here (it is already written just needs a link to the lines above) 

    Countdown instead of frozen numbers ?


Yes, I'll update and make it more visible asap. In any case nothing major before September.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...