branches etc about rhel7-cis HOT 2 CLOSED

Items addressed in bold below.

• create a master or stable branch base on current version

  • This is the current plan. We will create a master branch and cut stable releases from it once the role is more complete and we are ready for a "stable" release.

• add a staging branch and allow a few people write access

  • I'm not sure I see the purpose or benefit of having a staging branch. Can you explain further? Would changes get committed directly to staging vs the current PR -> devel flow?

• you could then cherry pick changes into devl from staging

  • See above.

• merge devl into stable after x amount of time

  • This is the current plan. Once we have a stable/finished release.

• use tagging system that indicates current playbook compatibility

  • We currently tag things with a standardish versioning system. Can you explain further what you mean here? Like make the tags match up to Ansible versions or CIS benchmark versions or something?

from rhel7-cis.

"I'm not sure I see the purpose or benefit of having a staging branch. Can you explain further? Would changes get committed directly to staging vs the current PR -> devel flow?"

i imagine this as an additional option to a PR which typically has many commits. one off fixes/rule implementations could be staged and pulled in faster. people will immediately see that and might choose to do a quick fix on something else instead of potential overlap

"We currently tag things with a standardish versioning system. Can you explain further what you mean here? Like make the tags match up to Ansible versions or CIS benchmark versions or something?"

Yes a concatenation, latest benchmark being v2.2.0 thus v1-2.2.0 then v2-2.2.0 or similar.

from rhel7-cis.