This is somewhat a continuation of the "permutations...again" thread, but I think the topic is much broader than that. Over time contributing Sage has become increasingly bureaucratic with the goal (I hope) of getting higher-quality more-stable code.
Raising the bar on Sage code quality creates this limbo area of code that's good enough to be shared/built upon, but not good enough to be included in Sage. The combinat folks seem to have realized this from the beginning (hence the combinat queue) and this was also the motivation for psage http://purple.sagemath.org/goals.html (see especially "Change the development model") I don't see this changing anytime soon. On the other hand, it's very important that code like this not get lost, and there is value added by taking code to the next level (e.g. http://sagemath.blogspot.com/2011/12/when-using-sage-to-support-research.html ) If something like the salvus model http://sagemath.blogspot.com/2011/11/is-time-ripe-for-httpsagenbcom.html takes off, and I'm optimistic it will, that might open up opportunities for others to do this work, or (more interestingly) researchers to secure funding that allows them to put on their developer hat as part of their day job rather than squeezing it in on nights and weekends between teaching and research. (Of course it would also be nice of the academic landscape shifts to give credit to these worthwhile endeavors but that's not going to happen overnight.) So, what can we do? We're looking to shake up the development model next year, I think it'd be useful to see how to best leverage this "alpha-quality" research code from Sage *and* provide an easy (or at least no-harder-than-necessary) way to migrate such code into Sage itself once it's ready (with incentives). What tools, models, and conventions would be conducive to this? The intent seems to be to support sage-combinat-like queues or patch overlays, but is this the best model? (It works, but it seems to be a lot of overhead and has its drawbacks.) Long-lived git branches? Independent forks in separate namespaces (like psage)? A very stable sage-core with various (optional?) overlays? (Would this allow for an even more "sound software engineering practices" base without the tension to apply unrealistically high bars everywhere? I've see good patches or even bugfixes not go in for ages due to trivial documentation issues... (being able to *easily* make trivial chances or build upon the work of others will help here)) Decorators for "alpha-quality" methods that don't exist in the "stable" model? Any other ideas? - Robert -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.