[IPython-dev] (slightly OT) tags vs. branches

[David Warde-Farley]

Fernando,

Thanks for such a detailed reply and so quickly!

On 2011-08-17, at 1:26 AM, Fernando Perez wrote:

> An additional benefit of using tags is that github automatically
> creates downloadable tar/zipballs for any tag, so you get an automatic
> download website by the mere act of pushing a tag.

Neat, I had forgotten about that. Although I notice you also have a (presumably setuptools-generated) tarball on PyPI. Does it complicate things any to have two similar-but-different source distributions? (I'm thinking in terms of any generated documentation, etc.)

> Now, we only create numbered branches for cases when we do maintain a
> release series in parallel with the main development. That was the
> case for the 0.9.x and 0.10.x series, simply because what we now call
> 0.11 took forever to get into shape, and it was important to still
> provide users with fixes to the released IPython while we cooked 0.11.
> But now that those branches are finished, we can get rid of them (to
> keep the repo tidy) and simply leave the tags as reference points of
> when the release was made (Min is actually going to do that cleanup
> soon).

Ah, okay. Got it. This was the part I wasn't clear on.

> The other case when we do create extra branches on the repo is when
> there is a major feature that requires extensive collaborative
> development where we may want multiple core devs to be able to write
> directly.  We did that last summer with some of the work that led to
> 0.11, and now we have the htmlnotebook branch for the same reason.
> But once it gets merged, we'll delete the branch from the repo, as in
> this case it's strictly convenience.

Gotcha. Yes, that does seem like a good case for core-repo branches.

> I should add (re. Aaron's comment) that in IPython we do try to review
> most code, except for very small changes.  We only commit directly
> typically things that fix a bug in a small, localized change and when
> the bug is nasty, such as one that Aaron happened to report yesterday
> that crashed IPython altogether.  I whipped up a localized fix and
> committed it right away.  But in general, even core devs with commit
> access submit all our work for review via pull requests, as you can
> see from the pulls page:
> 
> https://github.com/ipython/ipython/pulls
> 
> which has PRs from pretty much everyone.

Yep, this is the model I have been quite impressed with in my interactions with IPython, and the model we're planning to follow for Theano. One of our core developers had set up an instance of ReviewBoard ( http://www.reviewboard.org/ ) but it was basically set up (via some hacks) to review code *after* it had gone into the trunk, which made little sense to a lot of us, and was a usability nightmare. We're hoping GitHub will help us get our reviewing house in order.

> In my mind, review is always better than not, but with such a small
> team we also use some judgment in allowing occasional changes to go in
> directly when waiting for review would otherwise just paralyze things.
> We basically try to strike a balance between maximizing review (which
> pretty much always increases code quality) and maintaining good
> throughput.

> I hope this helps, feel free to ask further.  

It absolutely helps, thanks very much.

> And glad to see Theano on github!

So am I, very much so. :)

David