[debops-users] News from the DebOps project

Maciej Delmanowski drybjed at drybjed.net
Wed May 9 12:38:04 CEST 2018


Hi, sorry for the late reply.

On May 01, Scott wrote:
> Great to read about the upcoming changes. While reading through the
> documentation today to I ran into a couple of errors and realized it was
> due to using the latest documentation with an older version of DebOps.
> I've yet to upgrade to the latest version until I get a chance to fully
> review the changes. I'm hesitant to upgrade until I know it will be
> smooth as this is in production, especially with the X.509 certificate
> changes (although it appears that only affects new certificates).

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. :-)

> To my point, I wonder if it wouldn't be worthwhile to have separate git
> branches for each release; or is it too early for this (perhaps this is
> more suitable for major point versions)? I imagine it would be helpful
> whilst running an older version and preparing to upgrade as well as
> tracking changes and being able to more easily view version diffs.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <https://lists.debops.org/pipermail/debops-users/attachments/20180509/248c4dad/attachment.sig>


More information about the debops-users mailing list