just a tiny thing, but I also noticed that WIFI can not be switched of. It says Can’t stop wifi network.
I think this also causes that the wired network connection doesnt funcion, because all the webui stuff became very slow here.
and I just noticed that the webui connection is not possible anymore…? Anybody else has this?
terminal tells me “ssh: Could not resolve hostname zynthian.local: nodename nor servname provided, or not known” when I try to login. Is there any quick solution for this? Because I have this concert tomorrow…
I wanted to check the midi filter rules because they didnt function like before the update.
You may have downloaded the same file twice. 2 images generated on 2 different runs can’t have the same MD5 signature because timestamps are different.
Sometimes, a night build run succesfully but the zip file is not generated correctly, provoking a “gap” in the file sequence. To avoid downloading the same file twice, please, check the file’s date.
Also, take into account that the date shown in the Jenkins GUI is 1 day before that the file’s date. That’s because the build takes several hours and Jenkins show the starting date, while the file’s date is the ending date. As i want to have the fresh image early in the morning, i’ve moved the starting time to 21:00 …
I’m opening an issue for fixing this ASAP … 
Regards,
I’m working for fixing that.
Yes. It’s explained above, my friend:
You shouldn’t be using Aruk images for production … it’s in pre-release state.
Kind Regards
ah shit ok sorry, was not really aware that it was in prerelease state…
@jofemodo please let us know what we can do to help with Aruk. I am in the process of reinstalling Gorgona Omega an it is taking so long. Download, unzip, flash, update… This takes hours and I will need to do it all again when I test Aruk. Is there a plan for the test and release of Aruk? I am sure there are some great minds with fantastic experience and skills available in our community to help which may best be targeted as specific tasks. (I have been an engineer, software developer, test manager and project manager.)
Hi @riban!
As you have noted, Gorgona is quite old and the proccess of fresh burning + updating is too long and complex to be reliable, what makes difficult to get a working and updated Gorgona image.
Releasing Aruk is my zynthian’s highest priority right now. You and other zynthianers can help me with this task in several ways:
Downloading and testing the “green” build images and specially, the release candidates.
Report errors/bugs you find on gitHub tracking systems, taking care of choosing the right repo. Please, report consistent and reproducible errors. If you have doubt, we could discuss in the forum before opening a new issue. Also, try to no duplicate issues.
Fix as many error/bugs as you can. If you know what should be done, do it. Fork & PR, or use a development branch if you already are a zynthian’s team member.
Merging new features is frozen until Aruk is released. I love to develop new features and really hate testing and debugging … so please, please … don’t feed the monkey!! 
Let’s focus on releasing Aruk and after that, we would have a long period of fun, for developing lots of new and exciting features without worrying about releasing a new image 
Of course, i would really appreciate any collaboration and tips about how to organize the tasks, improve the processes, etc.
Really love you all! 
I wonder if github projects might help. It would allow organising issues into cards which might allow for triage management, prioritisation, etc. It isn’t brilliant but provides some basic functions.
Another area that may confuse others (like it confuses me) is where to report issues. Currently there are several repros, some with issue tracking enabled. A user must consider what the issues is and where to report it. That can sometimes delay or worse, inhibit reporting. I appreciate that @jofemodo is pragmatic and will triage and move issues as appropriate but I think it may be beneficial to have a single issue tracking system for the project / product and use filtering and assignment to assign issues to modules, developers, etc. A single place where users can search for existing issues, report issues and track responses may ease the whole process and provide better issue tracking. It could also be linked to in the web-conf and http://zynthian.org.
Keep on suggesting enhancements but we need to be disciplined in putting them in the backlog rather than jumping on the shiny stuff. (I know it is hard and I will break that rule more than once 
.)
I’m already using it. Take a look to “Aruk” project in the repos …
Regarding an unified place for reporting the issues, i think it could be nice. Perhaps we could create a “dummy” repo on github for that?
Regards,
This would be only useful, when you can move them between projects.
Non technical ppl will submit here and savy ppl can create them in the appropriate project.
A problem with that is that a user who reports an issue wants to see updates to that ticket. If we have an issue manager who can keep both synchronised then it works, i.e. a public facing issue tracker and an internal defect tracker but this adds significantly to effort. This is how many of my projects work with our suppliers having multiple issue tracking systems and the project having several and there is someone having to copy updates between them. It does work quite well and has advantages if you have a defect tracker which is used purely for technical matters which is synchronised back to the public facing one but there is an overhead.
An who is paying this defect manager?
Too complex! We need something simpler. My proposal for reorganizing things after ARUK release:
Create a dummy repository “zynthian-tracking” for issue tracking.
Inside this repo, create a project for each active zynthian repository: zynthian-sys, zynthian-ui, zynthian-webconf, etc. This implements the triage system.
Create a consistent and well-defined label set.
Use the cross-project referencing notation in commits (i.e. zynthian/zynthian-tracking#45). It’s not so comfortable as the #45 notation, but it’s a little price to pay.
In such a way, users can follow the issues,easily while developpers can keep issues separated by code repo and commits linked to tracking system.
Of course, if you have a better proposal, my ears are open, but keep in mind that we have no resources/time to waste. The overhead must be minimum …
Thanks,
Alternatively, we can use the github global issue viewer:
https://github.com/issues?utf8=✓&q=is%3Aopen+org%3Azynthian+
combined with a “organization” project kanban.
The problem is that you can’t create issues from here. We should have a “dummy” repo for issue creation, then the “triage stage” would move each issue to the right repo. The user could follow the issues using the “global viewer” or the organization project kanban.
It’s probably the more coherent workflow because each issue is moved to the right repo tracker.
Regards,
These are success problems!
We have demonstrated considerable ability in developing. The addition of the audio meters, for instance, have to me, demonstrated how effective the open source approach to development has been. No hierarchy of managers pronouncing, no hastily written justifications to be ignored outside the overview. And look at the speed it has come together.
Just competence…
Excellent!!
At the same time we are moving to a CI approach to release which once again is progressing very effectively, There are issues. It would appear that a unplayed zynth is going to have a jack crash at some point, and I imagine we would all agree that this is an issue we need to address, and if a freeze on new features aids that process, (not that I’ve EVER been guilty of feature suggestion, Oh No…) then I for one am willing to offer nothing more than testing to get back to the reliability I have come to expect.
But I think the idea of testing is where we do have issues. Retrofitting of testing harness is a difficult process. And quite how we DO test seems to be an area that would really help our situation.
I have two main zynth’s and I would have to say my testing procedure is pretty haphazard, partly because they both have idiosyncrasies that have just appeared and then resolutely refused to go away. I haven’t got TTY MIDI IN anymore on one machine and I’ve lost the ability to use a mouse on the other. Perhaps this makes me a bit slap dash on my testing process, but I would like to think that we have some form of operational testing to declare some baseline functionality ( it loads a snapshot, it plays a snapshot, it loads an engine, it plays the engine, it removes the engine, it’s not there…)
sort of stuff.
We can now drive the interface from MIDI messages and perhaps a sequence of MIDI and some examination of the recorded or listened output might provide a quick method fro confirming the basic functionality before we refine the examination to long running issues like the passive jack failure.
So you say wyleu, my sweet, why don’t you get on and prepare such a thing? Well that’s where the hierarchy of the commercial organisation CAN apply some pressure that produces results, because with the best will in the world the tedious ( and I say that from experience) process of constructing and refining such tests is not something that the discipline of the Open source community does address particularly well. What is a priority on Monday can disappears under the simple process of getting throu’ the week, to be replaced by the next weeks great enthusiasm .
So perhaps we need to adopt a community consensus to make the process of testing a zynth as competent, successful and considered as the effort we put into developing new features.
As I said I am as guilty as any, but should I be charged by the community to provide a SUBSET of the testing area then I would in the same vain as the ‘Where’s your sound sample?’ confrontation feel a pressure to produce such a SUBSET. it really only requires a couple of components.
1/ An overall agreed approach to HOW we test.
2/ Volunteers to accept the subsets of testing
3/ A draconian allocation of subsets to those volunteers
4/ Much congratulation and partying when tests are provided.
I’m up for it, hopefully others are as well…
Once we have this nailed THEN we can get back to the much more enjoyable process of sentences that start, How about, or what if, or could we…?
Great! We have a volunteer!!!
There are a few concepts around testing but mostly there is a general consensus on what is good practice.
Within functional requirement testing one might create unit tests or similar to run specific tests to ensure user workflows will operate as designed. (Workflows may consist of several test units.) I have found the best way to define functional tests is to do so in combination with the user requirements and the documentation. Basically these three things are very similar and by combining them you end up with tests and documentation that closely match the design / requirements with minimal effort. So the functional tests might follow the user docs and other guides and in turn they will inform that documentation and improve it.
Non-functional tests may include resilience, availability, load (limits) and soak. You can consider load testing as ensuring that the product works up to its normal limits with its expected load, e.g. Pianoteq supports 16 note polyphony with specified JACK server settings. You can consider soak testing as ensuring the the device continues to behave as expected over an expected period, e.g. all normal tests continue to pass when run at intervals over several hours / days. Stress testing can be considered as identifying the load at which the system breaks which informs how much you can do before it starts to break.
Monkey testing is the most fun as it basically means play until something breaks, report the issue preferably with detail of how it broke / what triggered the issue then carry on playing. This is what most open source projects get because you can ask people to play with a version and some will.
I am happy to be involved in testing at all levels. I have some experience of testing technology projects and concur with @wyleu that it can be tedious but only really if the tests are poorly written and you need to repeat them.
I haven’t mentioned regression testing and other such things. One thing at a time. Should we split this discussion out to a GitHub ticket or separate forum topic? I feel there is a discussion to be had (that we are having) about how we test, how we manage the project and separate, announcements and progress reports on new releases. This topic seems to have swayed around these topics.
@jofemodo I see you have implemented much of this but not yet the Zynthian Tracker (dummy) repro for triage. This looks like a it could work though only time will tell. We should test drive it. New issues should be reported in the Zynthian Tracker and triaged by our triage manager (@jofemodo?). These are moved to relevant repo issues. The Kamban boards are updated with progress. We need to agree the board titles and what each means. There are already “Awaiting”, “Analylzing”, “Work In Progress” and “Testing”. There may need to be a different set for the Zynthian Tracker project.
Hi @zynthianers!
Sorry for not answering all your posts on these days. I’m having a very busy week.
But … i’ve dedicated some hours to the new Aruk image:
So … today we have a “green” fresh night-build SD-image that should be tested:
I will be out all the weekend, but if you test this image and everything is fine (or not worst than before!), i will release Aruk RC-2 on monday
Thanks a lot for your work and patient!
Pulling it down. We shall see how it gets on.
Well it loads ok & runs ok on zynthian-amp2.local . . .See if it’s still up tomorrow morning!
Well zynthian-nord.local also runs and the Mouse interface on the GUI has majikally come back to life !!
https://discourse.zynthian.org/uploads/default/original/2X/d/db2
a1c65b5fc89555881b4929fd5cbf17fb5c4b8.wav
Let’s see if they are still alive in the morning
and indeed it is!
fill the sky with hats!!