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
> b) It's much less tempting to start experimental and highly unstable
> branches
> c) You can get a very similar effect by adding remotes to your own repo.
> d) It only very slightly simplifies an unusual case (what's developer
> X working on today?).
>
> Less tempting
> ------------------
> Just as a minor example, here's my nipy branch list:
>
> https://github.com/matthew-brett/nipy/branches
>
> Lots of crap in there; I just made a branch with a single extra commit
> that I may well throw away, the branch I'm currently working on:
>
> https://github.com/matthew-brett/nipy/tree/fmristat-test-refactor
>
> - I am constantly rebasing and reorganizing while I try to work out
> what I'm doing. I'd think much harder about that if I thought other
> people were expecting to pull down all my stuff. Thinking harder =
> slower coding (for me at least :))
>
> Similar effect
> ----------------
>
> - I'd like to see what Gael and Jonathan Taylor are up to from time to
> time:
>
> Once:
> git clone g...@github.com:matthew-brett/nipy.git # origin remote
> git remote add gael git://github.com/GaelVaroquaux/nipy.git
> git remote add jonathan git://github.com/jtaylor/nipy.git
>
> >From time to time:
> git fetch --all
>
> - same effect, and it allows me to chose who I'm following. But
> actually, I very rarely do that in the abstract, I look when they tell
> me to look at something, and I'm pretty sure it's the same for them
> and my stuff.
>
> See you,
>
> Matthew
>
>
I agree with Matthew here, but I could see a possible hybrid approach.
Let's say we were a more organized group (I will wait for the laughter to
die down...), then one could imagine having branches with names of approved
milestones/goals/planned features for the next release. The names would
convey the features actively being worked on, and provide a focus for us.
When a feature is finished, we then merge into master. If a feature is not
ready for prime-time, then we can just hold it off.
Just a thought,
Ben Root
------------------------------------------------------------------------------
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
