Hi Sébastien, I have been active in the sage-combinat queue for a little over a year. Here is my impression of how the sage-combinat queue works. It could be that how I think that the queue works, or how it is supposed to work, is just wrong but to summarise I think that the queue currently works in exactly the way that you would like it to -- it's just that (to my knowledge) this isn't written down clearly anywhere.
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. > My understanding is that this is how the queue works: when a patch is ready for review then you move it to the top of the queue. The problem, I think, is that this is unofficial policy. Certainly, when I first started adding patches to the queue I had no idea how it worked and I was almost afraid to move things up and down in the queue least I broke something -- and, to be fair, until I understood how the queue work it was probably better for everyone that I didn't move my patches without some care. > 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. > > Most of the time new patches are added to bottom of the queue, precisely so that they don't create conflicts with existing patches. Occasionally I have seen patches added higher up the queue, but they have all been patches which were expected to be ready for review quickly. > 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... > I don't think that this is a consequence of #3 and nor is it the way that the queue is supposed to work: when your patch is ready to review you should move it (close to) the top of the queue. In fact, if you look this os documented in the series file where it says: # Patches needing review # # Prerequisites before putting a patch in this section: # - Patch with ticket on trac marked as needs review # - Patch uploaded or linked from trac # - All tests pass (at least those that were likely to get broken) My interpretation of this is that patches should be moved to the "Patches needing review" section of the queue/series file when they are ready. > > 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. > > If your patch really does depend on a slow patch then you have to wait for it. If, on the other hand, the two patches don't commute, but you are not really relying on the patch you can move your patch past the slow patch and ask the author to rebase their patch on yours. If your patch really does depend on the other patch then you have to convince the to finalise it or -- as I did once because the author busy doing other things -- take over the patch and finish it. 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. > As I just said, I disagree on this one. If your patch really does depend o another patch it can sometimes slow things down a little but usually it doesn't. On the other hand, when I hit true dependence it can be a hassle but it is also great that other people are writing thign which I can build on as it would be a pain to write all of this myself from scratch, > > 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!!!) > I haven't found this to be so painful. I move my patch to the place in the queue where I want it. I then try to reapply the queue. If something beaks I'll rebase the patch if it is obvious, especially if the patch is a "slow patch" (I'm never entirely comfortable rebasing other people's patches as officially this is frowned upon but it's easy and it keeps the queue healthy I do it and hoped not be get flamed. If the rebase looks too tricky then I put a guard on the patch. Once the queue applies I check to see if sage builds and usually it does. Once or twice I have had to track down a patch that is breaking the queue, but the error messages combined with a grep of the patch directory often identifies the culprit quite quickly. Once a horribly broke the queue. When it became clear that I couldn't fix it quickly I posted on sage-combnat for suggestions ad the issue was soon resolved. I agree that it would be good to make this process more efficient. Some are saying that the move to git will fix this (this is not reallty clear as some of this posts make it sound like git will even write the code for us). There was also a recent suggestion to have different "themes" in the combinat queue. Perhaps this would be an improvement. By in large, however, I think that the currently workflow is OK. If anything, once you get use to using hg, I think that the main issue is the (volunteer) review process. So far this has been ok for me (that Travis!), but I have a few patches sitting off the queue which may not be so lucky. Cheers, Andrew -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
