If a group of people want to work on an isolated feature they could always fork Sage and review each other's stuff as they go along. The only downside is that they can't use use our trac to split it into subtasks as our git viewer would always show the entire branch, not the subtask branch. But there are lots of other options, from just plain git to github's web interface.
As a corollary, if you are a single dev working in isolation on a big and non-modular chunk of code then you need help ;-) On Thursday, April 2, 2015 at 1:18:24 PM UTC+2, Thierry (sage-googlesucks@xxx) wrote: > > Hi, > > during the talk about coding theory rewrite at sd66, we were discussing > about the groups of people starting to develop some code for Sage and > waiting to have something ready and clean to start submitting (e.g. > matroids, finite state machines, manifolds), which could lead to a > patchbomb that will sometimes just not be reviewed. There was also some > GSOC projects that were not merged after a long period of separate > development still waiting for a review. > > One reason invoked was the fear of letting something entering Sage, and > then not beong able to modify it easily, because of deprecation policy. > > What should be the right way to avoid that ? > > Should we offer a kind of test-sage ? Should we propose a kind of > proprecation warning that says "This code is very new and its design is > not > foolproof. Its design might change.". > > What do you think ? > > Ciao, > Thierry > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
