09-15-2016, 02:23 AM
I'm sorry you feel that way... but do appreciate the time you have spent in trying to highlight issues in the pine64 development process, as there are issues, and they need to be resolve in order to consolidate all the confusion presented by the different sites and images.
So in a nutshell, what you're suggesting is needed (which Armbian has already done) is a scripted way to make pine64 images, which will then make it possible to easily reproduce, upgrade and fault-find. Also, which is why I was heading towards already-existing stuff like github - if we use a system that people are already familiar with, they are more likely to interact, thus there is a better chance of getting more community members involved. But at the same time, we need to get rid of all the legacy images, which are just adding the confusion unnecessarily, and ensuring that old bugs pop up again un-necessarily. And naturally, if we have some sort of automated build system, if a bug report came in for something a silly as the uEnv.txt having hard-coded mac address by default, it could be fixed, tested, and an updated image made available. And if there was some way to add a CI system like Travis, even some of the testing would be automated as you go... i.e. changes to build scripts.
Maybe we need to split this off into another discussion thread focusing on streamlining the build process & documentation (maybe at post #133?) so this can be discussed further. It would probably also go hand-in-hand with the discussion stating up about potentially android moving from the code base that the pine64 guys have been working on to a community one as that appears more stable and more manageable, so there is again the question of how to make so everything can be backed up, tracked, documented, etc.
So in a nutshell, what you're suggesting is needed (which Armbian has already done) is a scripted way to make pine64 images, which will then make it possible to easily reproduce, upgrade and fault-find. Also, which is why I was heading towards already-existing stuff like github - if we use a system that people are already familiar with, they are more likely to interact, thus there is a better chance of getting more community members involved. But at the same time, we need to get rid of all the legacy images, which are just adding the confusion unnecessarily, and ensuring that old bugs pop up again un-necessarily. And naturally, if we have some sort of automated build system, if a bug report came in for something a silly as the uEnv.txt having hard-coded mac address by default, it could be fixed, tested, and an updated image made available. And if there was some way to add a CI system like Travis, even some of the testing would be automated as you go... i.e. changes to build scripts.
Maybe we need to split this off into another discussion thread focusing on streamlining the build process & documentation (maybe at post #133?) so this can be discussed further. It would probably also go hand-in-hand with the discussion stating up about potentially android moving from the code base that the pine64 guys have been working on to a community one as that appears more stable and more manageable, so there is again the question of how to make so everything can be backed up, tracked, documented, etc.
(09-15-2016, 01:49 AM)tkaiser Wrote: Enough time wasted here again. When I come up with Pine64+ NAS benchmarks with FreeBSD and mainline kernel I post them to Armbian forum, feel free to link to then.