[CCC DEV] Branch question/confusion

[Martin Ellis]

>
>
> As Matt identifies, doing work in our own forks branches then making pull
> requests
> requires that someone (other than the committer) gets involved.  In many
> cases
> that's extra effort.  On a large project, with lots of main and side-line
> developers,
> I can see how that makes sense.  But for kroc I'd go for something like:
>

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?


>  - commits straight to master for small/own changes (e.g.
> fixes/updates/etc.).
>
  - in a branch if changing chunks of others' code, or widespread changes
> that
>    may have knock-on effects in other builds, and pull-request in so
> people get
>    a chance to look (but for mainstream developers, I wouldn't see
> self-pulling
>    as a problem).
>  - in a fork for external bodies and pull requests for changes coming in
> from
>    outside (e.g. someone developing a new module for something or other, or
>    supporting another TVM arch, etc.).
>

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?


>
> > 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.
The commit author should know/mark when a commit is a feature or a bug fix
so the overhead of this isn't huge.


>
> > If we want a new feature, or master and 1.6 diverge so far that we can no
> > longer cherry-pick bug fixes we make a new branch from master and bump
> the
> > 6.
>
> I'd save 1.6 -> 1.7 type moves for big changes, and 1.6.0 -> 1.6.1 for
> lesser
> things, like new modules, new features (if at all).
>

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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.concurrency.cc/pipermail/developers/attachments/20130424/1836399b/attachment-0001.htm>