On Jun 1, 2010, at 4:09 PM, Dr. David Kirkby wrote:
On 06/ 1/10 11:56 AM, Robert Bradshaw wrote:
On May 29, 2010, at 3:34 AM, Dr. David Kirkby wrote:
The real question though is why do you think Sage would be better off
with a roadmap? Would we have more users?
Probably not.
Happier users?
Yes.
Would it attract more developers?
It would probably put less off. The random nature of Sage at the
moment is not attractive to developers.
I don't know anyone who's been turned off due to the nature of Sage
development or lack of clear roadmap, but I could see it happening.
Are we suffering due to the lack of a roadmap?
I think we are. I believe that if there were specific dates for
feature freezes, it would be useful to know. I for example have a
lot of tickets I need reviewing, which has become increasing
difficult to get done since sage-solaris was created. Should I try
to badger someone to review them tomorrow, since the release will be
made Thursday, or I should not worry, since no releases will be made
soon?
Releases are always going to be made soon, so it's always worth trying
to get a review as soon as possible. (I've got a lot of tickets in
that situation as well, but I've been otherwise occupied lately). The
only urgent ones would be blockers (e.g. something that produces
incorrect results) or occasionally something that's really a pain to
rebase.
If Sage has a mission of being a viable alternative to the
commercial products, it should have some roadmap of how it is going
to do that. Student projects could be proposed to address specific
areas of weakness.
Yes, it's amazing what students can do.
As you know, there was a full-time employee working on the Solaris
port, yet that was many years late. Had there been specific
milestones to reach by certain dates, it would have been realised
that port was slipping badly. It's more difficult when there is no
plan.
Honestly, I don't know if such a plan or milestones would have made a
difference here.
I believe there is far too little time between a release candidate
and a final release - a fact that would be obvious to any
professional software developer if a roadmap was published.
I'd agree with you here.
Would a user download a verion today, if there was a new release
scheduled for tomorrow? He/she would probably wait a day or so.
Or, he would decide to do that, then never come back for a long time.
(It's happened to me.) With frequent releases this is less of an issue.
Or is it more of a PR need?
You may consider it "PR" but I would say it looks more professional
than random dates. I think appearing professional is a good thing if
you want to compete with professional software.
I didn't mean this in the derogatory sense at all--I agree it's
important to be professional.
I think our different views may be age related. It might not be a
coincidence that both Peter Jeremy and myself are quite a bit older
than most Sage developers. Perhaps we see things from a different
perspective.
And I sincerely do appreciate another perspective, thank you for
elaborating. It may also be the cathedral vs. the bazaar difference of
perspective. It could also be professional software developers vs.
volunteering mathematicians (and in particular, Sage is developed
primarily by its users, who put in the work to get the features they
need and want them in as soon as possible rather than being directed
by external customers).
In terms of a roadmap, I think it would be extremely valuable to have
a list of features that Sage is clearly lacking to be a viable
alternative to the closed source offerings, perhaps somewhere on the
wiki by topic. We need something higher level than tickets, but lower
level than the mission. This has been done haphazardly for some areas,
but doing this systematically (with a common place to accumulate the
results) would be very valuable. This has and will happen, to some
extent, as part of grant proposals and sage days planning. The
combinatorics group is a stellar example of this: http://trac.sagemath.org/sage_trac/wiki/SageCombinatRoadMap
. I'm not convinced that tying things to specific milestones/
timelines will be as realistic given the dynamic nature of the
developer base, but setting goals for specific Sage days, or "big"
releases like 5.0 makes a lot of sense.
- Robert
--
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