On May 29, 2010, at 3:34 AM, Dr. David Kirkby wrote:
On May 26, 10:56 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
I didn't know anyone even looked at those numbers--maybe it would be
better to put it in the *past* so people know not to trust it. I just
deleted the date for now, though hopefully June is still a realistic
target.
- Robert
IMHO, Sage development should have a plan like Jeremy showed for
OpenOffice and FreeBSD - not have development occur in an
uncoordinated haphazard manner. That's not to say we expect everything
to happen on the days indicated, but at least have something to aim
at.
Both of those roadmaps seem to focus primarily on the a single release
cycle, which given their different pace, makes sense. On the other
hand, I'm not able to find a clear roadmap for Python--though at a
lower level PEPs serve the same purpose (though not tied to a date,
other than the release cycle ones) and they seem to get along just
fine. The Sage project does have some concrete goals [1] and we do
occasionally have specific pushes (e.g. the new symbolics, coercion,
linear algebra overhaul, documentation) though those are usually
shorter term (e.g. associated with a Sage Days).
The real question though is why do you think Sage would be better off
with a roadmap? Would we have more users? Happier users? Would it
attract more developers? Are we suffering due to the lack of a
roadmap? Or is it more of a PR need? Given that Sage has no full-time
developers, and in particular is primarily driven by the personal
needs of those who use it in teaching and research, I think it is
unrealistic to attach dates or releases to most feature requests or
bug reports unless someone is actively working on it (in which case
the answer is still "it'll be in as soon as I get it done" and given
our rolling release schedule there's no +6 months until the next
release). So what would be on this roadmap? The recent discussion
about overhauling permutation groups comes to mind, though again I
don't know if a timeline could be assigned at this point (but a Sage
Enhancement Proposal would be nice).
At the moment when I create a trac ticket, I gets a choice of several
milestones including 4.4.3 or 5.0. With no plan of what one of those
releases is supposed to consist of, when it is supposed to occur, its
hard to chose. (Actually, I just set it to the earliest, but if there
was a proper plan, then I'd be more choosy)
If something has a positively reviewed patch that doesn't break,
there's little motivation to put it off until a later release (meaning
the next one, if the current release is in a feature freeze--or I
suppose if the release manager decides do to a stability/bug-fix-only
release), so we always assign tickets to the next release, and bump
everything that didn't go in when a new release comes out. The 5.0
milestone is there to collect items that are goals/blockers for 5.0,
but if something's ready no sense in waiting until then to get it out.
I know you won't like the answer, but the releases consist of
whatever's ready to go when a release is cut. Personally, I think it's
great for both developers (your stuff gets in and released quickly)
and users (they get new features and bug fixes quickly, though if
they're happy with the version they have there's no need to upgrade).
- Robert
[1] http://trac.sagemath.org/sage_trac/milestone/sage-5.0
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
