[CCC DEV] Branch question/confusion

Matt Jadud matt at jadud.com
Wed Apr 24 16:29:17 BST 2013


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/031e473b/attachment.htm>


More information about the developers mailing list