Re: [debops-users] News from the DebOps project

Hi, sorry for the late reply. On May 01, Scott wrote: The stable releases of DebOps are not designed yet, I plan to work on that in the form of DEPs (DebOps Enhancement Proposals) - something akin to Python's PEPs if you are familiar with them. The idea is to have a set of documents that describe the project development, ideas and usage, tied to the git repository. DEPs are explained in https://docs.debops.org/en/master/dep/dep-0001.html I hope that tying this system with the DebOps monorepo will make sense in that the changes in specific DEPs will be traceable alongside code changes in the git history. Now it's time to write some initial documents that describe current status quo in detail, I have some ideas in mind: - DEP 100: What's the project about and what we are trying to do here - DEP 101: Debian as a reference Operating System - DEP 102: Ansible as a default orchestration engine - DEP 10x: Usage of Operating System repositories as a priority - DEP 10x: Usage of third-party software sources - DEP 10x: Focus on stable software releases as an alternative to rolling releases - DEP 10x: Definition of public API These will be written and published on the mailing list first for a review, then they can be added to the repository. With DEPs I don't want to specifically focus on individual Ansible roles; instead define guidelines for role authors as to what DebOps roles should do - for example, how to install Go-based software from upstream. DEPs can also be used to define the final result of DebOps, ie. the infrastructure you get when you use it. Of course if you have any ideas you would want to see as DEPs go ahead and write about them. I aim for DebOps to be a community-driven project, not everything has to come from me. :-) I'm aiming for stable DebOps releases to use their own 'stable-x.y' branches, with the v1.0.0 being the first "stable" release. What "stable" means in this context would be that only fixes that don't modify the existing public API (default variables, local Ansible facts) would be backported to the stable branch. No new roles, no drastric changes in the configuration. I'm not sure how many "stable" branches would be supported, but probably 2-3 max depending on time and additional work needed. Any changes would need to be merged into 'master' branch before being cherry-picked to a stable branch with a new release. This all should be defined in a DEP. Keep in mind that from my point of view I care only for the 'master' branch to have the latest changes available, so input from people that try to stick to some version of the project would be greatly appreciated. What do you expect from DebOps in this case? Right now I don't think that DebOps is ready for a stable release. There are many roles that have to be updated to current DebOps standards, for example to use namespaced variables. I'm hesitant to make a stable release with current codebase since there will be lots of changes in the next one. But, as far as I can tell, lots of people are now using DebOps in their production environments, so maybe that is exactly what you would expect? To have a stable release with current codebase with known bugs and issues you can handle on your end. It seems that any issues with Python package release that includes the Ansible codebase are now fixed, I could do one more v0.7.x release to check if everything works and then v0.8.0 which would have its own 'stable-0.8' branch. That way we could test the stable release scheme, commit cherry-picking and minor releases. Perhaps this should be well defined as a DEP first, or we could define it afterwards when the good practices are estabilished. Let me know what you think. Cheers, Maciej