github workflow: this seems to present a different workflow than that
espoused in gitwash used by mpl and other projects
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
The issue being - why not have all the development branches in the
same main repo?
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
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
On Wed, Aug 31, 2011 at 10:16 PM, Matthew Brett <matthew.brett@...149...> wrote:
On Wed, Aug 31, 2011 at 7:54 PM, John Hunter <jdh2358@...149...> wrote: