On Sat, Nov 24, 2012 at 9:57 AM, Sébastien Labbé <sla...@gmail.com> wrote: > 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.
Thanks for your well thought out analysis of the situation. > 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!!!) This does sound like a lot of boring manual labor to get good "ready" code into Sage itself. It also is something the patchbot is intended to solve--it's a pain to do manually but could totally be automated in the background. Ideally you could mark a patch as "ready to go in" and everything else would be automated (including seeing how far down the stack it could commute and whether it's feasible to merge into Sage proper. Perhaps part of the issue is that the true dependencies are linearized into a single queue. > 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). +1 > 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-devel" group. > To post to this group, send email to sage-devel@googlegroups.com. > To unsubscribe from this group, send email to > sage-devel+unsubscr...@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
