Hi, I have been using the sage-combinat branch from 2008 to 2010 (all of my patches were in sage-combinat before getting on the sage trac) and then stop using it. Here is my view of this. First I believe the following principle is simple but very important :
Principle #1 : The priority (ordering) of patches to be merged into Sage should be given to the next patch which is ready and have positive review. To me the main disadvantage of Sage-Combinat queue is that it does not tend to respect Principle #1. Here is why I claim this. First let us introduce some definitions. Definition #2 - "Conflict". There is conflicts between two patches if they is a conflict when applying one patch after the other or if the doctest of one patch is broken by the other. Principle #3 : When someone creates a patch in the sage-combinat queue, he or she will put the patch somewhere it does not disturb others, so somewhere it does not create conflicts with other patches. That means the patch will most probably be added after related patches susceptible to conflicts. The consequence of Principle #3 is that the creator of a patch in the sage-combinat queue accept that *the time before inclusion of its own patch into Sage is larger than the time of inclusion of all patches it depends on*. Moreover, those patches depends on others which depends on others and so on... Definition #4 - "Slow patch" : A patch is slow if it stays on the "needs work" or "needs review" status for a long time. The problem is that a certain patch might depend on a slow patch, so that it can be considered as a slow patch even if it is during a period of time while you are promptly working on Sage. I understand that a group of developpers working on similar research subject might work on similar patches/files and are suceptible to conflicts. Thus, it might be a good idea to share a common queue to "anticipate and see conflicts in advance". For example : the sage-combinat queue. But, this tends to respect Principle #3 which violates Principle #1. Another reason which tends to violate Principle #1 is that changing the series file (changing the order of patches) takes a non negligeable amount of energy so that you might prefer to keep the ordering as it is and defined following Principle #3. Indeed, testing if a patch commutes with others is not that fast to check : one must unapply the patches, change the series file, reapply all the patches, run sage -br (with hundreds of modified files!!!) Then, once the commutativity is proved, one must recheck that the patch still work before putting it under review (unapply patches to go back to you patch, sage -br (with hundreds of modified files again!!!!). You might after build the documentation doing sage -docbuild reference html (with again hundreds of modified files again!!!) Hence, I believe that a development model where there exists a sane competition to be the first to be merged (creating conflicts to eventual slow patches) might be better than a system which tries to avoid conflicts (favorising slow patches). I am looking forward to discuss with Nicolas, Florent and Nathann about it during the next meeting of Sage users in Paris region. Cheers, Sébastien -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/1HdTwfvjSqwJ. To post to this group, send email to sage-combinat-devel@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.
