Repository structure discussion

[Gormartsen]

I recommend next branch structure for github.

• master - current stable release
• testing - current testing release
• unstable - current unstable release
• issue-NNN - issue related release for development purposes.

This way we heave next code flow:

Branch issue-NNN get created from unstable testing.
When issue get fixed in this branch, we merge code via PR to unstable testing.

We can have some tests for package to run them automatically on testing branch.
When testing branch passed all tests code get merged to master (stable).

When we do a release, we use TAG feature for history.

I cut out unstable, because I couldn't find how unstable different form issue-NNN.

This conversation is important, because I am going to use branch structure to automatically build packages for repository:

master -> stable
testing -> testing
issue-NNN -> unstable. If there is more than one issue-NNN branch, i can automatically build packages like fedberry-23-0.9.issue-NNN

This way we can install RPM form unstable using issue name.

Another important part is versioning.
If we keep changing version and changelog via file like:

 -Release:        0.8
 +Release:        0.9

 +* Sun Mar 06 2016 mrjoshuap <jpreston at redhat dot com> - 23-0.9
 +- Autogenerate html docs from md files
 +

We will get in conflict trouble in future.

I can generate changelog using commit descriptions.

For version naming I am open for propositions.

[mrjoshuap]

Agreed. Also, we should be removing archives from the repos... as I've put in a couple of the PRs, we should perform a spectool -g -R <SPECFILE> before the rpmbuild -ba <SPECFILE>. This will help keep the repos small.

[Gormartsen]

@mrjoshuap 👍 Agreed. sources should not be a part of github repo.

[mrjoshuap]

For some repos we use version YYYYMMDD release 1.GIT_COMMIT_SHORT, others use a version 23 release NUMBER. I'd like the versioning to be consistent, one or the other. The mix usually makes things more difficult. Thoughts?

[Gormartsen]

Personally I follow next flow, but we can decided to go with different approach if it suite our tasks better.

http://scottchacon.com/2011/08/31/github-flow.html

So, what is GitHub Flow?

Anything in the master branch is deployable
To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
Commit to that branch locally and regularly push your work to the same named branch on the server
When you need feedback or help, or you think the branch is ready for merging, open a pull request
After someone else has reviewed and signed off on the feature, you can merge it into master
Once it is merged and pushed to ‘master’, you can and should deploy immediately