[rkward-devel] splitting repos?

[Thomas Friedrichsmeier]

Hi!

On Sun, 25 Oct 2015 18:20:06 +0100
meik michalke <meik.michalke at uni-duesseldorf.de> wrote:
> do i get this right that "work/xyz" is supposed to be a branch that
> directly spawns from "master", not a branch "xyz" that spawns from a
> branch "work" (and that in turn from "master")?

Yes. "work/xyz" is simply a naming convention. Other than that, of
course it does not matter so much where the branch spawns from (could
also be another, existing work branch, or a release branch, or ...),
but where it will be merged, eventually. And that's generally master,
so far.
 
> as far as i can tell we're currently developing in the master branch.
> what do think about moving toward a branching model like outlined
> here: http://nvie.com/posts/a-successful-git-branching-model/
>  https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
> 
> it would mean that "master" is always the current stable release,
> marked by release tags, while all development happens in a branch
> spawning from "master" (e.g., "work"), and single feature branches
> can spawn from that development branch (or kept local until it's
> merged into the development branch and pushed to origin).
> 
> just a suggestion.

It may make sense to have a permanent branch that is always the current
stable release (or the upcoming release). Personally, I'd find it
rather confusing to call that "master", although I am aware that some
people like it that way. Make it "master" and "stable", instead, and
I'll be happy. We could try something along these lines when it's time
for the next release.

Also, it probably makes sense to make more use of temporary feature
branches. I'm only just starting to get the hang of that, myself... What
I do consider rather important, though, is that we keep having one
branch where most development is visible _early on_ (i.e., generally,
before a feature is fully tested and polished). The common base for
active developers, for daily builds, for making it easy to see and
discuss what is actively going on. Currently that's what "master" does
for us.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20151025/240fe658/attachment.sig>