It occurred to me that it's also possible to file pull requests very early on while working on a branch. This would make these branches that others may care about more visible. We would just want some convention to say "wait -- this branch isn't done yet, don't merge".
Mike On 09/06/2011 11:38 AM, Michael Droettboom wrote: > I think most of the points being made here are valid. However, a common > occurrence (at least for me) is for a user to struggle against a bug > that I'm currently working on in one of my branches. Looking at the > main repository, it isn't very discoverable that a solution may already > exist, and the user can waste time wondering if it's a bug or user error > etc. Perhaps a compromise between these two approaches would be to have > a wiki page which is a directory of any branches that developers > consider interesting and want to point people toward? Maybe that's just > creating busy work, of course. > > Mike > > On 09/01/2011 05:07 AM, Fernando Perez wrote: >> On Wed, Aug 31, 2011 at 20:16, Matthew Brett<matthew.br...@gmail.com> >> wrote: >>> 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?). >> Limited internet access here, so no time for a long discussoin... Just >> to say that I'm totally in agreement with Matthew here. >> >> We only make branches in the main ipython repo under exceptional >> circumstances, when there's a major piece of work that requires >> multiple-developer commit collaboration to beat into shape and >> cross-pulling from personal repos would just get annoying. But once >> those are ready and merge we delete them as visible branches right >> away. >> >> For example, since we moved to github, we've only done this *twice*: >> once for the big parallel rewrite, and once for the notebook work. >> Both of these were *major* efforts that took months to shape up, so it >> made sense to have them in there. But we make such a decision only >> for such special cases, otherwise following the workflow Matthew >> points out seems to work really well. >> >> Once you get into the habit of using multiple remotes to get a handle >> of an entire team's worth of contributions to a project, you realize >> how simple and effective it is. >> >> Cheers, >> >> f >> >> ------------------------------------------------------------------------------ >> 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 > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA ------------------------------------------------------------------------------ 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
