Hi, On Wed, Aug 31, 2011 at 8:37 PM, John Hunter <jdh2...@gmail.com> wrote: > 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.
Will you document both workflows? Will the core-devs have to keep track of two working sets that belong to them, some in forks and some on the main repo? Will you document what criteria the core-devs should use for this transfer? I suppose I can see that the one-repo workflow would make sense for 20 people in the same building working on a private repo, but, for y'all, with people coming in all the time saying, hey, I've got a patch, and much less direct contact between the developers, I'd be really surprised if it wasn't substantially more complicated than what you have. >> 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. Right - or follow Benjamin's suggestion, which seems very reasonable, of having one or two sensible branches in your main repo, like, master (maybe always deployable) and feature-several-of-us-are-working on, and just do pull requests from forks into whichever one make sense. >> 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. I'm the core dev on a couple of projects, and I almost never want the thing that you want, which is to see what everyone is working on right now. I don't think I've knowingly come across the user who is a) not up to adding remotes to the repo and b) will benefit from seeing or want to see what everyone is working on. I'm not saying they aren't out there, it's just not something I've considered. > 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. I'm missing it though - isn't the article describing a work-flow substantially the same as gitwash? That's what I meant in my reply, the one-repo thing is - as far as I can see - only a minor difference from what you have. Is that what you meant? Just the one-repo thing? See you, Matthew ------------------------------------------------------------------------------ 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
