On Tue, Aug 16, 2011 at 9:04 AM, Aaron Meurer <[email protected]> wrote: > On Tue, Aug 16, 2011 at 8:15 AM, Vladimir Perić <[email protected]> wrote: >> On Mon, Aug 15, 2011 at 10:57 PM, Aaron Meurer <[email protected]> wrote: >>> On Mon, Aug 15, 2011 at 1:59 PM, Vladimir Perić <[email protected]> >>> wrote: >>>> Actually, I was trying to clean up our issue list a few times already >>>> (generally closing a few way, way outdated issues and such) and I was >>>> thinking about it in general. I was actually going to suggest we >>>> organize a "Bug Day" (or rather a bug weekend perhaps) to organize and >>>> close our issues. It would be cool to do this after all (or most) GSoC >>>> work is merged in, as I assume that will make further issues obsolete. >>>> Something like this might also motivate students to stay on SymPy by >>>> having them fix random issues and "branch out" from their little bit >>>> of code. Currently there are some 900 issues on the tracker and this >>>> basically means you need a direct link to an issue to find it and for >>>> it to be useful. >>> >>> Doc day sounds fun. Two years ago, we had a "Doc day", where a bunch >>> of people improved documentation (this is, e.g., the origin of the >>> Gotchas and Pitfalls document). Would you like to organize it? >> >> "Bug day", you mean? And yes, I'd like to organize something like >> that. I think though that we should wait to get the current GSoC work >> in, as people are busy working on that (reviewing, updating), and the >> new stuff might fix even more old issues (the integration work for >> example). I think doing it in two or three weeks is fine, though. > > Sorry, typo :) > >> >>> >>>> >>>> If we decide to do something like this (but also if we don't) we might >>>> also want to give some thought to our general organization in the >>>> issue tracker; it's a bit haphazard at the moment. Tagging works fine, >>>> but I'd like to see some more care given to the assignment of >>>> milestones - we don't really have any rules for it (unless I'm missing >>>> something). The problem here is that issues with milestones get pushed >>>> to the top of the list and get much more exposure as such; on the >>>> other hand, a lot of these aren't being worked on and so they clutter >>>> the list. Of course, this problem might simply disappear if we trim >>>> down our 900 issues to 200 or something (not that I expect it, >>>> though). >>> >>> The problem with milestones is that probably 80% of issues with >>> milestones get postponed at the release. Because this is a volunteer >>> project, the milestones really have no meaning other than "this would >>> be great." If no one works on an issue, it doesn't get fixed, >>> regardless of how important it is. >>> >>> I do agree that milestones are abused a little. The thing is, once >>> someone attaches a milestone to an issue, it never gets removed, just >>> postponed. >>> >>>> >>>> As part of a move to a more rapid release schedule, I'd like to see >>>> milestones used just for regressions (and perhaps some very obvious >>>> bugs) and have all issues without a milestone. We could introduce >>>> additional priority levels to further differentiate issues if >>>> required. This is just a thought, though, I'd much rather just have us >>>> be consistent. There's no point in adding a milestone to some random >>>> issue unless someone is working on it. >>> >>> I agree. Fewer issues should have milestones. >> >> Ok, so lets remove them and decide how we are going to use them in the >> future. You have bulk editing privileges, so just remove it as you see >> fit. I think "milestoned" issues shouldn't take up more than one, two >> screens (they take ~4 for me ATM), so that's perhaps 15-20 issues at >> the most. > > Bulk editing out the milestones is a bad idea, I think. You need to > read each issue to see why the milestone was attached and judge on an > individual basis if it's important. The next time I do a release, > when I go through the milestoned issues, I'll consider deleting the > milestone instead of postponing it for each issue. I'll add a note > about this to the release guide. > > >> >>> >>> I've been using the label Priority-Critical for issues that absolutely >>> *must* be fixed before the next release. The main purpose that the >>> milestones hold is that they are generally all gone through before a >>> release, and either fixed or (more usually) postponed. >> >> Ok, I feel if we cut down on the amount of issues with milestones we >> can then actually use milestones and not a special label, but an extra >> label is ok too. Perhaps it would be a good idea to write a wiki page >> detailing our current practices (basically, how you feel is best/how >> you do it, because there aren't any rules anywhere) and we can work >> from that. >> >>> >>> By the way, I think we should have more labels. There are a bunch of >>> topics that have a ton of associated issues, but are not grouped >>> together with any label. If you want to tag a bunch of issues with a >>> new label, just let me know, and I will create a new label in the >>> system (otherwise it will bug you about not having an official label). >>> I also have the ability to bulk edit issues, so if you want, you can >>> just give me a list of issues and I will mark them all with a given >>> label. >> >> Yeah, more labels are probably a good idea. I think the automating >> cc-ing of people for certain labels might be a big help (like you have >> me set for Python 3 and Testing) and if we had finer-tuned labels more >> people would be willing to put up with the extra traffic that entails >> (I know my two are almost unused). As for the actual labels to add, I >> don't know, I'm not really that familiar with most parts of SymPy. At >> the very least, each of our modules (directories under sympy/) should >> have their own tag. > > If there are a bunch of issues relating to the same thing, then they > should be grouped with a label. If it's not specific enough, though, > it won't be very useful. For example, just having a "functions" label > wouldn't be very helpful, I think. And you'd need to be careful with > a "core" label or else just about everything would fall under it. > >> >>> >>> I can also do other things like change the default ordering of issues >>> (right now it is lexicographic with respect to Milestone, then >>> Priority, then reverse Stars, then ID), add new labels, make only one >>> in a group of labels allowed (like is done with type, priority, and >>> milestone), create issues templates, and apply certain rules to issues >>> based on what labels it has. >> >> I think the current order is fine (if we trim down the milestones, of >> course). I also don't know if creating templates or the other stuff is >> needed really, but I'll give it some thought. > > Just letting you know the sort of things that can be done. Let me > know if you have an ideas. > > Aaron Meurer
By the way, another way that milestones are being used is to keep track of when we should remove deprecated behavior. I think we may be doing this wrong, though. Recently, Mateusz removed some deprecated functions that were removed in 2008 or 2007, and were marked for removal in 0.8.0. I think using versions, especially major versions, to mark removal of deprecated behavior is wrong. We should either use a specific number of versions (like three versions from now would be 0.7.4), and for example if 0.7.3 is really 0.8.0, then we should remark it as 0.8.1. Or, we should use time based milestones. I can add labels like Milestone-2012, Milestone-2012, etc. Finally, if we use version milestones for removing deprecated behavior, and we fix issue 2513, which means that we keep track of versions in the DeprecationWarnings themselves, we could just do a check of the code base before every release for any deprecated behavior that should be removed. What do people think about this? Aaron Meurer > >> >>> >>> Aaron Meurer >>> >>>> >>>> Thoughts? >>>> >>>> On Mon, Aug 15, 2011 at 9:30 PM, Aaron Meurer <[email protected]> wrote: >>>>> Hi everyone. >>>>> >>>>> I was bored today, so I wrote up a little script that opens a random >>>>> open issue in the issue tracker in your default webbrowser. It's at >>>>> https://github.com/asmeurer/Issue-Tools. I put it inside a large >>>>> GitHub project in hopes that I or some of you will write some other >>>>> cool or useful tools for working with the issues. >>>>> >>>>> But hopefully this little script will be useful to those of you who >>>>> get bored and want to contribute to SymPy, but don't really have >>>>> anything specific that you want to do. Just open a random issue and >>>>> work on that (or, as seems to be common, decide that the issue is >>>>> outdated and close it). >>>>> >>>>> Aaron Meurer >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "sympy" group. >>>>> To post to this group, send email to [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> [email protected]. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/sympy?hl=en. >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Vladimir Perić >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "sympy" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]. >>>> For more options, visit this group at >>>> http://groups.google.com/group/sympy?hl=en. >>>> >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "sympy" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/sympy?hl=en. >>> >>> >> >> >> >> -- >> Vladimir Perić >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/sympy?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
