On Wednesday, 27 January 2016 15:59:34 UTC, 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. >
For the record, I never proposed to create a fork of either of them in the 1st place. Hopefully nauty 2.6 will be released under a GPL-compatible license, and IMHO it was important to show the will to create a fork. I might also remind you about csdp optional package, for which I was forced on http://trac.sagemath.org/ticket/14505 to do a lot totally useless re-packaging, only to be thrown away when the switch to git has taken place. And csdp is very similar to what I propose (http://trac.sagemath.org/ticket/19967) in one or another way with cliquer - adding a sane building system. And a solution is pretty similar too (cliquer is quite easy as it has no external dependencies, but on the other hand it has no directory structure at all, everything is dumped in one place). Both csdp and cliquer are quite old, essentially being unchanged for years and years. > 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. > > I really do not understand why a complicated, buggy, hard to maintain, fix, or even read patches and scripts (e.g. https://github.com/sagemath/sage/blob/master/build/pkgs/cliquer/spkg-install and its role in Sage 7.0 OSX binaries facepalm) should be preferred to an honest public git repo with our (trivial) changes laid out nicely, while autotools do the heavy lifting for us. Dima > > 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.
