> > contributions. E.g., they won't even consider a new component be > added to Python unless somebody clearly commits to supporting the > contribution for "five years". And of course the people making that > commitment have to be reputable. We should do the same for Sage -- >
<sarcasm> Don't you think we should start by doing the same for Sage's own source code? Anybody who proposes a patch should agree to do the debugging/maintenance of what (s)he added for the next 5 years? Looks weird to only have this high level of expectation for third-party code only, and not for our own. </sarcasm> In Sage, we are at a level where some files don't have a clear "regular maintainer". We would need to be 10x more developpers to enforce such rules. For 'cliquer' in particular, maybe we could propose upstream a autotoolized build system, and see how it goes? We did it for 'planarity' not so long ago (and perhaps with others?). Our spkg-install file indeed contains several platform-specific instructions. Nathann -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.