On Mon, Nov 26, 2012 at 9:53 AM, P Purkayastha <ppu...@gmail.com> wrote: > On 11/27/2012 01:19 AM, Robert Bradshaw wrote: >> >> 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 >> > > > I think the Sage community could quickly expand and there could be tens, if > not hundreds, of git development branches once the switch to git occurs. It > would be quite hard to keep track of all the different branches and the > individual modifications that people have in their forks. I looked up scipy > right now, and that itself has over 500 watchers and 200 forks. The > situation is the same for matplotlib, and almost the same for mathjax. It > would be nice to see how those communities cope with such a huge number of > forks and development branches. > > What I describe below is one way I think we could have access to the many > individual patches and "alpha-quality" code people might have. > > To encourage people to contribute back high-quality version of their > research projects into Sage, one thing that could be done is to enable a > wikipage where the developers can mention or list their current > project/unpolished code. The hope is that such a model will help the person > get feedback for his/her code and the person can get encouraged to > eventually submit it to trac and include it with Sage. It often happens with > me that I get a bit more motivation to finish/polish my work once someone > asks me for it - the feedback helps me know that the code might be useful > for someone else too! I wonder if other people here have faced similar > situations.
I think publishing git branches should be easy enough (read, a one-liner from sage). Getting noticed/getting feedback is the hard part. Another crazy idea: encourage uploading of unfinished code with optional nag reminders. I'd rather people upload code without tests and people start reviewing it than hold onto it until they "get around to" adding all the examples. Just having public "todo" lists can be motivation to finish something up, or bug someone about finishing something up. > The wiki page could be similar to the one used in > http://godashboard.appspot.com/ (that's not a wiki page though). There, a > lot of projects are listed; though I am not sure how it is maintained. The > positive aspect of having a wiki page is that any developer who has been > given access to it can edit it and list his/her project or code. This could > also help to consolidate all the different and separate development that > goes on in psage and combinat, into one place where you can access all those > links and sub-projects (I wasn't even aware of psage for instance). > > A big question is, of course, how can one get easy access to all these > development code. I don't have a solution for this. > > About getting trivial patches merged in - I don't know how it can be > effected. One option is to use the online editing facility of github itself, > which has already been used a bit in the notebook development. I don't know > where the Sage library will be hosted though. Yep. Or at the very least: 1. Notice issue. 2. One-liner to become pristine version of code. 3. Fix. 4. Send for review [also a one-liner] 5. One-liner to get back to where you were, with or without this edit. Testing may optionally happen on your machine in the background, and the patchbot will pick it up. Step (2) would also include pulling someone's open ticket, so rather than responding with "you forgot a period" you just add it in. (Online is even better.) - 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.
