>
> 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.

Reply via email to