Hi Nathan, I'm sure that I should drop this but...
I don't know. People usually pay attention to the code they wrote even much > later. I still write to Robert Miller when I have questions on the graph > backends, and I like to have his advice on Sage things from time to time. 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!). > > > The absent or poor documentation is what I like least about sage. > > Welcome to the graph world : > 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. 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! Because the people in sage-combinat do talk to each other you can, if you want, get a lot of feedback when writing something. Moreover, in my experience, when a patch is ready to be reviewed it normally happens very quickly. 1) A bugfix patch for something that is in Sage should NEVER be included in > Sage-combinat. It should be sent to Sage, and sage-combinat will inherit it > later, when Sage is updated. This way bugfix patches will be merged before > the author's death > 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. 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. > 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." 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. 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. 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. As I see it, the development model of sage and sage-combinat, which is after all just a subset, is exactly the same. 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. 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. 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! Cheers, Andrew -- 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.
