<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'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'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'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' 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'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>
> Branching and tagging for release is separate.<br>
> We make a 1.6 branch off of master, this is not committed to directly, all<br>
> new work goes into master, we just cherry-pick bug fixes from master.<br>
<br>
</div>Yep. Again, I wouldn't object to developers cherry-picking their own fixes/updates<br>
into the stable branch (otherwise we'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'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>
> If we want a new feature, or master and 1.6 diverge so far that we can no<br>
> longer cherry-pick bug fixes we make a new branch from master and bump the<br>
> 6.<br>
<br>
</div>I'd save 1.6 -> 1.7 type moves for big changes, and 1.6.0 -> 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>
> Tags signify releases on a branch. They should be done at stable points.<br>
> 1.6.0 is the first stable point on the 1.6 branch.<br>
> We make new tags after pulling in fixes from master and when we think it is<br>
> stable.<br>
> We Tag often...?<br>
<br>
</div>I'd save tagging for when 1.6.0, 1.6.1, ... become available. When telling<br>
people to get the stable kroc, they'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>