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
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
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
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
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
