Plans for packages/archives instead of using git?


#1

I’m curious as to why it’s set up like this instead of a archive drop / package. It works, but there are quirks - most notably a user ends up bleeding edge which may be broken (it was when I tried*) and it’s hard to pick a specific “version”.

Another problem is, allthough it can be fixed, that some config files are checked in. Changing them makes git then believe I have changes to be (potentially) checked in, not very elegant and can in some cases prevent me from pulling stuff. One proper fix is create them in “home” (why run as root?) somewhere if they do not exist according to some template, and read them from there, as this also fixes them being overwritten.**

*I’ve filed the stuff I found as issues on github, and I belive they’re fixed
** I don’t have much time on my hands, but I could possibly do this.

Don’t want the post to be overly negative, so ending with a big kudos to pulling the project together! I’m looking forward building a kit or two


#2

Your question is quite generic.
Make a specific request/proposal and Fernando will think about it. He is very open for improvements.

But qit is state of the art. We could have new images quicker though. And yes, when you checkout, it was not a good time. A day after a merge, iirc.
It’s still a project for a certain hardware set and not a software project which runs on any hardware. So generally I agree with you about the config/home location. But it would work best, if you create your own branch, make the changes and propose them to Fernando.

There is still a github topic waiting for your answer :slight_smile:

Kind regards,
Markus


#3

I replied to the github ticket, my bad it was a bit misleading.

Well my question is actually specific but maybe my examples to frame it are poor. Zynthian uses git to deliver to an end user. There are some problems with that approach as i tried to exemplify. Master or dev branches braking stuff sometimes is nothing strange, just not very nice for an end user. One way to remedy this is to deploy zynthain releases as a big bundle to go into /zynthian (not a full os image) which a script can download and extract as opposed to running git pull etc etc. There would be some minimal testing done on each such release etc. More work, sure.


#4

I agree, that we need something, that filters broken master branches.
And if there will be more contributors in due time, it will be crucial.
We could use tagging also.
We need volunteers who test the master. Once they are happy with it, we create a tag.
This tag is published in a file, that the zynthians collect and git pull, if new.
We need to define kind of sprints. While developers make changes in their branches, the master is not touched besides for bug fixes. The testers have weeks to test. Before we merge the developers work, we create a tag of the now working master.


#5

Zynthian images does not use master branches for the 2 more important/complex repositories:

  • zynthian-ui
  • zynthian-sys

The update system uses different branches for updating these 2 repositories. In that way, i can merge from the master only those features that are “more or less” well tested. So developers and advanced testers can use the master branch in its zynthian boxes for testing before merging the changes into the “update” branch and going to “the masses”.

Anyway, currently Zynthian software is very experimental and using it, you “kind of agree” contributing to debug. We are a small community yet, and we need testers to reach stability. If only developers test the changes, it wont work, so … currently every user is a tester :wink:

If you want stability you should use the SD image without updating. The updates from a SD image to the next one can contain bugs … well, the SD images too :blush:

Probably we can define a better way of working, and we will do someday, but currently it’s not a priority. We are only a few developers yet. Let’s walk a little bit more, focus on improving software, adding features and debugging. We will come back to this subject later, when it’s really important and needed.

Thanks!!