On Fri, Apr 15, 2016 at 9:21 AM, Vincent Delecroix <20100.delecr...@gmail.com> wrote: > +1 (both for Jeroen proposition and John intervention) > > Indeed the -1 from William is just about a general philosophy that he will > be of no help implementing.
I would like to hear what Volker thinks. I wonder if his proposal might even to be to consider making sagenb an optional package. > > I agree with Erik remark but holding this move makes it just worse. And > doing it will not prevent us from analyzing why we failed keeping Sagenb > leaving outside of Sage. > > > On 15/04/16 13:06, John H Palmieri wrote: >> >> +1. >> >> For those who disagree, please recognize that the current situation is >> unmanageable: there are interdependencies between sage and sagenb, so >> certain changes in sage require changes in sagenb. Getting those changes >> done in sagenb is difficult, because sagenb is not really actively >> maintained. So if you disagree, please suggest a concrete alternative, >> because (as Jeroen says) the status quo is not working. >> >> John >> >> >> On Friday, April 15, 2016 at 1:44:22 AM UTC-7, Jeroen Demeyer wrote: >>> >>> >>> Hello all, >>> >>> I propose to make SageNB no longer a separate package but to move it >>> back into the Sage git tree. For purposes of installation and use of >>> SageNB, it will still be a separate Python package, but the sources will >>> be in $SAGE_ROOT/src/sagenb instead of a separate git repo. The changes >>> to the Sage build system to support this move will be minimal. >>> >>> The reason is that SageNB is truly in maintenance mode currently. Making >>> new SageNB releases regularly to fix things is a burden for the SageNB >>> release manager Karl-Dieter Crisman. On #14840 [1], he said "the sooner >>> sagenb gets back in Sage proper, the better!" >>> >>> The original reason to split SageNB from Sage was to enable quick >>> development. That worked for a while, but now that development has >>> stalled, this reason no longer applies. A secondary reason was to make >>> SageNB truly independent from Sage, but that also never happened. So I >>> see no reason to keep SageNB split from Sage currently. >>> >>> I know this is a controversial proposal, but it will certainly be easier >>> to maintain SageNB this way. I also want to stress that this is >>> orthogonal to any future deprecation or removal of SageNB: we can still >>> do that from the Sage git tree. >>> >>> Jeroen. >>> >>> >>> >>> [1] http://trac.sagemath.org/ticket/14840#comment:58 >>> >> > > -- > 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. -- William (http://wstein.org) -- 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.
