Robert Bradshaw wrote:
On Mar 7, 2010, at 5:07 AM, Dr. David Kirkby wrote:
Robert Bradshaw wrote:
On Mar 6, 2010, at 4:50 PM, Dr. David Kirkby wrote:
I thought there was going to be a 4.4 stabilisation release, but if
I create a new trac ticket, I'm given the milestone options are
4.3.4 and 4.5 - there is no 4.4 choice.
IMHO, it would be good if the stabilisation release did go ahead,
and *only* bug-fixes were permitted. i.e. no new code to add
functionality - just to fix pre-existing bugs.
Whenever you add code, you risk introducing bugs. For the most
stable possible release, it makes sence to hold off any enhancements
until 4.5
IIRC, after viewing the nature of most annoying bugs in that thread,
it was decided they were not fit for a stabilization release.
- Robert
I was not aware of that. I think it is a real shame.
In my personal opinion, a decent stabilisation release could be
achieved by everyone submitting just bug fixes.
Yep. The problem is that this involves telling everyone what to do.
Not really. You tell people what a release will consist of. It is to them
whether or not they want to submit bugs or enhancements for review. They will
just be aware that the enhancements will have to wait for a release.
There should be very little for them to rebase their enhancements either, as the
changes made to Sage will not be as large as normal.
William said the other week that Sage had got more buggy recently.
Therefore it would seen sensible to me to have this release, even if
the list of bugs submitted does not fall onto anyone's "most annoying"
list.
If each developer could clear up just two bugs, without introducing
any more (i.e. there were no new features), then Sage would probably
have a couple of hundred less bugs than it has now.
Having a rule that
* Now updates to standard packages (since these often introduce as
many problems as they solve)
* Only bug fixes - no enhancements.
then IMHO, we could stabilise Sage somewhat.
Those 200 bugs fixes might not be on the 'most annoying' list of most
people, but it would be useful to squash 200 bugs. I think we could
all find 2 bugs we could fix, without introducing any updates to
standard packages.
We actually have the occasional bug day where everyone gets together on
IRC with just this goal (though I'm with you that upgrading spkgs is
dangerous).
Clearly the spkg updates should fix bugs, but all too often they have extra
requirements, or the interface changes in some way.
If you want a stabilization release, volunteer to be a release manager
(perhaps partnering with someone else) and only merge "safe" bug fixes.
I don't thing anyone would complain, as long as the release cycle wasn't
too long so that people knew their code their new code could still get
in in a timely manner. If you don't have time for this, I totally
understand, as I don't either.
I don't have time now, but it is something I'll consider at some point in the
future.
Dave
--
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
