Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/) be added as a standard Sage package. We now have a procedure that *all* spkg's must go through before they are added to Sage.
Quick question:
Do you think SQLAlchemy be added to Sage? [ ] +1 "yes" [ ] -1 "no"
1. GPL version 2 compatible license. (This rule will be reconsidered in December 2008. I.e., we might allow GPL v3 only code.)
2. The package must build on our supported architectures: * Linux x86, x86_64, itanium, ppc * OS X ppc, intel * Solaris sparc, x86_64 * MS Windows (or at least a reasonable plan for building in the near future)
3. Quality: The package should be "better" than anything else (that passes criteria 1 and 2) and an argument should be made for this. The comparison should be made to both Python and other software. Criteria in passing the quality test include: * Speed * Documentation * Usability * Memory leaks * Maintainable * Build time * Size * Dependencies
4. Interest and Demand: * JSAGE vote (majority) * A majority vote on sage-devel.
-- William Stein Associate Professor of Mathematics University of Washington http://wstein.org
On Mar 14, 8:53 pm, "William Stein" <wst...@gmail.com> wrote:
> Hi,
> Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/)
> be added as a standard Sage package. We now have a procedure that
> *all* spkg's must go through before they are added to Sage.
> Quick question:
> Do you think SQLAlchemy be added to Sage?
> [ ] +1 "yes"
> [ ] -1 "no"
+1
In this case I thought it was clear that there was sufficient demand
to get this merged. I.e. the discussion to merge this started before
"the rules" were even dicsussed.
> Here are some *guidelines* for voting/discussing:
> GUIDELINES FOR INCLUSION OF ALL NEW SPKGS IN SAGE
> 1. GPL version 2 compatible license. (This rule
> will be reconsidered in December 2008. I.e., we
> might allow GPL v3 only code.)
Yep.
> 2. The package must build on our supported architectures:
> * Linux x86, x86_64, itanium, ppc
> * OS X ppc, intel
> * Solaris sparc, x86_64
> * MS Windows (or at least a reasonable plan for building in
> the near future)
Pure python, no compiled code.
> 3. Quality: The package should be "better" than anything else (that
> passes criteria 1 and 2) and an argument should be made for this. The
> comparison should be made to both Python and other software. Criteria
> in passing the quality test include:
> * Speed
> * Documentation
> * Usability
> * Memory leaks
> * Maintainable
> * Build time
> * Size
> * Dependencies
While I personally never looked for alternatives the consensus in IRC
was that it is the best out there.
> 4. Interest and Demand:
> * JSAGE vote (majority)
> * A majority vote on sage-devel.
> On Mar 14, 8:53 pm, "William Stein" <wst...@gmail.com> wrote: > > Hi,
> > Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/) > > be added as a standard Sage package. We now have a procedure that > > *all* spkg's must go through before they are added to Sage.
> > Quick question:
> > Do you think SQLAlchemy be added to Sage? > > [ ] +1 "yes" > > [ ] -1 "no"
> +1
> In this case I thought it was clear that there was sufficient demand > to get this merged. I.e. the discussion to merge this started before > "the rules" were even dicsussed.
If there is sufficient demand, that'll be clear by how this vote goes. It's really better that we are organized and mature about how we add things to Sage at this point, I think. Otherwise, packages will slip in that will cause _you_ tons of grief down the road... as you no doubt know.
> > Here are some *guidelines* for voting/discussing:
> > GUIDELINES FOR INCLUSION OF ALL NEW SPKGS IN SAGE
> > 1. GPL version 2 compatible license. (This rule > > will be reconsidered in December 2008. I.e., we > > might allow GPL v3 only code.)
> Yep.
> > 2. The package must build on our supported architectures: > > * Linux x86, x86_64, itanium, ppc > > * OS X ppc, intel > > * Solaris sparc, x86_64 > > * MS Windows (or at least a reasonable plan for building in > > the near future)
> Pure python, no compiled code.
> > 3. Quality: The package should be "better" than anything else (that > > passes criteria 1 and 2) and an argument should be made for this. The > > comparison should be made to both Python and other software. Criteria > > in passing the quality test include: > > * Speed > > * Documentation > > * Usability > > * Memory leaks > > * Maintainable > > * Build time > > * Size > > * Dependencies
> While I personally never looked for alternatives the consensus in IRC > was that it is the best out there.
> > 4. Interest and Demand: > > * JSAGE vote (majority) > > * A majority vote on sage-devel.
> Cheers,
> Michael
> > --
> > William Stein > > Associate Professor of Mathematics > > University of Washingtonhttp://wstein.org
-- William Stein Associate Professor of Mathematics University of Washington http://wstein.org
> > On Mar 14, 8:53 pm, "William Stein" <wst...@gmail.com> wrote:
> > > Hi,
> > > Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/)
> > > be added as a standard Sage package. We now have a procedure that
> > > *all* spkg's must go through before they are added to Sage.
> > > Quick question:
> > > Do you think SQLAlchemy be added to Sage?
> > > [ ] +1 "yes"
> > > [ ] -1 "no"
> > +1
> > In this case I thought it was clear that there was sufficient demand
> > to get this merged. I.e. the discussion to merge this started before
> > "the rules" were even dicsussed.
> If there is sufficient demand, that'll be clear by how this vote goes.
> It's really better that we are organized and mature about how we
> add things to Sage at this point, I think. Otherwise, packages will
> slip in that will cause _you_ tons of grief down the road... as you
> no doubt know.
Oh, I look at any portability issue since I know whom it will bite in
the ass in the end. I agree that we need to go about this via some
process, but the fact that I merged a bunch of code dependent on this
which is a pain to remove makes this a rather inconvenient thing to do
now.
Since I also merged Setuptools (since it is a dependency of
SQLAlchemy) we have to go through the same process for that spkg,
too.
> > > Here are some *guidelines* for voting/discussing:
> > > GUIDELINES FOR INCLUSION OF ALL NEW SPKGS IN SAGE
> > > 1. GPL version 2 compatible license. (This rule
> > > will be reconsidered in December 2008. I.e., we
> > > might allow GPL v3 only code.)
> > Yep.
> > > 2. The package must build on our supported architectures:
> > > * Linux x86, x86_64, itanium, ppc
> > > * OS X ppc, intel
> > > * Solaris sparc, x86_64
> > > * MS Windows (or at least a reasonable plan for building in
> > > the near future)
> > Pure python, no compiled code.
> > > 3. Quality: The package should be "better" than anything else (that
> > > passes criteria 1 and 2) and an argument should be made for this. The
> > > comparison should be made to both Python and other software. Criteria
> > > in passing the quality test include:
> > > * Speed
> > > * Documentation
> > > * Usability
> > > * Memory leaks
> > > * Maintainable
> > > * Build time
> > > * Size
> > > * Dependencies
> > While I personally never looked for alternatives the consensus in IRC
> > was that it is the best out there.
> > > 4. Interest and Demand:
> > > * JSAGE vote (majority)
> > > * A majority vote on sage-devel.
> > Cheers,
> > Michael
> > > --
> > > William Stein
> > > Associate Professor of Mathematics
> > > University of Washingtonhttp://wstein.org
> --
> William Stein
> Associate Professor of Mathematics
> University of Washingtonhttp://wstein.org
> > > On Mar 14, 8:53 pm, "William Stein" <wst...@gmail.com> wrote: > > > > Hi,
> > > > Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/) > > > > be added as a standard Sage package. We now have a procedure that > > > > *all* spkg's must go through before they are added to Sage.
> > > > Quick question:
> > > > Do you think SQLAlchemy be added to Sage? > > > > [ ] +1 "yes" > > > > [ ] -1 "no"
> > > +1
> > > In this case I thought it was clear that there was sufficient demand > > > to get this merged. I.e. the discussion to merge this started before > > > "the rules" were even dicsussed.
> > If there is sufficient demand, that'll be clear by how this vote goes. > > It's really better that we are organized and mature about how we > > add things to Sage at this point, I think. Otherwise, packages will > > slip in that will cause _you_ tons of grief down the road... as you > > no doubt know.
> Oh, I look at any portability issue since I know whom it will bite in > the ass in the end. I agree that we need to go about this via some > process, but the fact that I merged a bunch of code dependent on this > which is a pain to remove makes this a rather inconvenient thing to do > now.
> Since I also merged Setuptools (since it is a dependency of > SQLAlchemy) we have to go through the same process for that spkg, > too.
Let's just say that if sqlalchemy gets voted in then setuptools does automatically.
> > > > On Mar 14, 8:53 pm, "William Stein" <wst...@gmail.com> wrote:
> > > > > Hi,
> > > > > Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/)
> > > > > be added as a standard Sage package. We now have a procedure that
> > > > > *all* spkg's must go through before they are added to Sage.
> > > > > Quick question:
> > > > > Do you think SQLAlchemy be added to Sage?
> > > > > [ ] +1 "yes"
> > > > > [ ] -1 "no"
> > > > +1
> > > > In this case I thought it was clear that there was sufficient demand
> > > > to get this merged. I.e. the discussion to merge this started before
> > > > "the rules" were even dicsussed.
> > > If there is sufficient demand, that'll be clear by how this vote goes.
> > > It's really better that we are organized and mature about how we
> > > add things to Sage at this point, I think. Otherwise, packages will
> > > slip in that will cause _you_ tons of grief down the road... as you
> > > no doubt know.
> > Oh, I look at any portability issue since I know whom it will bite in
> > the ass in the end. I agree that we need to go about this via some
> > process, but the fact that I merged a bunch of code dependent on this
> > which is a pain to remove makes this a rather inconvenient thing to do
> > now.
> > Since I also merged Setuptools (since it is a dependency of
> > SQLAlchemy) we have to go through the same process for that spkg,
> > too.
> Let's just say that if sqlalchemy gets voted in then setuptools does
> automatically.
Yep. I just wanted to make sure we don't have to do the same thing
tomorrow/late tonight when you see the 2.10.4.alpha0 changelog :)
> Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/) > be added as a standard Sage package. We now have a procedure that > *all* spkg's must go through before they are added to Sage.
> Quick question:
> Do you think SQLAlchemy be added to Sage? > [ ] +1 "yes" > [ ] -1 "no"
> Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/) > be added as a standard Sage package. We now have a procedure that > *all* spkg's must go through before they are added to Sage.
> Quick question:
> Do you think SQLAlchemy be added to Sage? > [ ] +1 "yes" > [ ] -1 "no"
>> Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/) >> be added as a standard Sage package. We now have a procedure that >> *all* spkg's must go through before they are added to Sage.
>> Quick question:
>> Do you think SQLAlchemy be added to Sage? >> [ ] +1 "yes" >> [ ] -1 "no"
On Mar 14, 10:48 pm, Jason Grout <jason-s...@creativetrax.com> wrote:
> William Stein wrote:
> > Hi,
> > 4. Interest and Demand:
> > * JSAGE vote (majority)
> > * A majority vote on sage-devel.
> I assume "majority" = "the sum is positive", right?
> Jason
\geq 0 - with wstein as the tie breaker? - In the Senat it is the
speaker, isn't it?
Just kidding. In the end I think it should be decisive in most cases.
We also discussed the time fame for votes on sage-devel and wstein
suggested 24 hours.
> Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/)
> be added as a standard Sage package. We now have a procedure that
> *all* spkg's must go through before they are added to Sage.
> Quick question:
> Do you think SQLAlchemy be added to Sage?
> [ ] +1 "yes"
> [ ] -1 "no"
> Here are some *guidelines* for voting/discussing:
> GUIDELINES FOR INCLUSION OF ALL NEW SPKGS IN SAGE
> 1. GPL version 2 compatible license. (This rule
> will be reconsidered in December 2008. I.e., we
> might allow GPL v3 only code.)
> 2. The package must build on our supported architectures:
> * Linux x86, x86_64, itanium, ppc
> * OS X ppc, intel
> * Solaris sparc, x86_64
> * MS Windows (or at least a reasonable plan for building in
> the near future)
> 3. Quality: The package should be "better" than anything else (that
> passes criteria 1 and 2) and an argument should be made for this. The
> comparison should be made to both Python and other software. Criteria
> in passing the quality test include:
> * Speed
> * Documentation
> * Usability
> * Memory leaks
> * Maintainable
> * Build time
> * Size
> * Dependencies
> 4. Interest and Demand:
> * JSAGE vote (majority)
> * A majority vote on sage-devel.
> --
> William Stein
> Associate Professor of Mathematics
> University of Washingtonhttp://wstein.org
On Mar 14, 2008, at 12:53 PM, William Stein wrote:
> Hi,
> Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/) > be added as a standard Sage package. We now have a procedure that > *all* spkg's must go through before they are added to Sage.
> Quick question:
> Do you think SQLAlchemy be added to Sage? > [ ] +1 "yes" > [ ] -1 "no"
A couple of questions: - is it worth making this optional for a period of time so that we can try it out? - is it really solving a problem (not hanging out on IRC much, I have no clue what the issues are)? Or maybe better: what problem is solved by including it in the standard packages? - is it sufficiently central that it has to be standard?
It's worth keeping the "base" install as small as feasible (without cramping Sage's functionality for most users). I noticed that 2.10.3 got about 20MB smaller compared to 2.10.2 (even though that was mostly documentation shrinkage :-}).
Thanks!
Justin
-- Justin C. Walker, Curmudgeon at Large Institute for the Absorption of Federal Funds ----------- My wife 'n kids 'n dogs are gone, I can't get Jesus on the phone, But Ol' Milwaukee's Best is my best friend. -----------
> On Mar 14, 2008, at 12:53 PM, William Stein wrote:
> > Hi,
> > Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/)
> > be added as a standard Sage package. We now have a procedure that
> > *all* spkg's must go through before they are added to Sage.
> > Quick question:
> > Do you think SQLAlchemy be added to Sage?
> > [ ] +1 "yes"
> > [ ] -1 "no"
> A couple of questions:
> - is it worth making this optional for a period of time so that
> we can try it out?
> - is it really solving a problem (not hanging out on IRC much,
> I have no clue what the issues are)? Or maybe better: what
> problem is solved by including it in the standard packages?
> - is it sufficiently central that it has to be standard?
> It's worth keeping the "base" install as small as feasible (without
> cramping Sage's functionality for most users). I noticed that 2.10.3
> got about 20MB smaller compared to 2.10.2 (even though that was
> mostly documentation shrinkage :-}).
setuptools is about 190 kb, sqlalchemy is about 1.6MB. So in this case
both spkgs are small. And sqlalchemy solves a bunch of performance
related issues that turn DSage from barely usable in certain
situations into some much more usable.
I share the desire with you to keep Sage as small as possible. And
setuptools has been optional for a while, sqlalchemy was never put in
the optional repo but had quite an intense review process.
> --
> Justin C. Walker, Curmudgeon at Large
> Institute for the Absorption of Federal Funds
> -----------
> My wife 'n kids 'n dogs are gone,
> I can't get Jesus on the phone,
> But Ol' Milwaukee's Best is my best friend.
> -----------
> On Mar 15, 1:01 am, "Justin C. Walker" <jus...@mac.com> wrote: >> On Mar 14, 2008, at 12:53 PM, William Stein wrote:
>>> Hi,
>>> Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/) >>> be added as a standard Sage package. We now have a procedure that >>> *all* spkg's must go through before they are added to Sage.
>>> Quick question:
>>> Do you think SQLAlchemy be added to Sage? >>> [ ] +1 "yes" >>> [ ] -1 "no"
>> A couple of questions: >> - is it worth making this optional for a period of time so that >> we can try it out? >> - is it really solving a problem (not hanging out on IRC much, >> I have no clue what the issues are)? Or maybe better: what >> problem is solved by including it in the standard packages? >> - is it sufficiently central that it has to be standard?
>> It's worth keeping the "base" install as small as feasible (without >> cramping Sage's functionality for most users). I noticed that 2.10.3 >> got about 20MB smaller compared to 2.10.2 (even though that was >> mostly documentation shrinkage :-}).
> setuptools is about 190 kb, sqlalchemy is about 1.6MB. So in this case > both spkgs are small. And sqlalchemy solves a bunch of performance > related issues that turn DSage from barely usable in certain > situations into some much more usable.
> I share the desire with you to keep Sage as small as possible. And > setuptools has been optional for a while, sqlalchemy was never put in > the optional repo but had quite an intense review process.
>> Thanks!
>> Justin
> Cheers,
> Michael
>> -- >> Justin C. Walker, Curmudgeon at Large >> Institute for the Absorption of Federal Funds >> ----------- >> My wife 'n kids 'n dogs are gone, >> I can't get Jesus on the phone, >> But Ol' Milwaukee's Best is my best friend. >> -----------
mabshoff wrote: > On Mar 14, 10:48 pm, Jason Grout <jason-s...@creativetrax.com> wrote: >> William Stein wrote: >>> Hi, >>> 4. Interest and Demand: >>> * JSAGE vote (majority) >>> * A majority vote on sage-devel. >> I assume "majority" = "the sum is positive", right?
>> Jason
> \geq 0 - with wstein as the tie breaker? - In the Senat it is the > speaker, isn't it?
> Just kidding. In the end I think it should be decisive in most cases. > We also discussed the time fame for votes on sage-devel and wstein > suggested 24 hours.
How about 2 business days? There are some days that I know I'd be too busy/rushed to comment on a package, much less try to install it. Would a package really need 24 hour turn-around time?
Or maybe a 1-2 business day vote for getting into optional, then at least one week there with a voting thread on sage-devel for inclusion into standard?
> mabshoff wrote: > > On Mar 14, 10:48 pm, Jason Grout <jason-s...@creativetrax.com> wrote: > >> William Stein wrote: > >>> Hi, > >>> 4. Interest and Demand: > >>> * JSAGE vote (majority) > >>> * A majority vote on sage-devel. > >> I assume "majority" = "the sum is positive", right?
> >> Jason
> > \geq 0 - with wstein as the tie breaker? - In the Senat it is the > > speaker, isn't it?
> > Just kidding. In the end I think it should be decisive in most cases. > > We also discussed the time fame for votes on sage-devel and wstein > > suggested 24 hours.
> How about 2 business days? There are some days that I know I'd be too > busy/rushed to comment on a package, much less try to install it. Would > a package really need 24 hour turn-around time?
> Or maybe a 1-2 business day vote for getting into optional, then at > least one week there with a voting thread on sage-devel for inclusion > into standard?
We want to keep this _really_ simple, and... Sage moves at the speed of light, so I say 1 day. Anyway, most people who care will answer quite quickly. If something is at all contentious though, then we could keep voting open longer. But if a package gets a bunch of +1's immediately, then the outcome is pretty clear.
On Fri, Mar 14, 2008 at 3:53 PM, William Stein <wst...@gmail.com> wrote:
> Hi,
> Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/) > be added as a standard Sage package. We now have a procedure that > *all* spkg's must go through before they are added to Sage.
> Quick question:
> Do you think SQLAlchemy be added to Sage? > [ ] +1 "yes" > [ ] -1 "no"
> Here are some *guidelines* for voting/discussing:
> GUIDELINES FOR INCLUSION OF ALL NEW SPKGS IN SAGE
> 1. GPL version 2 compatible license. (This rule > will be reconsidered in December 2008. I.e., we > might allow GPL v3 only code.)
> 2. The package must build on our supported architectures: > * Linux x86, x86_64, itanium, ppc > * OS X ppc, intel > * Solaris sparc, x86_64 > * MS Windows (or at least a reasonable plan for building in > the near future)
> 3. Quality: The package should be "better" than anything else (that > passes criteria 1 and 2) and an argument should be made for this. The > comparison should be made to both Python and other software. Criteria > in passing the quality test include: > * Speed > * Documentation > * Usability > * Memory leaks > * Maintainable > * Build time > * Size > * Dependencies
> 4. Interest and Demand: > * JSAGE vote (majority) > * A majority vote on sage-devel.
> -- > William Stein > Associate Professor of Mathematics > University of Washington > http://wstein.org
On Mar 14, 2008, at 12:53 PM, William Stein wrote:
> Hi,
> Yi Qiang has proposed that sqlalchemy (http://www.sqlalchemy.org/) > be added as a standard Sage package. We now have a procedure that > *all* spkg's must go through before they are added to Sage.
> Quick question:
> Do you think SQLAlchemy be added to Sage? > [ ] +1 "yes" > [ ] -1 "no"
+1 to SQLAlchemy, it looks like good project. Yi has apparently found it useful, how many other people out there have downloaded and tried this out? Anyone?
