Anne Schilling <[email protected]> writes: > Here are several *ideas*: > > * We should run daily tests on the "needs review" section and pop patches > off that section if the tests do not pass (or people are not actively > working > on making them pass). > > * Everyone should try to get their patches into main-sage in a reasonable > time frame or remove their patches from the queue if they are outdated. > > * Perhaps we should have a second queue for only the patches currently > actively developed and in the review or final development process. > This queue would only be maintained on the very last version of sage > and patches are removed once the next version of sage comes out. > This would take the extra constraints off developers to, at the same time, > make their patch apply cleanly on a given version of sage and juggle > the tail of sage-combinat patches that lie on top of it. > This caused quite some frustration to both Franco and Mike and myself last > week trying to work on some large patches.
Although I am now relieved that I didn't break anything, let me add one other idea: in the unittesting package for fricas, two things turned out to be very useful: 1) being able to mark tests as "expected to fail" 2) a statistic how many tests were run how many failed, but should have passed how many passed, but were expected to have failed. with these two, I think one could actually require that no unexpected failures happen at any time -- the only problem being that fixing something somewhere might break something elsewhere, but that problem exists now, too. I do not know how much energy one should spend on that, however. Best, Martin -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" 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/sage-combinat-devel?hl=en.
