> > If I understand you correctly, you would like 'master' to contain
> > more stable code than what is usual for a large number of existing
> > projects - broken code, incomplete features, failures to even
> > compile, etc. And that is a nice goal indeed. I think we can achieve
> > that either by: 1. strong development practices - feature branches,
> > commit reviews, continuous integration tests or by: 2. not bothering
> > with strong development practices and putting all dirty work into a
> > separate development branch (let's call it 'develop') that's going to
> > be broken most of the time. However, every time the code starts to
> > look better (it compiles, tests pass), we promote it to master.
>
> 2. is not acceptable in any way, shape or form. The development branch
> needs to be usable almost all of the time and we should be deploying it
> to a dev system on a regular (every couple of days, bare minimum) basis.
> Regardless of what we call the different branches, the only place it's
> acceptable to have regularly broken code is in a feature branch.
I didn't mean that 2. would be suitable for us :-) I just wanted to say that
even this would be an improvement for some projects out there in the wild which
have their master broken most of the time.
>
> > Of course 1. is better than 2., but it would be nice if those
> > aforementioned bad projects adopted at least approach 2. The result
> > is that people interested in bleeding edge code have working master,
> > and even if they send a patch against master and 'develop' is used
> > for the actual development instead, usually those two branches are
> > not that far apart.
> >
> > Unfortunately, that's not what gitflow does. In gitflow, 'master'
> > means *the* stable, it means old code.
>
> No, it means "production ready" code. While that is going to be older
> than whatever we're currently developing by definition, it's not like
> develop is rawhide to master's epel. It's a consistent place to get
> stable code from if you chose to deploy from git or are working on a
> bugfix against the currently released version that can't wait for the
> development branch to be ready for release.
If you see it like this - you want 'master' to mean 'production ready' (== only
officially released versions) - then gitflow makes absolute sense.
>
> > It's not continuously updated
> > from develop branch, it's updated only at releases. It's not the
> > branch you want to receive patches against.
>
> Why not? If the fix is for a bug in master, wouldn't we want the patch
> against the released code instead of against code which hasn't been
> released yet?
It depends how much we would have re-factored the in-development code in the
meantime. In general I would rather see more patches against development code
than against stable code, it's easier for us to merge. But in most cases it
should not matter much, right.
>
> > And it's kind of
> > superficial anyway, because why would you check out a branch
> > containing only tagged commits? In git you can check out a commit
> > directly.
>
> How would you integrate any changes to that commit without making an
> unholy mess of the repo or releasing it as a patch?
Exactly the same as in the original gitflow model - by using hotfixes branch.
See the picture at [1].
Let's say you find a problem in tag 0.1. You create hotfixes/0.1 branch
starting from commit 0.1. You fix the problem in one or more commits. Then you
tag the last commit as 0.1.1 or 0.2, as you wish. Finally, you can delete
hotfixes/0.1 branch, it's no longer necessary.
Then you discover problem in tag 0.1.1. You create hotfixes/0.1.1 branch
starting from commit 0.1.1, fix the problem, tag the latest commit as 0.1.2,
delete the branch.
Of course all those hotfixes get merged into your development branch as well.
Everything is the same as in the picture. I was just trying to point out that
the rightmost thick line connecting tags 0.1, 0.2, 1.0 and so on (a branch
called master on the picture) is not necessary at all. The only "advantage" it
has is that it allows you to do "git pull" to get the latest stable release
instead of checking out a tag directly ('git tag' and 'git checkout <tag>').
However, since you don't agree with master referring to development code and
you rather want master to refer to the latest stable code (something I haven't
expected before), then yes, the original picture in the article makes sense in
this case. If you intention is to offer people the latest stable code by
default (when they open up our github/bitbucket page, they are shown master as
the default branch), it all makes sense and the branch is needed. (That's not
what Fedora Infra does, however, they display 'develop' branch as default for
many of their repos; that defeats the purpose of the rename in the first place).
>
> > I think this part of the workflow was created with some
> > older SVN-like systems in mind, not git.
>
> This workflow would be insane in SVN, branching and merging are
> expensive and tend to be painful.
>
> > So, in gitflow a 'master'
> > doesn't mean 'unbroken code', it means the most stable code you can
> > ever get.
>
> Exactly - it's stable code. The methodology provides a clean and well
> defined way to make changes to both stuff that's been released and stuff
> that hasn't been released yet. I'm not saying that gitflow is the only
> answer or that there aren't other ways to manage branches, I just think
> that it's a good, relatively well-defined solution and I don't really
> have a better alternative.
>
> > So, it depends what you want to have. If you would like 'master' to
> > mean 'unbroken/more stable code', I think gitflow fails to deliver
> > that. If you would like 'master' to mean 'you can't get any more
> > stable', then gitflow is perfect. But I really don't think that this
> > is a common understanding.
>
> Well, gitflow or any branching strategy isn't a cure. It's simply a
> methodology that takes any guesswork out of where code should go or
> what's in various branches. Without discipline and good development
> practices, it's worse than useless because we'd have multiple branches
> with an unclear purpose instead of just one.
>
> One of the biggest advantages I see in having a 'develop' branch is
> that new features don't have to come to a halt at release time. If we
> combined master and develop, new features can't be merged in once we
> start the pre-release process. How do you propose we do release
> branches without a separation between develop and master?
That's what the 'release' branches are for, see picture at [1]. It's like
branching Fedora XX from Rawhide. You branch 'release/1.0' branch from your
main development branch and you can work on both in parallel - stabilizing the
release in the release branch and do more development in the development branch.
So, in my world, 'master' branch never stops and 'release/XX' branches are
branched from it. In gitflow world, 'develop' branch never stops and
'release/XX' branches are branched from it. I don't see any major difference :-)
>
> How would hotfixes work if we find critical bugs in released code
> when our development branch isn't ready for release? How would the
> gitflow tool be affected? Can it handle stable and development branches
> being the same?
Let me try to illustrate my changes a bit better :) See this:
http://i.imgur.com/dLMe9fM.png
or alternatively this:
http://i.imgur.com/MQ1Hpg3.png
I haven't suggested any other changes to the workflow, everything remains the
same. All features stay intact. I just proposed to fix a logical inconsistency
in branch naming (in my view).
>
> > > That being said, I'm not completely against this idea if there are
> > > enough other folks who are +1. I'm still -1 on the idea but I could
> > > live with it :)
> >
> > In that case it will depend on what others think (or if they voice
> > any opinion at all). Of course, I could live with the default gitflow
> > as well. I just simply find confusing and a bit irritating its choice
> > to rename traditional branch names for no apparent reason or benefit
> > (in my view). I can definitely cope with it, sure, I'll remember what
> > branch name to use. But I'm concerned about the passers-by and
> > potential bleeding-edge users/contributors. I see this as an
> > unnecessary bump on the road they need to hop over.
>
> I'm not as worried, to be honest. We need to document our processes
> better but in a similar vein to what I said about github and making
> drive-by patches easier, if someone is not capable of looking at the
> readme or any other docs before writing a patch ... are we really that
> confident that any contributions would be useful and wanted? If
> reading the readme and typing 'git checkout develop' is too much work
> for testing, how likely is it that the same person would take the time
> to file a decent bug or send mail to the list?
I agree with you, people will need to read documentation anyway. The only thing
I dislike is that we want to divert from the traditions that everyone knows.
'master' is traditionally used to mean the main development branch, or at least
_a_ *development* branch. If we want to have a branch with just stable,
released code, why wouldn't we call it 'stable' (or anything similar) instead
of changing the meaning or 'master' and then using a different branch for the
purposes of master?
But I don't think we should spend too much time on this. If you believe that we
should go against the tide and have 'master' to mean something else, I'm fine
with that. I simply did not expect that this is really your intention.
>
> It'd be nice to hear some more opinions on this - especially
> from folks who will be regular contributors (don't make me call you out
> by name because I will resort to that if needed).
I think they are a bit discouraged by the long discussion and they don't want
to wrap their brains around all those graphs and models. I'm not surprised, I
did not expect to go into so much detail anyway, for me this was a trivial
rename fix proposal. But apparently I wasn't able to describe properly how
simple all of this is, and it evolved into such a complex monster issue :-) I'm
fine with anything, really.
_______________________________________________
qa-devel mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/qa-devel
