Helloooooooooo Andrew ! > I'm sure that I should drop this but...
At this level it may not hurt anymore :-) > When ever anything gets big enough I think this starts to break down. For > example, when I whined about the lack of documentation for the pickle jar > the people who put this is place didn't feel the need to step in and address > this. Even though I am just a sage-combinat customer:), I posted a patch on > trac and it is being reviewed (really!). HMmm.. I don't agree with that. I do not work with that many Sage developpers but I am totally convinced that any of them feels responsible about his own code to fix it when a bug is found. But you talk of documentation, and there I totally expect that it may not work anymore, as it is less "urgent and dangerous". At least for the classes I am patching now, I am pretty convinced that the explanation lies in the fact that "nobody here wrote them". I think that we are rather on the ascending path than the final explosion. > I agree that's nice, but what I am complaining about is a general lack of > documentation in sage, particularly for the metaclass framework, rather than > documentation for code in sage/combinat. If you check, the code in > sage/combinat has a relatively high coverage rate. Well documenting the methods when it comes to categories is not really helping, it asks for a more detailed explanation. This way of writing doctests works nicely for the graph stuff, where you only want to know what the method parameters mean and what the output is quickly, but the category stuff only asks for a 10 pages explanation with paragraphs, definitions and a long list of corner-cases situations. >> One other point I really do not like about the combinat model is that, >> unfortunately, you all know each other. > > I am really quite amazed that you see this as a bad thing! Ahhah. Sorry. I love to present as a bad thing something that is definitely good, and the opposite too. Sometimes I get convinced that it helps to think... There are many situations where you do not see the very bad sides of a good situation. "It looks so good, it just has to have good sides only !". But I insist that it is not only good in this case, especially when documenting code. Florent and I have done the same thing a couple of times : he has a patch to write and I do not know what is it, or barely, and I try to write its documentation while he explains it to me, and while I ask him questions. This way, you know what a totally ignorant users needs to know when he first meets the class. But the same way that -- after a while -- Sage developpers are totally unable to see things through the eyes of a newcomer and take a LOT for granted, it is hard to explain to somebody new something that you have taken for granted for weeks while talking with a colleague. Of course it is great to be able to talk together. I like this very much, even though I keep complaining about everything. Nicolas and Florent teach me many things quicker than I would have been able to teach myself otherwise(we find bugs by just doing that), but there is, in this way of working, a problem that does not exist when you cannot talk with each other : the guy who does the review will get the very same input the users will : the doc, and nothing else. > I think that was you are really complaining about are bug fixes which end > up in the sage-combinat queue but are not posted to trac. Yep > I fully agree that > patches should be posted to trac as soon as they are ready for review and > that people shouldn't keep half finished patches lying around in the > sage-combinat queue, or elsewhere. I don't see any harm, however, in a patch > being both on trac and also in the sage-combinat queue if it is relevant. Oh. I'm talking about the development model, and actually of... politics. If you keep adding fixes to the combinat queue, the bug will be fixed as far as the combinat guys are concerned, and they will not have any need to send it to trac. There is no need, and so it does not get done. Of course there is nothing wrong with having bugfixes in Sage-combinat. There is, for instance, no problem at all with including inside of Sage combinat a positively reviewed patch that will be merged ..... later, when Jeroen will feel like doing it. But the point is that if you insist a bugfix patch should not be there unless it is already positively reviewed, or not at all, then I am pretty sure everybody will send those patches to trac, because like everybody you need to have the bugs you meet FIXED in the code you work with. >> 2) Something I discussed with Florent : everybody in Sage-combinat should >> have at most 2 or 3 patches in the queue. Nothing more. If you want to add >> another one, get your patches merged into Sage > > > As Anne said, "it would be a good idea to try to integrate patches in the > sage-combinat > queue more quickly." That will not happen by just asking, though. That's what a development model is. That's what politics is all about. There are ways of doing things which infuence the way things are actually done. With the current combinat model, there is no need for the combinat developpers to send their code to Sage. That's why I call it a fork. >> 3) Why the hell do you need to have your own fork anyway ? (just my own >> thought, but I still don't exactly get it) > > > For me one of the key advantages of the sage-combinst queue is that it > allows code to be used and tested while it is being developed and before it > is reviewed. The best way to test code it to use it, so this actually saves > a lot of time and leads to better code. I know, I know. But look at the bad sides too ! Look at what you have to pay in exchange for that ! And did you ever really work with the REAL Sage ? Things can go pretty fast there too. And you can trust each other's code because it is fixed, and the documentation gets written too. It's not thaaaaat bad. But please, see that your development model has many good sides, like the one you mentionned, but that it comes with a load of problems that cannot be solved without changing the way you work. That's totally one of those ! This advantage is what makes combinat behave like a fork of Sage ! You are totally independent of Sage, you don't *NEED* to contribute to have your version of it evolve, and that's the problem ! >> 4) Just look at the TRAC section named combinat. Each time I go look at >> the patches, I just dream to put them all on "need_work" state. > > > I think this is a little spurious: you see a similar picture with every > component of sage, especially when you adjust for the size of the > components. > I think that this is a fair criticism of the sage-combiat patch > queue but not of the patches on trac. Well. To me it gave an idea of how patches can be as good as dead, even though you already use them in combinat. > Btw, many of these posts on trac come > from the general sage community and in addition to patches being reviewed > there are also feature requests > Let me end by saying that I thought it funny that you make such a big > distinction between sage and sage-combinat as I don't really see a > difference. That's a problem. > As I see it, the development model of sage and sage-combinat, > which is after all just a subset, is exactly the same. NOooooooooooooooooooo pleaaaaaaase !! IT IS NOT ! That's my whole point ! I always say that combinat is a fork of Sage, because even if you say that patches will get merged eventually (and they sometimes do), in practice it behaves as a totally indepedent software with its developent model. You do NOT review patches internally as we do in Sage. In Sage, we actually have no way to share code unless it is clean and documented. You do NOT do that in combinat, for you work on those patches. You do not have this need, and so you work with your own copy/fork of Sage, and we don't get the bugfies, and we don't get the features that are not ready for a Sage review, etc, etc.. It's a fork, because it CAN behave so independently. Please, do not just stay convinced that "all combinat patches eventually get merged". Look at how it is in pactice ! It is much slower than that, and this is because, then again, you CAN share code without reviewing it, without writing documentation, without testing the cases the author has no interest in ! > The sage-combinat > patch queue makes it easier for people working on applications in algebraic > combinatorics to talk with each other and to exchange ideas. Yes. That's the good side of your development model. That's also why you behave like if you were working on a fork. > The queue is a > pain to maintain sometimes but I think it's infinitely better than emailing > patches back and forwards or pushing half finished patches to trac. YES, but if you were working with the Sage TRAC server the patches would HAVE to be finalised. Please please, that's the whole point ! > The bottom line, which is completely independent of the sage-combinat patch > queue, is that if you don't like something in sage then you have to jump in > and fix it -- or convince some one to do it for you! Ahahaha. That's why most bug reports begin with "Am I doing anything wrong or is there a problem with [...]" :-) And I forwarded a bug report just yesterday to a french developper who wrote some code we use in Sage, to get as an answer "Nono, it's not unpleasant for a bit to getbug reports ! I am glad to know this code is useful !" :-) Have fuuuuuuuuuuuuun ! Nathann -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. 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.
