<div dir="ltr">I have started a page, damn I sound draconian when I write it out :p <div><br></div><div><a href="https://github.com/concurrency/kroc/wiki/Best-practices">https://github.com/concurrency/kroc/wiki/Best-practices</a><br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 24, 2013 at 4:29 PM, Matt Jadud <span dir="ltr"><<a href="mailto:matt@jadud.com" target="_blank">matt@jadud.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Martin,<div><br></div><div>I've slowly learned to bow to process.</div><div><br></div><div>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.</div>
<div><br></div><div>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.) </div>
<div><br></div><div>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.</div>
<div><br></div><div>Cheers,</div><div>Matt</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Apr 24, 2013 at 10:52 AM, Martin Ellis <span dir="ltr"><<a href="mailto:ellism88@gmail.com" target="_blank">ellism88@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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><div><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><div>Yes this is extra work, it also leads to MUCH better code from everyone.</div><div>Code review sounds a pain, but usually isn't, how about just trying this for a while?</div>
<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>
- 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>
- 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><div>I really disagree with this. All work should be done in a branch/fork and pulled.<br></div><div>because:</div><div>- This is how git is designed (well pulls are a shortcut around passing around patch sets).</div>
<div>- Small changes are rarely small.</div><div>- Promotes testing before making it to master.</div><div>You can make pull request for indervidual commits if you work in your own master.</div><div>
<br></div><div>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> </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>
<div><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><br></div></div><div>Cherry picking bug fixes should be done into the release branch at the same time as they are committed to master.</div>
<div>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> </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><div>
<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><div>Ok, I worded this badly, new branches should really be made when we want to introduce backwards comparability breaking changes.</div>
<div>
<div><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><div>
<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></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">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>
<br></div></div><div class="im">_______________________________________________<br>
developers mailing list<br>
developers@concurrency.cc<br>
<a href="http://lists.concurrency.cc/mailman/listinfo/developers" target="_blank">http://lists.concurrency.cc/mailman/listinfo/developers</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div>