[sage-combinat-devel] Re: Trac ticket 9651
Usually when I replace a patch, I click the little box that says replace earlier version? (There may be pros and cons for this.) The other thing I do (since once someone complained) is to make it very clear in the description what needs to be applied, so when I reviewed the patch yesterday I also modified the description to say that trac_9648 was a prerequisite. Dan On Oct 20, 12:00 pm, Christian Stump christian.st...@gmail.com wrote: sorry for that, I uploaded the version with the line deleted twice to the track server. I hope, this time everything is fine... -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
[sage-combinat-devel] Re: Trac ticket 9651
Usually when I replace a patch, I click the little box that says replace earlier version? (There may be pros and cons for this.) The first time, I forgot to click the box - and then I thought it might be good to keep track of the file history... The other thing I do (since once someone complained) is to make it very clear in the description what needs to be applied, so when I reviewed the patch yesterday I also modified the description to say that trac_9648 was a prerequisite. You're right, when I first wrote the patch, it depended on 9648, but you could still have apply it without. This changed later and I missed to update the description to make this clear. Thanks for the positive review, Christian -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To post to this group, send email to sage-combinat-de...@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
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
[sage-devel] Re: search_methods() to search the methods of an object
Maybe there's an advantage in change from X.kertab (look through ker* methods...) to X.kertab (look through methods that contain ker in name ...) In fact, it's what X.tab (look through * methods...) do. Pedro On Oct 20, 5:24 am, Dan Drake dr...@kaist.edu wrote: Here's something that happens to me: I have an object X that has a *lot* of methods -- matrices and graphs, often -- and I'm wondering if X has a certain method. Often, I find myself doing X.atab (look through a methods...) X.btab (look through b methods...) and so on, through the alphabet. This is annoying. I don't like things that are annoying. How about a function, somewhat like search_doc, search_def, and friends, that accepts an object and a string, and returns methods that match that string? Would you find that useful? Here's what I just wrote. Try dropping this into sage/misc/sagedoc.py, and adding search_methods to all.py in that directory: def search_methods(x, s): r Given an object x and a string s, this returns a list of methods of x that contain s. A better version of this would have an option to include or exclude methods that begin with an underscore, do proper regexps, etc. return [m for m in dir(x) if s in m] Then you get: sage: m = matrix(2, [1,2,3,4]) sage: search_methods(m, 'kernel') ['_decomposition_using_kernels', '_kernel_matrix_using_padic_algorithm', '_kernel_matrix_using_pari', '_rational_kernel_iml', '_right_kernel_matrix', '_right_kernel_trivial', 'integer_kernel', 'kernel', 'kernel_matrix', 'kernel_on', 'left_kernel', 'right_kernel'] sage: g = graphs.PetersenGraph() sage: search_methods(g, 'loop') ['allow_loops', 'allows_loops', 'has_loops', 'loop_edges', 'loop_vertices', 'loops', 'number_of_loops', 'remove_loops'] Thoughts? Should I open a ticket for this? Dan -- --- Dan Drake - http://mathsci.kaist.ac.kr/~drake --- signature.asc 1KViewDownload -- 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] bug wranglers
On Sun, 17 Oct 2010 17:45:08 +0200 Jeroen Demeyer jdeme...@cage.ugent.be wrote: On 2010-10-16 14:21, Burcin Erocal wrote: - look at newly submitted tickets, notify the related developers How are you going to figure out who the related developers are? I'd say there is an unofficial list of people who care about bugs in certain areas. The default assignments for the components on trac makes some of these sort of official, but this system can definitely be improved. (I certainly don't want to be the one to fix all the bugs in the symbolics and calculus components.) For a method anyone can follow to decide who might be the person to ask about a problem reported to the issue tracker (after checking that the problem is reproducible in the latest version), I suggest using something similar to the method we suggest to find possible reviewers. - Look at the backtrace, find out which line of what file raises the error - Look at the file in question and determine who wrote those lines (with hg annotate) or who contributed to the file in general - Notify two developers whose names come up This process can be improved, to check if the error was raised by unexpected input, if so, go up the stack trace and look at the previous function. Once the real point causing the problem is identified, it would take a developer much less time to fix it. Note that this approach, if we can set it up properly, will free more developer time. Indirectly, this could help with more bug fixes, better reviews on patches, etc. since the veterans can use their time more efficiently. 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 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] Writing parallel code in Cython
Are there accepted idioms for writing parallel code in Cython for the Sage library? I don't yet have a specific application in mind, but I'm interested in learning from any examples. -- 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: 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
Re: [sage-devel] bug wranglers
On Sun, 17 Oct 2010 15:56:41 +0100 Martin Albrecht martinralbre...@googlemail.com wrote: I was thinking of setting up trac to send a notice to a mailing list for each new issue. Then people interested in this effort can follow this list and help out. Is this possible? Can someone familiar with the trac set up comment? IMHO, distributing work day by day, or weekly is still putting too much load on one person. It should be enough if someone contributes to one issue per day. 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. My guess would be that we won't have the issue with locking very often (i.e. too many people doing too much work) but with no one feeling responsible. I guess for me your suggestion would turn out something like this: 1) I sign up to that mailing list since I feel a responsibility of contributing to Sage in such a way 2) For the first few days or weeks I go through newly opened tickets as you suggested. 3) Eventually, probably in some phase where I have less disposable time, I give up on dealing with this e-mail since somebody else will take care of it. I know this scenario too well. We should try to avoid overloading people or relying on the efforts of only a few people as much as possible. Of course, the answer could just be to not do step 3, but I would assume that it would happen to many of us. Being responsible for a week a time is something more local or short-time which would make it easier for me to commit. 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. To given an example of the workload here's the list of tickets created on the 15th. It seems 3-5 new tickets a day is the normal load: snip ticket descriptions Thus, as a rule of thumb we could say whoever is responsible for a day should deal with five tickets old and new. This seems like about 1-2h of work which seems doable to me. Of course, if many people feel differently then we should choose a different path. I suggest still setting up a mailing and assigning all new bugs to a B-team user on trac with email address pointing to this list. Following your suggestion, to make sure there is someone in charge for a particular day, we can set up a wiki page to sign up for days (not weeks). It would be great if we can have at least 2 people on call for a day. Though it is not a disaster if a few new entries get missed, since we can always process them later. We just need to make sure not to build a huge backlog, and do as much preprocessing as possible before assigning a bug to a developer. For anyone who cannot commit to a regular schedule, a search on trac for tickets assigned to the B-team will point what needs to be classified, so they can help at any point without signing up if they wish to. The B-team should be responsible for doing the following before passing a bug on to a developer: - make sure there is enough information to reproduce the problem - check if it is already reported, if so close the current as a duplicate - find which area of the code the problem seems to occur People can always ask for help on the mailing list if there is a problem with this phase. - assign to a developer only if they agree to work on the problem, otherwise leave the issue in a confirmed state, assigned to tbd (these terms can also be used to search for things to do...) The B-team can also handle the report a problem link from the notebook, the problems reported on ask.sagemath.org, or the sage-support mailing list, as required. Comments? Any takers? I'd like it if someone takes the lead for the next few months, since I really need to be working on finishing my thesis. I am still willing to spend some time on bug wrangling these days, since I try to do that already (like quite a few other people) so I can still sign up for some days. 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
[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
[sage-devel] Re: Regression testing
This would be a good addition to the sage developement process indeed. Before going trough all the work of implementing this stuff, it might be wise to first look what's already out there. It might prevent you from doing double work, or give inspiration on how to do it. There seems to be a package wich already does some performance testing in the form of pyUnitPerf: http://sourceforge.net/projects/pyunitperf/ . There is also a coding recipe that tries to make timing results compareble across machines by comparing test times to a performance test of the machine: http://code.activestate.com/recipes/440700-performance-testing-with-a-pystone-measurement-dec/ Since we're probably not the only ones wanting this sort of testing possibility it might be interesting to maybe try to collaborate on this with programmers of other (open source) python projects and make a standalone project of this, in this way we wouldn't have to maintain it all by our own and is entirely in the open source spirit. - Maarten Derickx On Oct 21, 6:55 am, Robert Bradshaw rober...@math.washington.edu wrote: On Wed, Oct 20, 2010 at 5:33 PM, David Roe r...@math.harvard.edu wrote: There are a number of tickets in trac about performance regressions in Sage. I'm sure there are far more performance regressions which we don't know about because nobody noticed. As someone writing library code, it's generally not obvious that one is about to introduce a performance regression (otherwise you'd probably not do it). There have been instances where I've wondered whether a change I was making might have unintended consequences for performance, but testing all the ways in which this could manifest is laborious. Consequently, I've been thinking recently about how to detect performance regressions automatically. There are really two parts to the problem: gathering timing data on the Sage library, and analyzing that data to determine if regression have occurred (and how serious they are). +1. This has been lacking for a long time. Data gathering: One could modify local/bin/sage-doctest to allow the option of changing each doctest by wrapping it in a timeit() call. This would then generate a timing datum for each doctest line. * these timings vary from run to run (presumably due to differing levels of load on the machine). I don't know how to account for this, but usually it's a fairly small effect (on the order of 10% error). * if you're testing against a previous version of sage, the doctest structure will have changed because people wrote more doctests. And doctest lines depend on each other: you define variables that are used in later lines. So inserting a line could make timings of later lines incomparable to the exact same line without the inserted line. We might be able to parse the lines and check that various objects are actually the same (across different versions of sage, so this would require either a version-invariant hash or saving in one version, loading in the other and comparing. And you would have to do that for each variable that occurs in the line), but that seems to be getting too complicated... Many users will only have one version of sage installed. And even with multiple versions, you need somewhere to PUT the data in order to compare to later. One way of handling these problems is to create a relational database to put timings in. This could also be interesting for benchmarketing purposes: we could have timings on various machines, and we highlight performance improvements, in addition to watching for performance regressions. So, here's a first draft for a database schema to put timing data into. I've included a description of each table, along with a description of columns I thought were non-obvious. I'm definitely interested in suggestsion for improving this schema. Table: Hosts # computer information; including identifying data to determine when running on same host col: id col: identifying_data # some way to uniquely identify the computer on which a test is being run. Presumably the output of some unix function, but I don't know what. Table: Sage_version # a table giving each existing version of Sage an id # the ids for official sage releases should be consistent across databases; # users can also create their own temporary versions which use a different block of id numbers. # when a new version is created, the Files, Doctest_blocks and Doctest_lines tables are updated col: id col: version_name # string defining the version col: prev_version_id # versions should be totally ordered. Since we want to reserve some id space for official sage versions and other space for users, this can't be done by just the numerical id. Table: Files # a table for all the files in sage that have doctests col: id col: filename # e.g. sage/rings/integer.pyx # we might also want some other
[sage-devel] Re: Merging needs_review tickets in alphas
On 20 Okt., 19:10, Jeroen Demeyer jdeme...@cage.ugent.be wrote: So my concrete proposal would be: any author of a needs_review ticket can ask the release manager to merge his ticket in the next alpha release, the release manager then decides which needs_review tickets to merge. If the ticket does not get a positive_review by the time the release candidate comes out, it gets removed again. As a side effect of this, it might also be easier to find reviewers for these tickets, because they can test it simply by downloading the latest alpha. We should just make sure tickets don't get a positive review (and finally merged) *solely* by blind testing, i.e., the *code* / sources should also still get properly reviewed by at least one person. But I agree it seems often the case a mature ticket doesn't get a positive review early (and therefore not merged) just because the reviewer hesitates due to a lack of resources (accessible test platforms or simply time to test on a wider range of systems). Also, in case an already merged needs review ticket requires further changes, it should be well-documented on the ticket which patch(es) went into which alpha. An alternative for larger tickets is of course to open follow-ups. If not too many tickets get tested this way, there shouldn't be much trouble with rebasing other tickets that were based on a later unmerged volatile one. 2ct, -Leif -- 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] Review wranglers
In order not to overload the bug wranglers thread too much I'm starting a new thread. One thing which came up in that thread is the difficulty of finding reviewers. I also agree that this is an issue. For small bug fixes, the time to find a reviewer totally dominates the patch development time. For big tickets, in some cases there are very few people (possible none) who are able or willing to do the review. Sometimes it can happen that perfectly good patches fixing real bugs just get lost because nobody reviews them (this almost happened to #9799 for example). So while a bug wrangler team might be needed to keep the users happy, maybe there should also be a review wrangler team or something to keep the developers happy. It would be good if there was a list of people willing to do reviews and on which subjects. Jeroen. -- 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] Writing parallel code in Cython
I tend to write code in Cython, and then call it through an @parallel wrapper. This doesn't support mpi or anything fancy, but it's quite effective for what I've needed. On Thu, Oct 21, 2010 at 4:57 AM, Mitesh Patel qed...@gmail.com wrote: Are there accepted idioms for writing parallel code in Cython for the Sage library? I don't yet have a specific application in mind, but I'm interested in learning from any examples. -- 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] Writing parallel code in Cython
On Thu, Oct 21, 2010 at 4:57 AM, Mitesh Patel qed...@gmail.com wrote: Are there accepted idioms for writing parallel code in Cython for the Sage library? I don't yet have a specific application in mind, but I'm interested in learning from any examples. I personally think how to write parallel code (or any code) often depends *immensely* on the specific application. That said, I once suggested this to one of Craig Citro's undergrad professors who I had lunch with and he immediately said his main research was to argue that my perspective was completely wrong. So YMMV :-) -- William -- 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 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] Review wranglers
On Thu, Oct 21, 2010 at 8:25 AM, Jeroen Demeyer jdeme...@cage.ugent.be wrote: In order not to overload the bug wranglers thread too much I'm starting a new thread. One thing which came up in that thread is the difficulty of finding reviewers. I also agree that this is an issue. For small bug fixes, the time to find a reviewer totally dominates the patch development time. For big tickets, in some cases there are very few people (possible none) who are able or willing to do the review. Sometimes it can happen that perfectly good patches fixing real bugs just get lost because nobody reviews them (this almost happened to #9799 for example). So while a bug wrangler team might be needed to keep the users happy, maybe there should also be a review wrangler team or something to keep the developers happy. It would be good if there was a list of people willing to do reviews and on which subjects. Not to sound pessimistic, but something like this has been tried before (the editorial board). For small fixes, I'd say automation is the key (so I can just look at the code and say yes, or *easily* try it out.) For big tickets, if there's no one willing or able to do the review, than I'd say most of the time they should be broken up into pieces that can be reviewed. - 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
[sage-devel] Re: build and test reports server
On Sep 5, 4:04 pm, William Stein wst...@gmail.com wrote: On Sunday, September 5, 2010, David Kirkby david.kir...@onetel.net wrote: On 5 September 2010 11:01, YannLC yannlaiglecha...@gmail.com wrote: Would it be a valuable project to write scripts e.g. sage-test- report / sage-ptest-report producing xml output compatible with the CDashschemehttp://public.kitware.com/Wiki/CDash:XML. I guess it needs only some modifications of the sage-test / sage-ptest scripts. Does anyone ever thought about this? I think it might be a relatively easy way to get automated build/test reports. Yann People have thought of it, and its been discussed. Though I think getting the test framework in a better shape is a higher priority. Until such time as those can be relied upon, I don't there's a lot of point in making automated responses. I disagree. The two problems can be worked on in parallel. If somebody wants to write something like Yann proposes, that would be great and could definitely happen today. -- 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 athttp://groups.google.com/group/sage-devel URL:http://www.sagemath.org -- William Stein Professor of Mathematics University of Washingtonhttp://wstein.org Hi, Hoping to obtain a bit more feedback, here is a first minimalistic example, * first the result, only testing the gsl subdirectory (best viewed with firefox): http://yann.laiglechapuy.net/spkg/sage_cdash_7f193cfcc6d5_2010-10-22_02:13:51.849502.xml * and here is the script (to be placed in SAGE_ROOT/local/bin, based on sage-test): http://yann.laiglechapuy.net/spkg/sage-test-cdash Of course the report could be better (in case of failure, the cause is not reported yet), but it's just to demonstrate that it would definitely be quite easily feasible. Do you think this might be useful? Is anyone willing to try to install a CDash server for Sage? Yann -- 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: Differential Geometry via SAGE
Run a Sage Days workshop!? Good idea, thanks a lot! At the same time, better first to get some results and to have at least a small group working in this direction, in order to have some base for discussion (not only good intentions, but some real things). Let us look how the things will go. If good, I think we should organize this event. I did not know that Mathematica includes packages in differential geometry, maybe because I haven't used it for a long time. I know that Maple has a lot of differential geometry implemented, but also I have no real experience in it, because I prefer the open source tools. Last years I used maxima, and then Sage. Anyway, the experience of professor Jack Lee surely can help much in the development of differential geometry in the Sage. Mikhail -- 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] bug wranglers
On Thu, Oct 21, 2010 at 6:03 AM, Burcin Erocal bur...@erocal.org wrote: On Sun, 17 Oct 2010 15:56:41 +0100 Martin Albrecht martinralbre...@googlemail.com wrote: I was thinking of setting up trac to send a notice to a mailing list for each new issue. Then people interested in this effort can follow this list and help out. Is this possible? Can someone familiar with the trac set up comment? IMHO, distributing work day by day, or weekly is still putting too much load on one person. It should be enough if someone contributes to one issue per day. 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. My guess would be that we won't have the issue with locking very often (i.e. too many people doing too much work) but with no one feeling responsible. I guess for me your suggestion would turn out something like this: 1) I sign up to that mailing list since I feel a responsibility of contributing to Sage in such a way 2) For the first few days or weeks I go through newly opened tickets as you suggested. 3) Eventually, probably in some phase where I have less disposable time, I give up on dealing with this e-mail since somebody else will take care of it. I know this scenario too well. We should try to avoid overloading people or relying on the efforts of only a few people as much as possible. Of course, the answer could just be to not do step 3, but I would assume that it would happen to many of us. Being responsible for a week a time is something more local or short-time which would make it easier for me to commit. 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. To given an example of the workload here's the list of tickets created on the 15th. It seems 3-5 new tickets a day is the normal load: snip ticket descriptions Thus, as a rule of thumb we could say whoever is responsible for a day should deal with five tickets old and new. This seems like about 1-2h of work which seems doable to me. Of course, if many people feel differently then we should choose a different path. I suggest still setting up a mailing and assigning all new bugs to a B-team user on trac with email address pointing to this list. Following your suggestion, to make sure there is someone in charge for a particular day, we can set up a wiki page to sign up for days (not weeks). It would be great if we can have at least 2 people on call for a day. Though it is not a disaster if a few new entries get missed, since we can always process them later. We just need to make sure not to build a huge backlog, and do as much preprocessing as possible before assigning a bug to a developer. For anyone who cannot commit to a regular schedule, a search on trac for tickets assigned to the B-team will point what needs to be classified, so they can help at any point without signing up if they wish to. The B-team should be responsible for doing the following before passing a bug on to a developer: - make sure there is enough information to reproduce the problem - check if it is already reported, if so close the current as a duplicate - find which area of the code the problem seems to occur People can always ask for help on the mailing list if there is a problem with this phase. - assign to a developer only if they agree to work on the problem, otherwise leave the issue in a confirmed state, assigned to tbd (these terms can also be used to search for things to do...) The B-team can also handle the report a problem link from the notebook, the problems reported on ask.sagemath.org, or the sage-support mailing list, as required. Comments? Any takers? I'd like it if someone takes the lead for the next few months, since I really need to be working on finishing my thesis. I am still willing to spend some time on bug wrangling these days, since I try to do that already (like quite a few other people) so I can still sign up for some days. I'd certainly be willing to pitch in, but probably wouldn't be able to commit to specific days. If no one's opposed, I'll at least add a confirmed state on trac. - 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: [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
[sage-devel] Trac components
Following up on the bug wranglers thread, it would make sense to have a more even bug classification. The current component division has just grown as people have added to it, and is not very coherent. Here's what I propose, feel free to revise or tear it apart: building basic arithmetic categories/coercion documentation (includes website/wiki) graphics notebook packaging porting - windows porting - unix testing calculus/symbolics combinatorics commutative algebra crypto geometry/topology graph theory (or should this be part of combinatorics?) group theory linear algebra number theory numerical/analysis stats If we decide to be more granular, we could at least do number theory - elliptic curves number theory - modular forms ... for easy viewing and searching. Keywords could also be used to differentiate tickets within a category. - 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: [sage-devel] pari-2.4.3 (testing, ALPHA) released
On 10/ 8/10 10:18 PM, Jeroen Demeyer wrote: (forwarding this from http://pari.math.u-bordeaux.fr/archives/pari-announce-10/msg0.html) Dear PARI lovers, I would like to announce the release of pari-2.4.3-ALPHA. The sources can be obtained through the address http://pari.math.u-bordeaux.fr/download.html I don't know, but I suspect the alpha may be more stable than our svn snapshot - that is *generally* the case. So it might be worth integrating the alpha into sage sooner rather than later. It should also make updating to 2.4.3 easier when it does finally get released. Though given the hassle to get the last Pari into Sage, perhaps you have had enough of that!! I for one would not blame you. You put a lot of work into getting that merged. I certainly will give it a try on sage-on-gentoo. From a distro packager perspective I'd rather deal with the alpha that can be downloaded than a svn snapshot for which I would have to prepare a real tarball rather than using the sage spkg. I'll be sure to report problems or success. As I said I would report I should. Used pari-2.4.3 against sage-4.6.alpha3 and ran the long tests on my x86 box. It didn't cause any extra doctests failures. Currently building rc0 including the change from the .p9 spkg of pari. Francois -- 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: Differential Geometry via SAGE
On Thu, Oct 21, 2010 at 7:46 PM, mikarm mik...@gmail.com wrote: Run a Sage Days workshop!? Good idea, thanks a lot! At the same time, better first to get some results and to have at least a small group working in this direction, in order to have some base for discussion (not only good intentions, but some real things). Let us look how the things will go. If good, I think we should organize this event. That's a great plan. Just let me know later if/when you decide, and I'll see what is possible/fundable, etc. I did not know that Mathematica includes packages in differential geometry, maybe because I haven't used it for a long time. I don't have any personal experience with it easier, but have heard about it from other people. I don't know if it is included in Mathematica or not. I know that Maple has a lot of differential geometry implemented, but also I have no real experience in it, because I prefer the open source tools. Same here :-) Last years I used maxima, and then Sage. Anyway, the experience of professor Jack Lee surely can help much in the development of differential geometry in the Sage. Mikhail -- 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
