[CCC DEV] Branch question/confusion

Martin Ellis ellism88 at gmail.com
Wed Apr 24 16:53:58 BST 2013

I have started a page, damn I sound draconian when I write it out :p


On Wed, Apr 24, 2013 at 4:29 PM, Matt Jadud <matt at jadud.com> wrote:

> Hi Martin,
> I've slowly learned to bow to process.
> Throw a few notes in the wiki, and I'll follow whatever you suggest. I
> agree that a clear process is good, and it doesn't sound too onerous to me.
> We can tweak it as we need to, but starting with something clear is good,
> both for us and others. I'll tweak/ask questions about the notes until I'm
> clear, which will probably suffice for most people out there in terms of
> clarity.
> This will also be good for ugrad students as I bring them through the
> project, so yes, lets write something down, and edit from there. (That is,
> if Fred, Adam, or anyone else has some suggestions/comments, it will be
> easier to talk about some linear notes, as opposed to continuing the
> threaded conversation.)
> I'm only suggesting you throw the notes in the wiki (or anywhere you like)
> because it will be easier for us to nudge it around from there. I am
> guessing that we're all, by-and-large, cool with the level of process
> you're suggesting. It might represent learning in some ways, or a slight
> change of practice, but it doesn't sound painful.
> Cheers,
> Matt
> On Wed, Apr 24, 2013 at 10:52 AM, Martin Ellis <ellism88 at gmail.com> wrote:
>>> 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.
>> _______________________________________________
>> developers mailing list
>> developers at concurrency.cc
>> http://lists.concurrency.cc/mailman/listinfo/developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.concurrency.cc/pipermail/developers/attachments/20130424/1f11cd4c/attachment.htm>

More information about the developers mailing list