On Wed, Aug 31, 2011 at 10:16 PM, Matthew Brett <matthew.br...@gmail.com> wrote: > Yo, > > On Wed, Aug 31, 2011 at 7:54 PM, John Hunter <jdh2...@gmail.com> wrote: >> github workflow: this seems to present a different workflow than that >> espoused in gitwash used by mpl and other projects >> >> http://scottchacon.com/2011/08/31/github-flow.html >> >> I like the idea of lots of feature branches off upstream/master and >> master always being deployable (nightly builds?). What is the >> advantage of core devs working in their own forks, as we currently do, >> over working on feature branches off of >> https://github.com/matplotlib/matplotlib? Seems like a lighter-weight >> approach that works, and it would probably make it easier for users to >> follow mpl development by tracking the mpl repo and all the branches >> off of it, rather than having to pull in the various dev's forked >> branches. > > The issue being - why not have all the development branches in the > same main repo? > > Because: > > a) Everyone needs write access to the main repo
I'm thinking about core devs here -- they all have write access to the main repo. Users and non core devs can continue with the fork approach. > b) It's much less tempting to start experimental and highly unstable branches This can still be done in forks. And experimental and unstable branches are a minor threat -- they may increase the signal-to-noise, but dead branches can be pruned and users and devs can probably get a pretty good feel for which are active by looking at the "last update" time on the branch list. > c) You can get a very similar effect by adding remotes to your own repo. Yes, I do this and I'm sure other mpl developers do to, but you need to know who to follow, which is harder for the casual developer or user. By having the core devs develop in feature branches off of upstream, it makes it easier for users and other developers to see what all the other cores devs are up to w/o having to specify who to track. They track the main repo, they see the main work of the core devs as they come and go. > d) It only very slightly simplifies an unusual case (what's developer > X working on today?). I think it simplifies it dramatically, because the average user or part time developer doesn't have to ask "which developers should I follow?" and do the work to add them to externals. They can assume that by tracking the upstream branches, they see the important non-experimental branches the core developers are working on. It is easy to follow developer X if you know a priori who X is. But since 95% of the work is done by people who have write access to the central repo, and 95% of the users want to track this, it makes sense to me to push more of the workflow into the central repo, while still supporting external contributions via pull requests from forks. Maybe I'm missing something, but I feel the gitwash workflow is more complicated than it needs to be and this article re-inforces that view. JDH ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
