Merging the flask notebook
Jeroen Demeyer
Please explain me the status of the flask notebook, whether, how and
when it should be merged into Sage.
Jeroen Demeyer
Let me clarify my questions a bit better:
1) Is the flask notebook ready to be merged into sage-4.7.2.alpha*?
This means: is it sufficiently mature and also positively reviewed?
2) Is the flask notebook either
(a) part of Sage, in which case it is simply a set of patches on Trac
which should be merged in the usual way by the Sage release manager.
(b) a separate project with a separate release manager and a separate
bug tracker which will give me a complete spkg to be merged into Sage.
(c) something in between, please clarify.
Note that I strongly prefer either (a) or (b) over (c).
Thanks,
Jeroen.
Mike Hansen
> This means: is it sufficiently mature and also positively reviewed?
>
> 2) Is the flask notebook either
> (a) part of Sage, in which case it is simply a set of patches on Trac
> which should be merged in the usual way by the Sage release manager.
> (b) a separate project with a separate release manager and a separate
> bug tracker which will give me a complete spkg to be merged into Sage.
> (c) something in between, please clarify.
> Note that I strongly prefer either (a) or (b) over (c).
I believe it will be (b) although there may be some tickets on the
Sage trac. You set them to a sage-notebook milestone if you want, and
they can be closed when the updated spkg gets into Sage.
--Mike
Jason Grout
Rado (the point guy for the flask notebook) apparently didn't see this
message. I just pointed to him, but it might also be good to post this
to sage-notebook.
Thanks,
Jason
Rado
copy from trac#11106
jereon>>>"""Rado, do you mean a new spkg in addition to the existing "sagenb" or will it be inside "sagenb"?
There is no problem with this but I think it is something that you really should think about. As I mentioned on http://groups.google.com/group/sage-release/browse_frm/thread/758ac9a5106f5d4f, I would like the flask notebook to be either
(a) 100% part of Sage, in which case it is simply a set of patches on Trac which should be merged in the usual way by the Sage release manager.
(b) 0% part of Sage, i.e. a completely separate project with a separate release manager and a separate bug tracker which will give me a complete spkg to be merged into Sage.
I believe that anything between these two extremes would create extra complications. Currently, option (a) holds for sagenb. I would not find it a problem if it starts out as (b) in the development phase but once it's merged it reverts back to (a), i.e. part of Sage.
Also keep in mind that a few tickets deal mostly with the Sage library but still need patches to sagenb, so maybe (a) would be a slightly better solution. Recent examples: #9976, #10052."""
I thinks its basically settled that I have to make a whole new notebook .spkg (thanks to Burcin for showing me how to do that.) That means going on with b) for the time being. I know that William is encouraging the view that the notebook is a separate project and will be using google code as tracker (i.e. option b)).
Then the question is should
1) the notebook stay separate on google code
or
2) close it and move back to track after initial flask release.
How does the community feel about either of those?
If I have to pick (hopefully I don't) I would stay on google code, because google code looks better than trac and it makes it easy to work with the usual hg push/pull, instead of monster patches and hg queues. I also see the benefit of going back to trak for better sage/sagenb release coordination.
That said seems that the majority of the issues with the notebook are sage independent (scalability, user and worksheet management, openid/LDAP, internalization of templates, etc.). So far only jmol and jsmath->mathjax required patches to both sage proper and sagenb.
I don't speak from experience and other opinions are welcome.
Rado
Robert Bradshaw
+1, I think it's a step backwards to move everything to trac. As I've
said before, in this system we're not even using a revision
control--we're just manually moving patches around.
> I also see the
> benefit of going back to trak for better sage/sagenb release coordination.
Like you, I don't see a huge amount of coordination required. (If
there was, I'd go so far as to say it should be part of the main
repo.) Also, I don't think the notebook needs the same kind of
refereeing that one wants for the mathematical portions of Sage.
> That said seems that the majority of the issues with the notebook are sage
> independent (scalability, user and worksheet management, openid/LDAP,
> internalization of templates, etc.). So far only jmol and jsmath->mathjax
> required patches to both sage proper and sagenb.
>
> I don't speak from experience and other opinions are welcome.
The big questions are
(1) Who is going to contribute.
(2) Who is going to organize/merge these contributions.
Especially for (2), if you are planning to continue to work on it and
accept contributions, then stay with the current system for sure. If
you are thinking that the Sage release manager manage it then move to
trac.
- Robert
kcrisman
Sebastien Labbe has this great new rst2sws functionality. He's even
based it off the flask notebook.
But over half the patch is to sagenb, not to the sage repository.
Even if this gets positive review on Trac, what guarantees that this
will end up in the sagenb? It could end up being a moving target.
At the very least, sagenb should (on the ideas mostly recommended
lately, that it should be an independent spkg) then be allowed to have
Sage-specific fixes/packages applied on an ongoing basis. Then
"upstream" should incorporate them as they have time. We do this to
fix other spkgs all the time - some of whom are quite slow to adopt
our fixes, if ever.
So there needs to continue to be a way for Sage developers to make
useful contributions that don't require them to be in two different
projects at the same time. Or?
- kcrisman