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.


Reply via email to