<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div id=":1mv"><div class="im"><br>
</div>As Matt identifies, doing work in our own forks branches then making pull requests<br>
requires that someone (other than the committer) gets involved.  In many cases<br>
that&#39;s extra effort.  On a large project, with lots of main and side-line developers,<br>
I can see how that makes sense.  But for kroc I&#39;d go for something like:<br></div></blockquote><div><br></div><div style>Yes this is extra work, it also leads to MUCH better code from everyone.</div><div style>Code review sounds a pain, but usually isn&#39;t, how about just trying this for a while?</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1mv">
 - commits straight to master for small/own changes (e.g. fixes/updates/etc.). </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div id=":1mv">
 - in a branch if changing chunks of others&#39; code, or widespread changes that<br>
   may have knock-on effects in other builds, and pull-request in so people get<br>
   a chance to look (but for mainstream developers, I wouldn&#39;t see self-pulling<br>
   as a problem).<br>
 - in a fork for external bodies and pull requests for changes coming in from<br>
   outside (e.g. someone developing a new module for something or other, or<br>
   supporting another TVM arch, etc.). </div></blockquote><div><br></div><div>I really disagree with this. All work should be done in a branch/fork and pulled.<br></div><div style>because:</div><div style>- This is how git is designed (well pulls are a shortcut around passing around patch sets).</div>

<div style>- Small changes are rarely small.</div><div style>- Promotes testing before making it to master.</div><div style>You can make pull request for indervidual commits if you work in your own master.</div><div style>

<br></div><div style>We also want other people to work on this project right?  We should impose the same rules on ourselves as those who help us?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div id=":1mv">
<div class="im"><br>
&gt; Branching and tagging for release is separate.<br>
&gt; We make a 1.6 branch off of master, this is not committed to directly, all<br>
&gt; new work goes into master, we just cherry-pick bug fixes from master.<br>
<br>
</div>Yep.  Again, I wouldn&#39;t object to developers cherry-picking their own fixes/updates<br>
into the stable branch (otherwise we&#39;re likely to generate backlog).</div></blockquote><div style><br></div><div style>Cherry picking bug fixes should be done into the release branch at the same time as they are committed to master.</div>

<div style>The commit author should know/mark when a commit is a feature or a bug fix so the overhead of this isn&#39;t huge.</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div id=":1mv"><div class="im">
<br>
&gt; If we want a new feature, or master and 1.6 diverge so far that we can no<br>
&gt; longer cherry-pick bug fixes we make a new branch from master and bump the<br>
&gt; 6.<br>
<br>
</div>I&#39;d save 1.6 -&gt; 1.7 type moves for big changes, and 1.6.0 -&gt; 1.6.1 for lesser<br>
things, like new modules, new features (if at all).<br></div></blockquote><div><br></div><div style>Ok, I worded this badly, new branches should really be made when we want to introduce backwards comparability breaking changes.</div>

<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1mv"><div class="im">
<br>
&gt; Tags signify releases on a branch.  They should be done at stable points.<br>
&gt; 1.6.0 is the first stable point on the 1.6 branch.<br>
&gt; We make new tags after pulling in fixes from master and when we think it is<br>
&gt; stable.<br>
&gt; We Tag often...?<br>
<br>
</div>I&#39;d save tagging for when 1.6.0, 1.6.1, ... become available.  When telling<br>
people to get the stable kroc, they&#39;ll be downloading the kroc-1.6 branch,<br>
rather than a particular tag, so should get all the fixes-to-date.</div></blockquote><div> <br></div></div>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.</div>

<div class="gmail_extra" style>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.<br><br></div></div>