Hi,
Yo,
github workflow: this seems to present a different workflow than that
espoused in gitwash used by mpl and other projectshttp://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
GitHub - matplotlib/matplotlib: matplotlib: plotting with Python? 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
ยทยทยท
On Wed, Aug 31, 2011 at 8:37 PM, John Hunter <jdh2358@...149...> wrote:
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: