Comments inline:
> So it looks like we're keeping the submodules, based on the previous
> debate. On that basis, let's talk about how we should treat the
> repo(s) with respect to merges.
>
> We've already added a "develop" branch, and we've cut a first tagged
> release from master (1.0.1 to match the foreman versioning). However,
> there are some open questions:
>
> How does "develop" map to the submodules?
Not completely sure what this means, but I will take a whack at it 
I think the submodules should only have a master branch just as they do
now. Since submodules are just pointers to SHA's in remote repos there
is little need for have a separate branch to roll changes. This also
affords us the ability to tell people to update one specific module if
there are bugs in the versions that are cut into tags via a simple pull.
> How strict should we be with "develop"?
> How often should we update "master" from "develop"?
I'm going to answer this question and the previous one in a single
block since I think they flow together nicely. I think master should
have the current stable stuff in it so we can cut tags from it directly
- this might mean cherry-picking from develop to master for fixes that
cause problems with the current releases. As far as how strict we
should be with develop, I think we should just treat it as the defacto
branch for new changes. Like outlined previously, merges from develop
to master can happen as needed and the releases can result in a
complete merge. This does mean that develop needs to be clean to get
merged and released every time we do a Foreman core release, but that
should be attainable since those releases are pretty rare right now.
> How often should we tag?
Like I said above, I think it should be driven by the exact version of
Foreman at that time (i.e. 1.0.1) with a minor version appended, just
like most packagers do. So 1.0.1-1 would be first, etc. This process
can happen as often as we want once we define the conditions under
which backports should happen.
> How should we deal with backporting bugs/fixes?
>
> I suggest the following:
>
> Merge pull requests to "master" on the submodules and keep "develop"
> pointing to the SHAsums for "master" in foreman-installer. Minimal
> testing/ACKs required for pull requests to be merged in this way.
Do you mean master for each of the submodules?
>
> Keep "master" on foreman-installer pointing to last known stable
> SHAsums. Do extensive testing every couple of weeks before updating to
> match develop (at a minimum, a basic install on our supported OSs)
>
> Tag a new master release after each Foreman release, assuming "master"
> passes the tests.
+1 to each portion of this methodology. I would also like to define a
test procedure that we can script and run via Jenkins to qualify
releases before the tag gets cut.
>
> Backport critical issues only - do we retag?
I think we assign a patch version, i.e. 1.0.1-2.
>
> This would mean that "master" in the submodules is live development
> code. That's not ideal, but maintaining 10 more "develop" branches
> seems like too little gain for too much effort. It also means that
> it's not too much trouble for one person to merge a bunch of PRs to
> "develop" without needing to wait on ACKs - we can do the
> peer-review/testing at the merge-to-master stage.
I'm actually fine with this, especially as the packages get out into
the wild more people will probably end up using them instead of direct
clones.
···
On Mon 05 Nov 2012 11:41:43 AM EST, Greg Sutcliffe wrote:
Thoughts?
