[CCC DEV] Branch question/confusion

[Fred Barnes]

Hi,

> 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
> pulled.
> because:
> - 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
> master.
>
> 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.

Yep,


> > > 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.

Agreed.


Cheers,

-- Fred
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
URL: <http://lists.concurrency.cc/pipermail/developers/attachments/20130424/db7e41a8/attachment.pgp>