On Friday, April 15, 2016 at 10:40:25 AM UTC-7, Dima Pasechnik wrote: > > > > On Friday, April 15, 2016 at 5:06:34 PM UTC+1, 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. >> > > Could you perhaps point out at these? > Are there any issues/pull requests on sagenb related to such changes? >
I don't know if there are any right now, but I think that many of the recent changes in sagenb have come because there were changes in the Sage library. Maybe "difficult" is not the right word, but this adds an artificial layer of complexity: instead of making a few possibly trivial changes in the relevant sagenb files within Sage, for example when the location of the built documentation moved, it takes a pull request, someone to handle that request, someone to put together a new sagenb release, etc. It often (almost always?) ends up being the same people working on the Sage trac ticket and the sagenb pull request, so we're adding some inefficiencies to the system. If we could deal with the issues with just a trac ticket, that would be better. > > > >> 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.
