Le mercredi 25 octobre 2017 18:10:50 UTC+2, vdelecroix a écrit : > > You are suggesting to reread a very long thread... not very useful to > get new people involved.
A summary is [available](https://groups.google.com/d/msg/sage-devel/fE45025Wphs/mKdCAeNhAgAJ), the final tally being [here](https://groups.google.com/d/msg/sage-devel/fE45025Wphs/rZ0xwAyJCAAJ). > As far as I understand there are distinct things: > > A) distributing Sage sources (which has few to do with SSL) > B) building Sage with or without SSL support > C) distributing Sage binaries with or without SSL > > All are different things. Which one are you talking about when saying > "inclusion of OpennSSL"? Before talking about implementation it would > help to have clear goals. > All of them. With qualifications : * Sage sources : a consensus seems to form on Sage-the-distribution being too large. A review of what needs to be inclided, what can be corrected in the interfaces and what can be used "raw" is in order. Discussion to open ? * Building Sage without SSL support : that's the object of the present proposal. It should be an _option_, not the default, as it is now. We shouldn't have to maintain such "anti-OpenSSL patchjes" vrom upgrade to upgrade. And we shouldn't have to patch software that _wants_ SSL support, such as R, or obtain crippled software such as pip. * Distributing binaries : a consensus seem to exist (even from Jeroen !) that binaries should support SSL. -- Emmanuel Charpentier Vincent > > On 25/10/2017 18:01, Emmanuel Charpentier wrote: > > The recent vote on the inclusion of OpennSSL in Sage has shown that some > > Sage developers > > [wished]( > https://groups.google.com/d/msg/sage-devel/fE45025Wphs/mKdCAeNhAgAJ) > > to keep the ability to build Sage without dependence on this contentious > > library. > > > > I think that this can be implemented, thanks to Git, in the following > > manner : > > * Prepare a branch (let's say `anchorite`). > > * Follow the [Trac ticket](https://trac.sagemath.org/ticket/24107) > aiming > > at the inclusion of OpenSSL > > * At this ticket merge into Sage, revert the pertinent commits in > > `anchorite` > > * At each point you want to release, merge with the branch you wish to > > reach to in `master` or `develop`, and reverse again. > > * If new additions or patches rely on the presence of OpenSSL, add them > to > > your set of patches to be reversed, rinse and repeat... > > > > In short, the delta between `master` or `develop` and `anchorite` will > be > > the sum of patches reversal involvig OpenSSL. > > > > This is easy to do for people using git as thei source. The problem is > not > > so simple to release tarballs or binaries : a synchronization with the > > release manager is necessary. And I haven't the foggiest idea on how to > > proceed, for lack of knowledge of the release process. > > > > No ,proposal ticket (yet), since this is mainly an organizational > issue... > > > > Your inputs, please ? > > > > -- > > Emmanuel Charpentier > > > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
