Re: [sage-devel] Re: bug wranglers
On Wed, Oct 20, 2010 at 10:24 PM, William Stein wst...@gmail.com wrote: On Wed, Oct 20, 2010 at 9:33 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Wed, Oct 20, 2010 at 5:10 AM, Johan S. R. Nielsen j.s.r.niel...@mat.dtu.dk wrote: I think that Burcin's suggestion is excellent. Development of Sage should definitely move towards more structure, documentation, testing and other software engineering practices, but as for any Open Source- project, these things should come naturally as the project grows and matures; as has already happened with Sage a lot, it seems (for a relative new-comer like me). To require too much too soon would kill the joy of working on the project and thus kill the project itself. +1 I have definitely seen that the level of bureaucracy has going up, especially in the last year or two, has turned off a lot of potential and even former developers. Another +1. The level of bureaucracy has gone up so much in the last year that it has very seriously turned off me. +1, and me too. The focus on software engineering and testing can certainly be good for quality (though that's not an immediate or certain implication), but the problem is that too much emphasis on it has a significant chilling effect on contributions. The lag time between hacking out some code and getting it in is way too high these days discourages contribution and sucks up a lot of development time and energy with endless rebases and waiting. +1 It kills a large portion of potential contributions of code for advanced research, perhaps 80% or more. I've talked to so many people about this in the last few months... Yup. And though we all want to produce bug-free code, holding that up as the primary objetive (as opposed to producing useful code) I think dissuades people from submitting or refereeing code. Also, anybody who has significant experience with software engineering knows that producing bug-free code is a recipe for producing almost no code. Agreed. I was talking to somebody today who works on Microsoft Windows (actually implementing the OS there), and who has also written a lot of code for Sage (at a research level -- advanced number theory stuff). He said internally at Microsoft code gets into the system, and out getting used by a lot of people (internally) much more quickly than with Sage. Instead of the very all or nothing model that we tend to have, they have many levels of review that code goes through. Sage would benefit from something similar. That's basically what http://purple.sagemath.org/ is about: a way to get code out there and distributed, used, etc., but without all the bureaucracy. As an example, I'll sit down this coming Tuesday with Sal Baig, and get his and Chris Hall's library for computing with elliptic curves over function fields into PSAGE, and have it be in the next release. That's code that isn't stable yet and is mainly for research. For a year they have been trying to get it into Sage, but it just isn't happening, since they care and know much more about *using* the code for research purposes, than about how to make a proper makefile/autoconf setup, so it builds fine on Solaris and OS X 10.4. I think PSAGE will show that the increasingly bureaucratic and plodding way in which code gets into Sage isn't necessarily bad, in the same sense that Debian can be very plodding and bureaucratic, but it still provides a good foundation for many other much more svelte and useful Linux distributions. I'm not sure I have a solution, but one thing that keeps coming to mind is that Sage is trying to span several audiences with different goals and criteria, and perhaps the various audiences would be best met by a stable vs. unstable model like Debian. Purple sage is an extreem move in this direction (more like Debian experimental)--I can certainly see the attraction and value, but I just hope it doesn't become an incompatible fork. A difference from debian experimental is that PSAGE starts by removing over 20 standard packages from Sage. In fact, so far, that is essentially *all* that PSAGE is. Also, my intention is that most Python code in PSAGE go into a different Python module than the sage one. Burcin's suggestion seem to fit this curve pretty well at this time. New developers and bugfixers -- with little overview of the monster that is Sage -- would feel more confident in reporting and fixing bugs if there was a feeling that there was someone (or a group of someones) with overview and structure. If some enthusiastic veterans could be found and agree on the exact model of this, I think it would improve bug-tracking and -fixing in a number of ways: - overview of bugs, their severity and class (by cleaning up, removing duplicates, collating related tracs, and reclassifying) - better classification of bugs by everyone else (by monkey-see- monkey-do) - better overview over bugs to
Re: [sage-devel] Re: bug wranglers
On Wed, Oct 20, 2010 at 10:24 PM, William Stein wst...@gmail.com wrote: On Wed, Oct 20, 2010 at 9:33 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Wed, Oct 20, 2010 at 5:10 AM, Johan S. R. Nielsen j.s.r.niel...@mat.dtu.dk wrote: I think that Burcin's suggestion is excellent. Development of Sage should definitely move towards more structure, documentation, testing and other software engineering practices, but as for any Open Source- project, these things should come naturally as the project grows and matures; as has already happened with Sage a lot, it seems (for a relative new-comer like me). To require too much too soon would kill the joy of working on the project and thus kill the project itself. +1 I have definitely seen that the level of bureaucracy has going up, especially in the last year or two, has turned off a lot of potential and even former developers. Another +1. The level of bureaucracy has gone up so much in the last year that it has very seriously turned off me. The focus on software engineering and testing can certainly be good for quality (though that's not an immediate or certain implication), but the problem is that too much emphasis on it has a significant chilling effect on contributions. The lag time between hacking out some code and getting it in is way too high these days discourages contribution and sucks up a lot of development time and energy with endless rebases and waiting. +1 It kills a large portion of potential contributions of code for advanced research, perhaps 80% or more. I've talked to so many people about this in the last few months... And though we all want to produce bug-free code, holding that up as the primary objetive (as opposed to producing useful code) I think dissuades people from submitting or refereeing code. Also, anybody who has significant experience with software engineering knows that producing bug-free code is a recipe for producing almost no code. I was talking to somebody today who works on Microsoft Windows (actually implementing the OS there), and who has also written a lot of code for Sage (at a research level -- advanced number theory stuff). He said internally at Microsoft code gets into the system, and out getting used by a lot of people (internally) much more quickly than with Sage. Instead of the very all or nothing model that we tend to have, they have many levels of review that code goes through. Sage would benefit from something similar. That's basically what http://purple.sagemath.org/ is about: a way to get code out there and distributed, used, etc., but without all the bureaucracy. As an example, I'll sit down this coming Tuesday with Sal Baig, and get his and Chris Hall's library for computing with elliptic curves over function fields into PSAGE, and have it be in the next release. That's code that isn't stable yet and is mainly for research. For a year they have been trying to get it into Sage, but it just isn't happening, since they care and know much more about *using* the code for research purposes, than about how to make a proper makefile/autoconf setup, so it builds fine on Solaris and OS X 10.4. I think PSAGE will show that the increasingly bureaucratic and plodding way in which code gets into Sage isn't necessarily bad, in the same sense that Debian can be very plodding and bureaucratic, but it still provides a good foundation for many other much more svelte and useful Linux distributions. I'm not sure I have a solution, but one thing that keeps coming to mind is that Sage is trying to span several audiences with different goals and criteria, and perhaps the various audiences would be best met by a stable vs. unstable model like Debian. Purple sage is an extreem move in this direction (more like Debian experimental)--I can certainly see the attraction and value, but I just hope it doesn't become an incompatible fork. A difference from debian experimental is that PSAGE starts by removing over 20 standard packages from Sage. In fact, so far, that is essentially *all* that PSAGE is. Also, my intention is that most Python code in PSAGE go into a different Python module than the sage one. Thus psage will be a superset of a subset of sage. Do you envision a migration path of code from psage to sage? (Perhaps not instigated or executed by the original authors of the code of course.) Would it be easy to install the missing pieces into a psage setup, or, conversely, install the new parts of psage on top of Sage? That being said, the sage-combinat model seems like it would be a huge amount of work to manage, but is nice for the end user. (Doesn't solve the messiness of ugly build problems with arcane spkgs...) First, have the initial status of tickets be some pre-new stage. (Something like unclassified.) This woud make it so you don't have to be an expert to classify a bug. Volunteers could go and look at all
Re: [sage-devel] Re: bug wranglers
On Wed, 20 Oct 2010 13:04:56 +0100 Dr. David Kirkby david.kir...@onetel.net wrote: To make matters easier to follow, lets look at Burcin's proposals. http://groups.google.com/group/sage-devel/msg/40d2af34d86586de?hl=en and consider them, here in an abbreviated and expanded form. 1) Burcin said: Many of the bugs on trac are duplicates and could be closed. He is probably right. Some are undoubably wrongly categorised, but from a personal perspective I often don't have a clue what to file them under anyway. Perhaps for those of us without maths degrees, the categories could be more explicit. But even that is not a full solution. This is exactly one of the points I wanted to address with the proposal. Even if we make the components on trac clearer, new users won't be able to choose one comfortably. It is far better to let someone who knows (B-Team member) do this (hopefully soon) after the bug is filed. BTW, after practicing with a few bugs, this should be fairly straightforward to do. Looking through the Sage library code to find the lines with the problem or trying to track down the cause of a problem is a great way to get familiar with the layout and structure of Sage, the coding guidelines etc. snip 2) Burcin said: We might be able to overcome this with a bug-wrangler team, people who volunteer to ... IMHO, If the categories could with a tick box, then this step could hopefully be removed for future bugs. The right people will automatically be notified. We need however to have a category I need helping chosing the right categories. That would be especially useful for those of us with a non-maths background, but I think to others too, as parts of Sage are so specialised, I doubt I'm the only one who struggles to know what to categorise things under. Note that since we changed trac to let users get accounts themselves, we let anyone file bug reports. There is usually quite a lot of work that needs to be done before a bug can be fixed. We need - full examples on how to reproduce it, - check if it is there on the latest release, - see if it occurs on all platforms, - check if it was reported before, - find out who would know how to fix it If you make a few people who know the Sage library well do all this, then they won't have much time to actually fix the bugs. The items listed above don't require so much experience with Sage. They can be done by new developer candidates. The Sage project needs to train new developers, since the veterans are already overloaded and some have been lost to burnout already. I suggest this as one way to train new developers. I think the lack of too many sign me up to do this shows there's not likely to be the number of developers taking this on. They might be more attracted to do it if they realise that it only needs to be done once, and new bugs would automatically be assigned to the right person. Considering the general lack of enthusiasm on the lists recently, I would say the amount of response my suggestion got quite successful. Even if you understand what the bug is, the chances are you don't know who is the best person to look at the bug. Given a reproducible bug, developers can easily tell who might be able to fix a bug. However this takes some time, so many people might even be reluctant to go through these steps if they don't feel like actually fixing the problem. See my response to Jeroen Demeyer's message for a longer answer to this. Several categories have nobody at all assigned to them. Since I'm an admin on trac I can see this. These include: * cygwin * debian-package * distribution * dsage * experimental package * factorization (this one *really* surprises me) * msvc * optional packages * packages * performance * PLEASE CHANGE * relocation I suggest merging - packages, optional packages, experimental packages under the title packages and - AIX or HP-UX ports, build, cygwin, debian-package, distribution, FreeBSD, msvc, porting, relocation, solaris, spkg-check under the title distribution The mathematical components can probably be merged as well. For example, I agree that factorization stands out quite a bit. :) Thanks for bringing the discussion back on topic. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: bug wranglers
On Wed, 20 Oct 2010 15:08:12 -0700 William Stein wst...@gmail.com wrote: On Wed, Oct 20, 2010 at 7:41 AM, kcrisman kcris...@gmail.com wrote: snip Not to be overly pessimistic, but one metric we do not collect, but Google do for us, is the number of posts each month to sage-devel. There has been a very dramatic falloff this year compared to all other years. http://groups.google.com/group/sage-devel/about?hl=en http://groups.google.com/group/sage-support/about?hl=en I think the number of posts to sage-support is more worrying than to sage-devel, but I believe the combination rather shows that we are unlikely to find a lot of developers taking on Burcin's proposals. Hmm, that is interesting. I don't know if it means anything (it might), but it is interesting. Thanks for that. I take it to mean that Sage is now a mature project with roughly the right number of developers. I strongly disagree with this. Although I see that you also support the fact that we need more developers as a follow up to this comment. I am quite disappointed by the fact that the sage-devel list has turned out to be a place to discuss how to compile mathematical software on various platforms, instead of how to do mathematics with the computer. This is partly because there are now specialized lists such as sage-algebra, sage-combinat-devel, sage-nt. Unfortunately, those lists are not used much either. I agree that the distribution part of Sage is very important, since it gives a lot people easy access to many open source mathematics packages. The developers and the maintainers of these packages should have a platform to share experiences and learn from each other. However, I don't think sage-devel is the right place for this. Perhaps a sage-porting list would be more useful. That said, everybody should keep recruiting new people as aggressively as they can, since developers come and *go*, as they have children, have to finish a thesis, get involved in other projects, finish making the contributions to sage they find interesting, etc. +1 Not only because people come and go. Sage is getting larger everyday and many of the current developers are already spending more time on it than they should. (I should be writing my thesis ATM.) Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: bug wranglers
On Wed, 20 Oct 2010 22:24:13 -0700 William Stein wst...@gmail.com wrote: On Wed, Oct 20, 2010 at 9:33 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Wed, Oct 20, 2010 at 5:10 AM, Johan S. R. Nielsen j.s.r.niel...@mat.dtu.dk wrote: I think that Burcin's suggestion is excellent. Development of Sage should definitely move towards more structure, documentation, testing and other software engineering practices, but as for any Open Source- project, these things should come naturally as the project grows and matures; as has already happened with Sage a lot, it seems (for a relative new-comer like me). To require too much too soon would kill the joy of working on the project and thus kill the project itself. +1 I have definitely seen that the level of bureaucracy has going up, especially in the last year or two, has turned off a lot of potential and even former developers. Another +1. The level of bureaucracy has gone up so much in the last year that it has very seriously turned off me. +1 from me as well. Though I'd say the expectations from the developers have gone up not just bureaucracy, with the requirements to do the jobs that could be automated etc. I see the bug wrangler, or the B-team, as a way of lowering the load on developers, and perhaps a possibility to gain new ones. snip I'm not sure I have a solution, but one thing that keeps coming to mind is that Sage is trying to span several audiences with different goals and criteria, and perhaps the various audiences would be best met by a stable vs. unstable model like Debian. Purple sage is an extreem move in this direction (more like Debian experimental)--I can certainly see the attraction and value, but I just hope it doesn't become an incompatible fork. A difference from debian experimental is that PSAGE starts by removing over 20 standard packages from Sage. In fact, so far, that is essentially *all* that PSAGE is.Also, my intention is that most Python code in PSAGE go into a different Python module than the sage one. We could also think about making Sage leaner, and easier to extend. Then the main Sage team can maintain - Sage-core with these 20 packages removed, which is as easy to install as Sage - Sage with the current mathematics functionality, and maybe more, as an alternative to the M's snip I agree that a big part of the problem is that it's hard to get a big picture of all the bugs being worked on. The idea of a weekly bug-wrangler is an interesting one. I have a simpler proposal (which may be insufficient, but would complement a bug-wrangler's role and is much easier to implement). First, have the initial status of tickets be some pre-new stage. (Something like unclassified.) This woud make it so you don't have to be an expert to classify a bug. Volunteers could go and look at all unclassified tickets and file them appropriately (severity, defect vs. enhancement, component, duplicate, etc.) Of course, there could be a rotating bug-wrangler, but if it was easy enough for a veteran to hop on and categorize a bunch of them in one sitting this might not even be necessary. This is perhaps already provided by: http://spreadsheets.google.com/viewform?key=pCwvGVwSMxTzT6E2xNdo5fA Harald Schilly could probably set things up so more people can wrangle the bugs that come in through that page. I was thinking of formalizing this with the bug wrangler approach. Harald cannot possibly deal with all these. The difference between this and the new issues filed on trac is getting less as everyone can file new issues on trac (even though the trac interface can be intimidating). snip Just out of curiosity, is trac still the best system to use for managing what we're managing? You work at Google and they have their own free http://code.google.com/ thing, which provides similar capabilities to trac, but with integrated code review, the possibility to delete comments (w00t!), etc., native support for Mercurial (which trac barely supports, preferring SVN), easy forking, etc. I have so far little experience with code.google.com, but I'm sort of curious how good it is. I set it up for PSAGE here http://code.google.com/p/purplesage/ since I didn't want to have to manage a whole trac, hg repo, etc., yet again. I have grown very fond of the tracker used by Python recently: http://roundup-tracker.org/ I like the fact that you can do everything via email. This feature would provide an easy way to submit patches you're working on to the issue trackers. We could just hook up to the email functions of mercurial. IIRC, Jason suggested at some point to take a look at http://www.reviewboard.org/ for patch reviews. I am still reluctant to host the project on Google... Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to
[sage-devel] Re: bug wranglers
On 10/21/10 5:55 AM, Burcin Erocal wrote: I have grown very fond of the tracker used by Python recently: http://roundup-tracker.org/ I like the fact that you can do everything via email. This feature would provide an easy way to submit patches you're working on to the issue trackers. We could just hook up to the email functions of mercurial. 8 years ago, I implemented a Roundup-based ticket tracker (after looking at a lot of systems), and was impressed with the configurability. I haven't used ReviewBoard, but it did look interesting. And my 2 cents: I agree with others that something needs to be done to lower the wall again for new contributors. I too have heard or seen new developers be overwhelmed by the amount of time needed to do a simple fix. I've also been slowed down a lot by the time it takes to review a patch, so a big +1 to Robert's work on a build-bot that tests any needs_review ticket automatically. Thanks, Jason -- Jason Grout -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: bug wranglers
On 10/21/10 8:03 AM, Burcin Erocal wrote: The week at a time approach you describe below is too much work for me. I doubt if I could put in 2 hours of work for Sage everyday for a whole week. I do however look at the new tickets on trac from time to time, and wouldn't mind either classifying a few of the new ones properly, or reading emails to see if a new developer has done it properly. Same here. I often look at bugs in categories I'm fluent in to give some initial feedback. I can't commit an entire week to it, though. I could take a day or two. Thanks, Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: bug wranglers
On 10/21/10 5:55 AM, Burcin Erocal wrote: IIRC, Jason suggested at some point to take a look at http://www.reviewboard.org/ for patch reviews. Here is one more possibility, though it may be too formal for our needs: Java Code Review: http://jcodereview.sourceforge.net/ Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: bug wranglers
Very interesting thread, and I'm so pleased William shared some thoughts vis-a-vis PSage. Regardless of whether he's spending more time on PSage right now, I think that for many OSS projects it's difficult to maintain momentum when the lead developer steps back a fair amount. Sage has done quite well during this time, but my guess is that if the BDFL were to make some official pronouncement about cooling it (in some specific way) on the bureaucracy, that would be better than a lot of arguing about it. It would be terrible if Sage lost momentum just at the point where it is achieving much more mainstream recognition. If we can get to the point where the following two things are available (neither of which I am even remotely capable of providing): 1) Double-click Windows app (we have this with Mac) 2) Slightly more robust large-scale server in a box we can just point people to who know NOTHING about admin then I'd feel much more confident about the long-term prognosis for Sage, even if a lot of the research-oriented community had friendly extensions. There would simply be enough additional users that a viable contributor base would be ensured for quite some time. Directly addressing the thread: What impressed me the most about R at the useR! 2010 conference was the automatic build testing for all the (many, many) optional packages. I think most of us want to keep Sage working on a big variety of platforms (I certainly do, for some of the meta-reasons OSS is good), but the sheer time involved without this automation for anything that uses non-Python code (esp. upgrading spkgs) is overwhelming. But this project seems to be further away than 1) and 2) above, which are so close to fruition. - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: bug wranglers
On Thu, Oct 21, 2010 at 1:23 AM, Robert Bradshaw rober...@math.washington.edu wrote: Thus psage will be a superset of a subset of sage. Yes. Do you envision a migration path of code from psage to sage? Yes. (Perhaps not instigated or executed by the original authors of the code of course.) Yes. Would it be easy to install the missing pieces into a psage setup, or, conversely, install the new parts of psage on top of Sage? Yes, and yes. That being said, the sage-combinat model seems like it would be a huge amount of work to manage, but is nice for the end user. (Doesn't solve the messiness of ugly build problems with arcane spkgs...) I want PSAGE to solve for me a similar problem that sage-combinat faces. However, the solution I'm using is different. It is much more flexible and powerful, and can have interesting benefits for Sage due to it helping clarify some of the dependencies of Sage. E.g., the first issue is about exactly how much Sage still depends on Maxima http://code.google.com/p/purplesage/issues/detail?id=1 since Maxima is one of the standard spkg's not in PSage. ... Again, I'm not necessarily claiming Sage itself needs to move that quickly again. This is very difficult technically due to the larger number of platforms supported, the larger test suite, codebase, etc. But something does need to change, or some of the truly brilliant computational mathematics researchers (like Mark Watkins, say) will be unlikely to be drawn in again. For me, PSAGE will accomplish this goal, while allowing me to continue to benefit from the incredibly valuable high quality work that so many people are doing on making Sage a solid, well tested, cross-platform system. I agree, something needs to change, and it makes more sense to create an agile offshoot. I suppose my sweet spot would be where Sage was 2-3 years ago: reviews were in place but usually quite quick, doctests were good but 100% was not required, less worrying about the long tail of operating systems. etc. (I'm probably suffering from golden-age nostalgic blindness a bit here...) Same here. But that may not be what's needed, especially to jumpstart things again. I just don't want to see psage becoming a divergent fork of what Sage was in late 2010, or an enormous amount of effort required to keep the two projects on a track where they can continue to benefit from each other. Neither do I. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: bug wranglers
On 10/21/10 11:23 AM, Burcin Erocal wrote: On Wed, 20 Oct 2010 13:04:56 +0100 Dr. David Kirkbydavid.kir...@onetel.net wrote: Several categories have nobody at all assigned to them. Since I'm an admin on trac I can see this. These include: * cygwin * debian-package * distribution * dsage * experimental package * factorization (this one *really* surprises me) * msvc * optional packages * packages * performance * PLEASE CHANGE * relocation I suggest merging - packages, optional packages, experimental packages under the title packages and - AIX or HP-UX ports, build, cygwin, debian-package, distribution, FreeBSD, msvc, porting, relocation, solaris, spkg-check under the title distribution I don't thinking lumping those lot together under the title distribution would be sensible myself. It's would make finding things of interest even slower. Especially given some of those have people that get notified about specific areas, but don't want to get inundated with tons of messages. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: bug wranglers
On 10/21/10 11:23 AM, Burcin Erocal wrote: On Wed, 20 Oct 2010 13:04:56 +0100 Dr. David Kirkbydavid.kir...@onetel.net wrote: Several categories have nobody at all assigned to them. Since I'm an admin on trac I can see this. These include: * cygwin * debian-package * distribution * dsage * experimental package * factorization (this one *really* surprises me) * msvc * optional packages * packages * performance * PLEASE CHANGE * relocation I suggest merging - packages, optional packages, experimental packages under the title packages But it's a bit silly really, as everything is a package. I wonder if all 3 should be removed myself. and - AIX or HP-UX ports, build, cygwin, debian-package, distribution, FreeBSD, msvc, porting, relocation, solaris, spkg-check under the title distribution I don't thinking lumping those lot together under the title distribution would be sensible myself. It's would make finding things of interest even slower. Especially given some of those have people that get notified about specific areas, but don't want to get inundated with tons of messages. The mathematical components can probably be merged as well. For example, I agree that factorization stands out quite a bit. :) Thanks for bringing the discussion back on topic. Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: bug wranglers
Thanks, very reassuring. Perhaps it would be useful to make that more clear at http://purple.sagemath.org/dsage.html (though that page really seems to be more about the differences rather than relationship between the two projects). On Thu, Oct 21, 2010 at 8:54 AM, William Stein wst...@gmail.com wrote: On Thu, Oct 21, 2010 at 1:23 AM, Robert Bradshaw rober...@math.washington.edu wrote: Thus psage will be a superset of a subset of sage. Yes. Do you envision a migration path of code from psage to sage? Yes. (Perhaps not instigated or executed by the original authors of the code of course.) Yes. Would it be easy to install the missing pieces into a psage setup, or, conversely, install the new parts of psage on top of Sage? Yes, and yes. That being said, the sage-combinat model seems like it would be a huge amount of work to manage, but is nice for the end user. (Doesn't solve the messiness of ugly build problems with arcane spkgs...) I want PSAGE to solve for me a similar problem that sage-combinat faces. However, the solution I'm using is different. It is much more flexible and powerful, and can have interesting benefits for Sage due to it helping clarify some of the dependencies of Sage. E.g., the first issue is about exactly how much Sage still depends on Maxima http://code.google.com/p/purplesage/issues/detail?id=1 since Maxima is one of the standard spkg's not in PSage. ... Again, I'm not necessarily claiming Sage itself needs to move that quickly again. This is very difficult technically due to the larger number of platforms supported, the larger test suite, codebase, etc. But something does need to change, or some of the truly brilliant computational mathematics researchers (like Mark Watkins, say) will be unlikely to be drawn in again. For me, PSAGE will accomplish this goal, while allowing me to continue to benefit from the incredibly valuable high quality work that so many people are doing on making Sage a solid, well tested, cross-platform system. I agree, something needs to change, and it makes more sense to create an agile offshoot. I suppose my sweet spot would be where Sage was 2-3 years ago: reviews were in place but usually quite quick, doctests were good but 100% was not required, less worrying about the long tail of operating systems. etc. (I'm probably suffering from golden-age nostalgic blindness a bit here...) Same here. But that may not be what's needed, especially to jumpstart things again. I just don't want to see psage becoming a divergent fork of what Sage was in late 2010, or an enormous amount of effort required to keep the two projects on a track where they can continue to benefit from each other. Neither do I. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: bug wranglers
On Thu, Oct 21, 2010 at 9:26 AM, Dr. David Kirkby david.kir...@onetel.net wrote: On 10/21/10 11:23 AM, Burcin Erocal wrote: On Wed, 20 Oct 2010 13:04:56 +0100 Dr. David Kirkbydavid.kir...@onetel.net wrote: Several categories have nobody at all assigned to them. Since I'm an admin on trac I can see this. These include: * cygwin * debian-package * distribution * dsage * experimental package * factorization (this one *really* surprises me) * msvc * optional packages * packages * performance * PLEASE CHANGE * relocation I suggest merging - packages, optional packages, experimental packages under the title packages But it's a bit silly really, as everything is a package. I wonder if all 3 should be removed myself. But not all packages are on the same footing--the Sage library being an excellent example of something that's much more than just another package. By packaging I would think of tickets involving the spkg install system, spkg checks, etc. that require compiler and shell scripting skills. In this sense, all packages are more similar than, e.g. number theory vs. packaging. and - AIX or HP-UX ports, build, cygwin, debian-package, distribution, FreeBSD, msvc, porting, relocation, solaris, spkg-check under the title distribution I don't thinking lumping those lot together under the title distribution would be sensible myself. It's would make finding things of interest even slower. Especially given some of those have people that get notified about specific areas, but don't want to get inundated with tons of messages. Perhaps porting would be a better title--and I could see the justification for splitting Windows from non-Windows, but finer granularity than that would not be of interest to the vast majority of people. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: Re: [sage-devel] Re: bug wranglers
The idea of having one piece of a Sage days devoted to people sharing ideas from books they read in a coordinated way sounds plausible as well, though probably it would really depend on the Sage days in question. That would sound good. If each person read a chapter of a book on a topic, and gave a short talk to everyone else, it should at least make people aware of the other issues. I bought this book http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/013703515 2/ref=sr_1_1?ie=UTF8qid=1287529714sr=8-1 though I'm not over-impressed with it. Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of this book http://www.amazon.com/Software-Engineering-Practitioners-Roger-Pressman/dp/ 0073375977/ref=sr_1_4?ie=UTF8qid=1287529714sr=8-4 to be very useful. You can pick up a used copy of the 6th edition (2004) for less than $2 on Amazon. I'd like to return to Burcin's original proposal if possible. He made a *concrete* proposal for what to do with the growing number of bugs in Sage and somehow this turned into a threat discussing which books on Software Engineering we should read and how early one should should fix bugs. Don't get me wrong, this is a useful discussion to be had but it is a shame that discussions move from concrete to abstract instead of the other way around quite often these days ([sage-general] anyone? :)) It seems clear to me even if we do employ all kinds of software engineering techniques that there will still be bugs we'll have to tackle and our current approach as serious issues. Even OpenBSD has bugs which they have to address despite the fact that they make quite an effort to scrutinize code. To get back to Burcin's proposal it seems while there is some support, it doesn't seem to spur enough interests to have enough people to distribute the load to or am I mistaken? Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://martinralbrecht.wordpress.com/ _jab: martinralbre...@jabber.ccc.de -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: bug wranglers
On 10/20/10 10:37 AM, Martin Albrecht wrote: The idea of having one piece of a Sage days devoted to people sharing ideas from books they read in a coordinated way sounds plausible as well, though probably it would really depend on the Sage days in question. That would sound good. If each person read a chapter of a book on a topic, and gave a short talk to everyone else, it should at least make people aware of the other issues. I bought this book http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/013703515 2/ref=sr_1_1?ie=UTF8qid=1287529714sr=8-1 though I'm not over-impressed with it. Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of this book http://www.amazon.com/Software-Engineering-Practitioners-Roger-Pressman/dp/ 0073375977/ref=sr_1_4?ie=UTF8qid=1287529714sr=8-4 to be very useful. You can pick up a used copy of the 6th edition (2004) for less than $2 on Amazon. I'd like to return to Burcin's original proposal if possible. It might have been better to post the followup to his comments not mine, but it does not matter too much. He made a *concrete* proposal for what to do with the growing number of bugs in Sage and somehow this turned into a threat discussing which books on Software Engineering we should read and how early one should should fix bugs. First, without any quantitative data, are we sure the number is growing? We should consider Sage is growing, adding new functionality, so an increase in the absolute number of bugs is inevitable. My gut feeling is the situation is getting worst, but I've seen no evidence to prove this. Even the most basic graph (say number of bugs vs date), would be semi-useful. There are methods of measuring software quality http://en.wikipedia.org/wiki/Software_quality http://www.developer.com/tech/article.php/3644656/Software-Quality-Metrics.htm http://it.toolbox.com/wiki/index.php/Software_Quality_Metrics but we don't do any of them. Ultimately the best way to manage the situation it to measure it, and determine the effect of various changes. Like it or not, the situation does need to be managed - it won't solve itself. You can see where I am leading with this - back to applying software engineering principles! Don't get me wrong, this is a useful discussion to be had but it is a shame that discussions move from concrete to abstract instead of the other way around quite often these days ([sage-general] anyone? :)) I would not consider my comments abstract, but individual book recommendations are less relevant to what Burcin said. It seems clear to me even if we do employ all kinds of software engineering techniques that there will still be bugs we'll have to tackle and our current approach as serious issues. Even OpenBSD has bugs which they have to address despite the fact that they make quite an effort to scrutinize code. To get back to Burcin's proposal it seems while there is some support, it doesn't seem to spur enough interests to have enough people to distribute the load to or am I mistaken? To make matters easier to follow, lets look at Burcin's proposals. http://groups.google.com/group/sage-devel/msg/40d2af34d86586de?hl=en and consider them, here in an abbreviated and expanded form. 1) Burcin said: Many of the bugs on trac are duplicates and could be closed. He is probably right. Some are undoubably wrongly categorised, but from a personal perspective I often don't have a clue what to file them under anyway. Perhaps for those of us without maths degrees, the categories could be more explicit. But even that is not a full solution. I've got a reasonable understanding about random numbers, as I did quite a bit of work on it during my Ph.D with Monte Carlo modelling. But I don't really have a clue what to file #10113 under. Often bugs should really be in several categories, but one can only chose one. IMHO it should be a tick-box, not a pull-down. If something with an elliptic curve causes a doctest failure, on Solaris, do I file it under * Elliptic curves ? * Doctests ? * Solaris ? If person X files such a report, John Cremola might be in the best position to fix it, but then I'd probably be able to make comments too. People with knowledge about doctests might realise its actually a failure in the doctest. (I'm very untrusting of the doctesing framework, especially for parallel tests). 2) Burcin said: We might be able to overcome this with a bug-wrangler team, people who volunteer to ... IMHO, If the categories could with a tick box, then this step could hopefully be removed for future bugs. The right people will automatically be notified. We need however to have a category I need helping chosing the right categories. That would be especially useful for those of us with a non-maths background, but I think to others too, as parts of Sage are so specialised, I doubt I'm the only one who struggles to know what to categorise things under. I think
[sage-devel] Re: bug wranglers
I think that Burcin's suggestion is excellent. Development of Sage should definitely move towards more structure, documentation, testing and other software engineering practices, but as for any Open Source- project, these things should come naturally as the project grows and matures; as has already happened with Sage a lot, it seems (for a relative new-comer like me). To require too much too soon would kill the joy of working on the project and thus kill the project itself. Burcin's suggestion seem to fit this curve pretty well at this time. New developers and bugfixers -- with little overview of the monster that is Sage -- would feel more confident in reporting and fixing bugs if there was a feeling that there was someone (or a group of someones) with overview and structure. If some enthusiastic veterans could be found and agree on the exact model of this, I think it would improve bug-tracking and -fixing in a number of ways: - overview of bugs, their severity and class (by cleaning up, removing duplicates, collating related tracs, and reclassifying) - better classification of bugs by everyone else (by monkey-see- monkey-do) - better overview over bugs to fix before releases (by better overview over all bugs) - shorter pickup-time between a trac has been filed (possibly by someone not interested in fixing it) and someone is looking at it - assurance that a veteran has looked at the trac, accepted it, and maybe even given an approving nod after positive review - and all of this gives more confidence to developer-rookies I think the system should entirely superseed the automatic-owner system that is currently in Sage. Software-speaking, this would provide an abstract interface between the tracs and those responsible for it, which makes it more flexible to have either one, several or many owners of a trac or class of tracs. Personally, I like the one-week-at-a-time suggestion (though several people should be on duty each week perhaps) sounds best. However, it's easy for me to say, as I don't think I have the required experience to undertake this duty (You are not bug-ninja materiAL, SOLDIER! Drop down and give me a recursive function generating the Fibonacci sequence!). When and if the time comes, I would be happiest with a one-week-at-a-time schedule, though. Burcin wrote: Perhaps we should come up with a locking mechanism, to prevent two different people from trying to sort the same issue at the same time, but it feels like too much organization at the beginning. Maybe there would not need to be a locking-mechanism to begin with, but surely a mechanism so that a bug-wrangler could see that no other bug-wrangler has already looked at this new trac. Cheers, Johan On Oct 20, 11:37 am, Martin Albrecht martinralbre...@googlemail.com wrote: The idea of having one piece of a Sage days devoted to people sharing ideas from books they read in a coordinated way sounds plausible as well, though probably it would really depend on the Sage days in question. That would sound good. If each person read a chapter of a book on a topic, and gave a short talk to everyone else, it should at least make people aware of the other issues. I bought this book http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/013... 2/ref=sr_1_1?ie=UTF8qid=1287529714sr=8-1 though I'm not over-impressed with it. Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of this book http://www.amazon.com/Software-Engineering-Practitioners-Roger-Pressm... 0073375977/ref=sr_1_4?ie=UTF8qid=1287529714sr=8-4 to be very useful. You can pick up a used copy of the 6th edition (2004) for less than $2 on Amazon. I'd like to return to Burcin's original proposal if possible. He made a *concrete* proposal for what to do with the growing number of bugs in Sage and somehow this turned into a threat discussing which books on Software Engineering we should read and how early one should should fix bugs. Don't get me wrong, this is a useful discussion to be had but it is a shame that discussions move from concrete to abstract instead of the other way around quite often these days ([sage-general] anyone? :)) It seems clear to me even if we do employ all kinds of software engineering techniques that there will still be bugs we'll have to tackle and our current approach as serious issues. Even OpenBSD has bugs which they have to address despite the fact that they make quite an effort to scrutinize code. To get back to Burcin's proposal it seems while there is some support, it doesn't seem to spur enough interests to have enough people to distribute the load to or am I mistaken? Cheers, Martin -- name: Martin Albrecht _pgp:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www:http://martinralbrecht.wordpress.com/ _jab: martinralbre...@jabber.ccc.de -- To post to this group, send an email to
[sage-devel] Re: bug wranglers
I think that Burcin's suggestion is excellent. Development of Sage should definitely move towards more structure, documentation, testing and other software engineering practices, but as for any Open Source- project, these things should come naturally as the project grows and matures; as has already happened with Sage a lot, it seems (for a relative new-comer like me). To require too much too soon would kill the joy of working on the project and thus kill the project itself. Burcin's suggestion seem to fit this curve pretty well at this time. New developers and bugfixers -- with little overview of the monster that is Sage -- would feel more confident in reporting and fixing bugs if there was a feeling that there was someone (or a group of someones) with overview and structure. If some enthusiastic veterans could be found and agree on the exact model of this, I think it would improve bug-tracking and -fixing in a number of ways: - overview of bugs, their severity and class (by cleaning up, removing duplicates, collating related tracs, and reclassifying) - better classification of bugs by everyone else (by monkey-see- monkey-do) - better overview over bugs to fix before releases (by better overview over all bugs) - shorter pickup-time between a trac has been filed (possibly by someone not interested in fixing it) and someone is looking at it - assurance that a veteran has looked at the trac, accepted it, and maybe even given an approving nod after positive review - and all of this gives more confidence to developer-rookies I think the system should entirely superseed the automatic-owner system that is currently in Sage. Software-speaking, this would provide an abstract interface between the tracs and those responsible for it, which makes it more flexible to have either one, several or many owners of a trac or class of tracs. Personally, I like the one-week-at-a-time suggestion (though several people should be on duty each week perhaps) sounds best. However, it's easy for me to say, as I don't think I have the required experience to undertake this duty (You are not bug-ninja materiAL, SOLDIER! Drop down and give me a recursive function generating the Fibonacci sequence!). When and if the time comes, I would be happiest with a one-week-at-a-time schedule, though. Burcin wrote: Perhaps we should come up with a locking mechanism, to prevent two different people from trying to sort the same issue at the same time, but it feels like too much organization at the beginning. Maybe there would not need to be a locking-mechanism to begin with, but surely a mechanism so that a bug-wrangler could see that no other bug-wrangler has already looked at this new trac. Cheers, Johan On Oct 20, 11:37 am, Martin Albrecht martinralbre...@googlemail.com wrote: The idea of having one piece of a Sage days devoted to people sharing ideas from books they read in a coordinated way sounds plausible as well, though probably it would really depend on the Sage days in question. That would sound good. If each person read a chapter of a book on a topic, and gave a short talk to everyone else, it should at least make people aware of the other issues. I bought this book http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/013... 2/ref=sr_1_1?ie=UTF8qid=1287529714sr=8-1 though I'm not over-impressed with it. Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of this book http://www.amazon.com/Software-Engineering-Practitioners-Roger-Pressm... 0073375977/ref=sr_1_4?ie=UTF8qid=1287529714sr=8-4 to be very useful. You can pick up a used copy of the 6th edition (2004) for less than $2 on Amazon. I'd like to return to Burcin's original proposal if possible. He made a *concrete* proposal for what to do with the growing number of bugs in Sage and somehow this turned into a threat discussing which books on Software Engineering we should read and how early one should should fix bugs. Don't get me wrong, this is a useful discussion to be had but it is a shame that discussions move from concrete to abstract instead of the other way around quite often these days ([sage-general] anyone? :)) It seems clear to me even if we do employ all kinds of software engineering techniques that there will still be bugs we'll have to tackle and our current approach as serious issues. Even OpenBSD has bugs which they have to address despite the fact that they make quite an effort to scrutinize code. To get back to Burcin's proposal it seems while there is some support, it doesn't seem to spur enough interests to have enough people to distribute the load to or am I mistaken? Cheers, Martin -- name: Martin Albrecht _pgp:http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www:http://martinralbrecht.wordpress.com/ _jab: martinralbre...@jabber.ccc.de -- To post to this group, send an email to
[sage-devel] Re: bug wranglers
Often bugs should really be in several categories, but one can only chose one. IMHO it should be a tick-box, not a pull-down. If something with an elliptic I didn't know this was possible on Trac; certainly this would overcome a lot of problems. Likewise, it would be nice to be able to be notified automatically about tickets in certain areas, without being an owner. Even if this is possible, it's not obvious how to do it. Not to be overly pessimistic, but one metric we do not collect, but Google do for us, is the number of posts each month to sage-devel. There has been a very dramatic falloff this year compared to all other years. http://groups.google.com/group/sage-devel/about?hl=en http://groups.google.com/group/sage-support/about?hl=en I think the number of posts to sage-support is more worrying than to sage-devel, but I believe the combination rather shows that we are unlikely to find a lot of developers taking on Burcin's proposals. Hmm, that is interesting. I don't know if it means anything (it might), but it is interesting. Thanks for that. - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: bug wranglers
On Wed, Oct 20, 2010 at 7:41 AM, kcrisman kcris...@gmail.com wrote: Often bugs should really be in several categories, but one can only chose one. IMHO it should be a tick-box, not a pull-down. If something with an elliptic I didn't know this was possible on Trac; certainly this would overcome a lot of problems. Likewise, it would be nice to be able to be notified automatically about tickets in certain areas, without being an owner. Even if this is possible, it's not obvious how to do it. Not to be overly pessimistic, but one metric we do not collect, but Google do for us, is the number of posts each month to sage-devel. There has been a very dramatic falloff this year compared to all other years. http://groups.google.com/group/sage-devel/about?hl=en http://groups.google.com/group/sage-support/about?hl=en I think the number of posts to sage-support is more worrying than to sage-devel, but I believe the combination rather shows that we are unlikely to find a lot of developers taking on Burcin's proposals. Hmm, that is interesting. I don't know if it means anything (it might), but it is interesting. Thanks for that. I take it to mean that Sage is now a mature project with roughly the right number of developers. That said, everybody should keep recruiting new people as aggressively as they can, since developers come and *go*, as they have children, have to finish a thesis, get involved in other projects, finish making the contributions to sage they find interesting, etc. -- William -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: bug wranglers
On 10/20/10 03:41 PM, kcrisman wrote: Often bugs should really be in several categories, but one can only chose one. IMHO it should be a tick-box, not a pull-down. If something with an elliptic I didn't know this was possible on Trac; certainly this would overcome a lot of problems. Likewise, it would be nice to be able to be notified automatically about tickets in certain areas, without being an owner. Even if this is possible, it's not obvious how to do it. I don't know if it's possible. It would seem a sensible feature, and perhaps one can do it in the latest version. It was just an observation that it would be useful. I've just registered on the 'trac' mailing list, and asked if this is possible. But since it's a moderated list, my post has not appeared yet, so I can't provide a link. If it was possible to set this up it would be good. It seems such an obvious thing to have to me. If it's not possible, perhaps I can file an RFE. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: bug wranglers
On Wed, Oct 20, 2010 at 5:10 AM, Johan S. R. Nielsen j.s.r.niel...@mat.dtu.dk wrote: I think that Burcin's suggestion is excellent. Development of Sage should definitely move towards more structure, documentation, testing and other software engineering practices, but as for any Open Source- project, these things should come naturally as the project grows and matures; as has already happened with Sage a lot, it seems (for a relative new-comer like me). To require too much too soon would kill the joy of working on the project and thus kill the project itself. +1 I have definitely seen that the level of bureaucracy has going up, especially in the last year or two, has turned off a lot of potential and even former developers. The focus on software engineering and testing can certainly be good for quality (though that's not an immediate or certain implication), but the problem is that too much emphasis on it has a significant chilling effect on contributions. The lag time between hacking out some code and getting it in is way too high these days discourages contribution and sucks up a lot of development time and energy with endless rebases and waiting. And though we all want to produce bug-free code, holding that up as the primary objetive (as opposed to producing useful code) I think dissuades people from submitting or refereeing code. I'm not sure I have a solution, but one thing that keeps coming to mind is that Sage is trying to span several audiences with different goals and criteria, and perhaps the various audiences would be best met by a stable vs. unstable model like Debian. Purple sage is an extreem move in this direction (more like Debian experimental)--I can certainly see the attraction and value, but I just hope it doesn't become an incompatible fork. Burcin's suggestion seem to fit this curve pretty well at this time. New developers and bugfixers -- with little overview of the monster that is Sage -- would feel more confident in reporting and fixing bugs if there was a feeling that there was someone (or a group of someones) with overview and structure. If some enthusiastic veterans could be found and agree on the exact model of this, I think it would improve bug-tracking and -fixing in a number of ways: - overview of bugs, their severity and class (by cleaning up, removing duplicates, collating related tracs, and reclassifying) - better classification of bugs by everyone else (by monkey-see- monkey-do) - better overview over bugs to fix before releases (by better overview over all bugs) - shorter pickup-time between a trac has been filed (possibly by someone not interested in fixing it) and someone is looking at it - assurance that a veteran has looked at the trac, accepted it, and maybe even given an approving nod after positive review - and all of this gives more confidence to developer-rookies I think the system should entirely superseed the automatic-owner system that is currently in Sage. Software-speaking, this would provide an abstract interface between the tracs and those responsible for it, which makes it more flexible to have either one, several or many owners of a trac or class of tracs. Personally, I like the one-week-at-a-time suggestion (though several people should be on duty each week perhaps) sounds best. However, it's easy for me to say, as I don't think I have the required experience to undertake this duty (You are not bug-ninja materiAL, SOLDIER! Drop down and give me a recursive function generating the Fibonacci sequence!). When and if the time comes, I would be happiest with a one-week-at-a-time schedule, though. Burcin wrote: Perhaps we should come up with a locking mechanism, to prevent two different people from trying to sort the same issue at the same time, but it feels like too much organization at the beginning. Maybe there would not need to be a locking-mechanism to begin with, but surely a mechanism so that a bug-wrangler could see that no other bug-wrangler has already looked at this new trac. I agree that a big part of the problem is that it's hard to get a big picture of all the bugs being worked on. The idea of a weekly bug-wrangler is an interesting one. I have a simpler proposal (which may be insufficient, but would complement a bug-wrangler's role and is much easier to implement). First, have the initial status of tickets be some pre-new stage. (Something like unclassified.) This woud make it so you don't have to be an expert to classify a bug. Volunteers could go and look at all unclassified tickets and file them appropriately (severity, defect vs. enhancement, component, duplicate, etc.) Of course, there could be a rotating bug-wrangler, but if it was easy enough for a veteran to hop on and categorize a bunch of them in one sitting this might not even be necessary. Second, rather than have the default milestone be the next release, have some default future milestone. Only tickets that are actively
Re: [sage-devel] Re: bug wranglers
On Wed, Oct 20, 2010 at 9:33 PM, Robert Bradshaw rober...@math.washington.edu wrote: On Wed, Oct 20, 2010 at 5:10 AM, Johan S. R. Nielsen j.s.r.niel...@mat.dtu.dk wrote: I think that Burcin's suggestion is excellent. Development of Sage should definitely move towards more structure, documentation, testing and other software engineering practices, but as for any Open Source- project, these things should come naturally as the project grows and matures; as has already happened with Sage a lot, it seems (for a relative new-comer like me). To require too much too soon would kill the joy of working on the project and thus kill the project itself. +1 I have definitely seen that the level of bureaucracy has going up, especially in the last year or two, has turned off a lot of potential and even former developers. Another +1. The level of bureaucracy has gone up so much in the last year that it has very seriously turned off me. The focus on software engineering and testing can certainly be good for quality (though that's not an immediate or certain implication), but the problem is that too much emphasis on it has a significant chilling effect on contributions. The lag time between hacking out some code and getting it in is way too high these days discourages contribution and sucks up a lot of development time and energy with endless rebases and waiting. +1 It kills a large portion of potential contributions of code for advanced research, perhaps 80% or more. I've talked to so many people about this in the last few months... And though we all want to produce bug-free code, holding that up as the primary objetive (as opposed to producing useful code) I think dissuades people from submitting or refereeing code. Also, anybody who has significant experience with software engineering knows that producing bug-free code is a recipe for producing almost no code. I was talking to somebody today who works on Microsoft Windows (actually implementing the OS there), and who has also written a lot of code for Sage (at a research level -- advanced number theory stuff). He said internally at Microsoft code gets into the system, and out getting used by a lot of people (internally) much more quickly than with Sage. Instead of the very all or nothing model that we tend to have, they have many levels of review that code goes through. Sage would benefit from something similar. That's basically what http://purple.sagemath.org/ is about: a way to get code out there and distributed, used, etc., but without all the bureaucracy. As an example, I'll sit down this coming Tuesday with Sal Baig, and get his and Chris Hall's library for computing with elliptic curves over function fields into PSAGE, and have it be in the next release. That's code that isn't stable yet and is mainly for research. For a year they have been trying to get it into Sage, but it just isn't happening, since they care and know much more about *using* the code for research purposes, than about how to make a proper makefile/autoconf setup, so it builds fine on Solaris and OS X 10.4. I think PSAGE will show that the increasingly bureaucratic and plodding way in which code gets into Sage isn't necessarily bad, in the same sense that Debian can be very plodding and bureaucratic, but it still provides a good foundation for many other much more svelte and useful Linux distributions. I'm not sure I have a solution, but one thing that keeps coming to mind is that Sage is trying to span several audiences with different goals and criteria, and perhaps the various audiences would be best met by a stable vs. unstable model like Debian. Purple sage is an extreem move in this direction (more like Debian experimental)--I can certainly see the attraction and value, but I just hope it doesn't become an incompatible fork. A difference from debian experimental is that PSAGE starts by removing over 20 standard packages from Sage. In fact, so far, that is essentially *all* that PSAGE is.Also, my intention is that most Python code in PSAGE go into a different Python module than the sage one. Burcin's suggestion seem to fit this curve pretty well at this time. New developers and bugfixers -- with little overview of the monster that is Sage -- would feel more confident in reporting and fixing bugs if there was a feeling that there was someone (or a group of someones) with overview and structure. If some enthusiastic veterans could be found and agree on the exact model of this, I think it would improve bug-tracking and -fixing in a number of ways: - overview of bugs, their severity and class (by cleaning up, removing duplicates, collating related tracs, and reclassifying) - better classification of bugs by everyone else (by monkey-see- monkey-do) - better overview over bugs to fix before releases (by better overview over all bugs) - shorter pickup-time between a trac has been filed (possibly by someone not
[sage-devel] Re: bug wranglers
On 18 Oct, 21:33, Robert Bradshaw rober...@math.washington.edu wrote: On Sun, Oct 17, 2010 at 6:39 AM, Dr. David Kirkby On Sun, Oct 17, 2010 at 6:39 AM, Dr. David Kirkby sage: seed(1,2) sage: seed(100,34) sage: seed(1,2,3,4,5,6,7) will all crash Sage with an Unhandled SIGSEGV. Plenty more sets of invalid input to other commands will hang Sage, so the only answer is to kill the process. Though in an ideal world, this kind of thing wouldn't crash Sage, I'm more worried about the kinds of bugs where valid input causes a segfault, or, much worse, an incorrect answer. Obviously getting incorrect results is the worst possible case bug - especially if the results look believable. If you try to factorise an integer and get a Bessel function as an answer, it is obviously wrong. Some results look reasonable and so are very bad news. I'd also agree getting crashes with valid input is bad, but its a fact of life people do enter invalid input. Sometimes how one uses a function is not very obvious, so using invalid input is going to happen. If that crashes Sage, and stops lots of people working on a Sage server, I think that's pretty serious, though not as bad as incorrect results. I think the main problem is ignorance. Good software engineering techniques do not form part of mathematics degrees, so most Sage developers are totally ignorant of the issues. Then those motivated to find more information soon hit the fact that books on this topic are not cheap. I have an 18-year old copy of this book, which despite the complaints the 7th edition is out of date, I think much of the material would be useful to Sage developers. http://www.amazon.com/Software-Engineering-Practitioners-Approach-Int... There's also plenty of books on software testing. http://www.amazon.com/s/ref=nb_sb_noss?url=search-alias%3Dstripbooks;... Perhaps when William assembles the team in Seattle, he could find the money to buy each person a book on software testing. Buy each person a different book, then hopefully Sage developers will able to independently review the material. Perhaps they each write a Wiki page on what they though was the most important things they learned from the book. I would submit that practicing good software engineering techniques is more than a matter of finding the money (and especially time) to read a good book on it--we all have different priorities on what we can afford to spend 10,000 hours on. (Note, I'm not saying it wouldn't be useful for all of us to learn these things, just that I don't expect working mathematicians to all find enough time on the side to become expert software developers as well). - Robert IMHO, if Sage is every to become a viable alternative to Maple, Mathematica or MATLAB, then practicing good software engineering is an absolute *must* - not an option. (I purposely excluded Magma from that list, as I know nothing about that tool). If you believe that levels of quality equal to those three commercial packages can be achieved without such skills, then we will have to agree to differ. Of course, for some users Sage is no doubt already the best of these packages, but it is unlikely to be so for a mass audience without major changes. I was not suggesting anyone spend 10,000 hours studying the subject of software engeering. I'm not suggesting people need to be experts. But perhaps spending 20-50 hours on it is not unreasonable. I don't know about you, but I've probably devoted 1000 hours to working on Sage, so 20-50 is a small percentage. I think 20-50 hours would be for you too. It's a fact of life that you often have to learn new skills. 20-50 hours would not mean taking a week off of work, but reading a book on a train to work, or at night instead of a bit of TV. Expecting a new developer to spend such time would be unreasonable, but then their contributions should in my opinion come under closer scrutiny from those with better knowledge. Mike Witt said above, with reference to the Sage bugs: I personally have been burned enough times now by obvious bugs that have shown up when I try to demonstrate what I'm doing in sage, that I hesitate now to shares things readily. It's clear to me (and perhaps Mike) the current methodology is not working. I certainly would not hesitate to show people things with MATLAB or Mathematica. If one of these tools did crash, I would not have egg on my face. But with Sage I would. Currently one person with poor Python skills can review the work of another with poor Python skills, and the code get committed to Sage. There's little filtering. I know Kcrisman has said +1 to your comments, so I'd say I'd have to disagree with him too. On a more practical note, I think it may help things if we actually used the priority field. Certainly Blocker: 14 Critical: 68 Major: 1609 Minor: 516 Trivial: 26 Of course most are Major as that is the default. Many were at one time the algebra component. That's
Re: [sage-devel] Re: bug wranglers
On Tue, Oct 19, 2010 at 8:09 AM, Dr David Kirkby drkir...@gmail.com wrote: If that crashes Sage, and stops lots of people working on a Sage server, I think that's pretty serious, though not as bad as incorrect results. It only crashes that one user's session. Each worksheet is run in a different process. --Mike -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: bug wranglers
I was not suggesting anyone spend 10,000 hours studying the subject of software engeering. I'm not suggesting people need to be experts. But perhaps spending 20-50 hours on it is not unreasonable. I don't know about you, but I've probably devoted 1000 hours to working on Sage, so 20-50 is a small percentage. I think 20-50 hours would be for you too. It's not clear to me that without a specific time and place to do so, that it would be particularly effective to spend 20-50 hours reading books about this. Software seems to be one of those things that is hard to really learn how to do without actually doing it. 10-20 hours spent trying to do some Sage development, but with a couple quality software engineers looking over your shoulder the whole time, might do it. The idea of having one piece of a Sage days devoted to people sharing ideas from books they read in a coordinated way sounds plausible as well, though probably it would really depend on the Sage days in question. I personally have been burned enough times now by obvious bugs that have shown up when I try to demonstrate what I'm doing in sage, that I hesitate now to shares things readily. This probably depends a lot on what mathematics you are doing with Sage, of course. Currently one person with poor Python skills can review the work of another with poor Python skills, and the code get committed to Sage. There's little filtering. Condensed version of much longer response I started with: I often find that people who contact us (and even contact me personally) about this are more likely to not want to contribute *anything*, even very minor bugfixes or documentation improvements, because they are not confident in their skills. Most people who feel confident enough to review are confident enough to point out things that look bad, and those who don't still will often point out something wrong/suboptimal. What happens more often, I think, is that someone with decent/good Python skills is tired or lackadaisical and reviews something they want to get in without spending the 1+ hours it takes to really test edge cases and so forth of a patch also written by someone with decent/ good Python skills who is tired or lackadaisical... etc. Since such a person also contributes and reviews in quality ways most of the time, it's much harder to filter for that. Finally, I think that MANY of the new bugs in Sage are *not* a result of someone destroying old code, but rather of a bug appearing where before there was no functionality! I think that to most Sage developers, it is better to have 99 out of 100 cases give the right answer, and have it tested out and hopefully fix the bug soon that surely is there, than to have a NotImplementedError for years and years. Stagnation is the way to not attract the new developers we would need (for time's sake) to improve our software engineering practice, indeed. To be sure, this is a design decision of sorts, and one at odds with your books, perhaps. But unless we also can operate under the implicit assumptions of them (which probably include things like actual employers, or perhaps a pool of developers who all have similar skill sets - neither of which is the case here, in a project which is monstrously diverse in terms of skill needs and obviously very non- hierarchical), I don't see how it's feasible to implement your ideas on this, other than the reminders of good practice you give in public fora such as this and on Trac tickets. Which I think that is having a positive impact, incidentally! :) - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: bug wranglers
On 10/19/10 05:06 PM, kcrisman wrote: I was not suggesting anyone spend 10,000 hours studying the subject of software engeering. I'm not suggesting people need to be experts. But perhaps spending 20-50 hours on it is not unreasonable. I don't know about you, but I've probably devoted 1000 hours to working on Sage, so 20-50 is a small percentage. I think 20-50 hours would be for you too. It's not clear to me that without a specific time and place to do so, that it would be particularly effective to spend 20-50 hours reading books about this. I don't have much experience to say whether you are right or wrong. I do *not* have a software background. I have never done any sort of computer science degree. However, I had had to write code which others will use, and it became clear to me that on a large project one needs to do a bit more than just writing the code. Based on my experience, I feel that 20-50 hours reading about what are good software engineering practices would be useful. Those are just as relevant if you code in C, assembler, Python or foobar. Software seems to be one of those things that is hard to really learn how to do without actually doing it. My main point was not about the code one writes. Clearly if you write in Python you should know about Python, but that's another matter altogether. I tend to agree that one of of the best ways to learn a language, is to use it. Things that I believe would be good for Sage, and one could get some useful understanding in 20-50 hours from a software engineering book would be: * An understanding of how software projects should be managed. This is especially so for William of course, but in general I think that's useful to know for all of us. To a certain extent, some trac tickets have to be managed. * An understanding of why bugs should be fixed as early as possible. * Understanding the different sorts of tests that software developers use - black box testing, white box testing etc. * Automated testing tools. * Understanding ways to estimate the quality of code. At the moment there is no analysis of defect rates in Sage. * The life-cycle of software. Analysis - Design - Code - Test - Maintenence. This applies to Sage as a whole, but also to individual parts of Sage. * An understanding of why software wears out. What can we do to reduce the rate of wearout? 10-20 hours spent trying to do some Sage development, but with a couple quality software engineers looking over your shoulder the whole time, might do it. That's an entirely different thing - I'm not talking about that. Any course on software engineering is not likely to have you writing code with someone looking over your shoulder. The idea of having one piece of a Sage days devoted to people sharing ideas from books they read in a coordinated way sounds plausible as well, though probably it would really depend on the Sage days in question. That would sound good. If each person read a chapter of a book on a topic, and gave a short talk to everyone else, it should at least make people aware of the other issues. I bought this book http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/0137035152/ref=sr_1_1?ie=UTF8qid=1287529714sr=8-1 though I'm not over-impressed with it. Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of this book http://www.amazon.com/Software-Engineering-Practitioners-Roger-Pressman/dp/0073375977/ref=sr_1_4?ie=UTF8qid=1287529714sr=8-4 to be very useful. You can pick up a used copy of the 6th edition (2004) for less than $2 on Amazon. To be sure, this is a design decision of sorts, and one at odds with your books, perhaps. But unless we also can operate under the implicit assumptions of them (which probably include things like actual employers, or perhaps a pool of developers who all have similar skill sets - neither of which is the case here, in a project which is monstrously diverse in terms of skill needs and obviously very non- hierarchical), I don't see how it's feasible to implement your ideas on this, other than the reminders of good practice you give in public fora such as this and on Trac tickets. Which I think that is having a positive impact, incidentally! :) - kcrisman The fact people have different skill sets, the fact we are not employed, the fact there is essentially non-hierarchical, does not really change things too much. Some aspects obviously do, as you can't demand people do what you want when you don't pay them. But hopefully people more people would do things better if they were aware of good practices. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: bug wranglers
On 10/17/10 9:39 AM, Dr. David Kirkby wrote: On 10/17/10 03:16 PM, Jan Groenewald wrote: Hi I believe any belief that having bug hunt weeks is a long term solution is rather flawed. The issues should be tackled at an earlier stage. Despite not being a sufficient solution, are they not nonetheless necessary? Or at least helpful? regards, Jan Yes, I think they would be useful. Periods of concentrated effort at fixing bugs is a standard practice in professional software engineering. In a similar way I feel bug fix only releases would be useful, where one concentrates on removing bugs, and not adding features. That idea has however been very much disliked by many people. Given the lack of enthusiasm by many (including William) for my suggestions of bug-fix-only releases, it will be interesting to see how many take William up on attending the Bug Days. (just answering the question about bug days, but I don't have time right now to comment on the other points) We have already had several bug days (week-long get-togethers; at least two that I've attended), plus numerous 1-day meet-on-IRC bug days, and they have been very successful. Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: bug wranglers
I would submit that practicing good software engineering techniques is more than a matter of finding the money (and especially time) to read a good book on it--we all have different priorities on what we can afford to spend 10,000 hours on. (Note, I'm not saying it wouldn't be useful for all of us to learn these things, just that I don't expect working mathematicians to all find enough time on the side to become expert software developers as well). +1 On a more practical note, I think it may help things if we actually used the priority field. Certainly Blocker: 14 Critical: 68 Major: 1609 Minor: 516 Trivial: 26 Is not the correct distribution. We have an extremely large number of components of varying scope as well, this could probably use some unification and cleanup as well. I think I must be one of the only people to use the 'minor' field on a regular basis. And most of the 'critical' ones are not critical in that sense. But there hasn't been much discussion at all of what counts as a critical or major thing - it's mostly in the eye of the beholder. - kcrisman -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: bug wranglers
On Oct 16, 5:21 am, Burcin Erocal bur...@erocal.org wrote: [...] if they are filed in different components. The members of the bug-wrangler mailing list will be able to see the initial report for every ticket, so they might recall a similar problem reported a few days ago. Another advantage is that the members of this team don't need to be developers, or even know how to code. It is enough to be able to listen to user requests and use trac. This could also be a good starting point for people who want to get into Sage development, since it provides an opportunity to look through the library and become familiar with the internal structure of Sage. Comments? What will be appropriate attire for Bug Days? Will there be a wake (and party) after the (bug) funeral? -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: bug wranglers
Hi, Burcin! I think this is a great Idea! I'm short on time in the next months, but If I'm free again, could help with this. greez, Stefan On 16 Okt., 14:21, Burcin Erocal bur...@erocal.org wrote: Hi, Motivated by the call for the bug days, here is an idea to manage the rapidly increasing number of new tickets on trac. Many of the bugs on trac are - duplicates, - already fixed, which can be closed after adding a doctest or - has not been seen by a developer who can fix it since keeping up with all the new tickets on trac is very time consuming, and possibly the problem was filed in the wrong category. We might be able to overcome this with a bug-wrangler team, people who volunteer to - look at newly submitted tickets, notify the related developers, ask for examples and test cases if the report doesn't provide them, etc. - every once in a while, go through the open tickets and see if they were fixed in a recent release (perhaps this won't be such a problem once the duplicates are filtered properly) I know some people already spend time doing some of this, but it's impossible to fight with more than 2000 open tickets without an organized effort. Most linux distributions already use a similar approach. The issues are first assigned to the bug-wrangler team, where the email address points to a mailing list. Then someone takes the new ticket, and follows up until the right developer gives feedback. This would also be an easy way to consolidate duplicate tickets, even if they are filed in different components. The members of the bug-wrangler mailing list will be able to see the initial report for every ticket, so they might recall a similar problem reported a few days ago. Another advantage is that the members of this team don't need to be developers, or even know how to code. It is enough to be able to listen to user requests and use trac. This could also be a good starting point for people who want to get into Sage development, since it provides an opportunity to look through the library and become familiar with the internal structure of Sage. Comments? Cheers, Burcin -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
