[CCC DEV] Branch question/confusion
F.R.M.Barnes at kent.ac.uk
Wed Apr 24 20:03:21 BST 2013
> Yes this is extra work, it also leads to MUCH better code from everyone.
> Code review sounds a pain, but usually isn't, how about just trying this
> for a while?
I'll give it a shot, sure ;).
> >[snip fred commit model]
> I really disagree with this. All work should be done in a branch/fork and
> - This is how git is designed (well pulls are a shortcut around passing
> around patch sets).
> - Small changes are rarely small.
> - Promotes testing before making it to master.
> You can make pull request for indervidual commits if you work in your own
> We also want other people to work on this project right? We should impose
> the same rules on ourselves as those who help us?
I suppose .. :). One particular thing I had in mind was when I get a bug
report on kroc-bugs typically of the form "the occ21 compiler crashes when ...",
which in some cases are fixed in a small step easily. This is probably a
peculiar case though, since only a small set of us are comfortable with how
that particular code-base works (though, getting external folk involved can
only be a good thing there!). But I'll sacrifice that shortcut for the greater
good of fork/pull model :). [.. off to fork kroc].
> > > Branching and tagging for release is separate.
> > > We make a 1.6 branch off of master, this is not committed to directly,
> > > all
> > > new work goes into master, we just cherry-pick bug fixes from master.
> > Yep. Again, I wouldn't object to developers cherry-picking their own
> > fixes/updates
> > into the stable branch (otherwise we're likely to generate backlog).
> Cherry picking bug fixes should be done into the release branch at the same
> time as they are committed to master.
Yep -- is someone going to pull Adam's changes over into kroc-1.6? :)
> Ok, I worded this badly, new branches should really be made when we want to
> introduce backwards comparability breaking changes.
> > > Tags signify releases on a branch. They should be done at stable points.
> > > 1.6.0 is the first stable point on the 1.6 branch.
> > > We make new tags after pulling in fixes from master and when we think it
> > is
> > > stable.
> > > We Tag often...?
> > I'd save tagging for when 1.6.0, 1.6.1, ... become available. When telling
> > people to get the stable kroc, they'll be downloading the kroc-1.6 branch,
> > rather than a particular tag, so should get all the fixes-to-date.
> As soon as we think 1.6 is stable we should tag. Tags are known good
> points and should be what we base our releases off.
> for people using git pulling 1.6 branch is probably fine. But for a deb
> package it is better to say this package is built of this specific tag.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 185 bytes
Desc: not available
More information about the developers