Imho if upstream hasn't made any changes in the last 5 years and/or can't be bothered with the added value of building a shared library then its better to fork. Make a git repo under the sagemath github organization, done. Really, everything is a fork in git. Just get used to it.
On Wednesday, January 27, 2016 at 10:59:34 AM UTC-5, Jeroen Demeyer wrote: > > Hello sage-devel, > > There are various degrees of patching upstream projects for Sage: > > (0) vanilla upstream stable release > (1) upstream stable release with patches accepted by upstream > (2) upstream development code (e.g. git master) > (3) upstream code with patches not accepted by upstream > (4) fork upstream > > In my opinion, (4) should only be done if there is very good > justification for it (example: polybori was forked as brial because > upstream is dead). > > Dima Pasechnik recently proposed to do (4) for both nauty and cliquer, > but I think in both cases this lacks justification and (3) can be done > instead. > > I know it is a hard question what is acceptable under which conditions. > However, these questions regularly come up and it would be good to have > some guidelines. In particular, we should consider this in the light of > maintainability and distributability of SageMath. > > > Jeroen. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
