I think that Burcin's suggestion is excellent. Development of Sage
should definitely move towards more structure, documentation, testing
and other software engineering practices, but as for any Open Source-
project, these things should come naturally as the project grows and
matures; as has already happened with Sage a lot, it seems (for a
relative new-comer like me). To require too much too soon would kill
the joy of working on the project and thus kill the project itself.
Burcin's suggestion seem to fit this curve pretty well at this time.
New developers and bugfixers -- with little overview of the monster
that is Sage -- would feel more confident in reporting and fixing bugs
if there was a feeling that there was someone (or a group of someones)
with overview and structure. If some enthusiastic veterans could be
found and agree on the exact model of this, I think it would improve
bug-tracking and -fixing in a number of ways:
- overview of bugs, their severity and class (by cleaning up,
removing duplicates, collating related tracs, and reclassifying)
- better classification of bugs by everyone else (by monkey-see-
monkey-do)
- better overview over bugs to fix before releases (by better
overview over all bugs)
- shorter pickup-time between a trac has been filed (possibly by
someone not interested in fixing it) and someone is looking at it
- assurance that a veteran has looked at the trac, accepted it, and
maybe even given an approving nod after positive review
- and all of this gives more confidence to developer-rookies
I think the system should entirely superseed the automatic-owner
system that is currently in Sage. Software-speaking, this would
provide an abstract interface between the tracs and those responsible
for it, which makes it more flexible to have either one, several or
many owners of a trac or class of tracs.
Personally, I like the one-week-at-a-time suggestion (though several
people should be on duty each week perhaps) sounds best. However, it's
easy for me to say, as I don't think I have the required experience to
undertake this duty ("You are not bug-ninja materiAL, SOLDIER! Drop
down and give me a recursive function generating the Fibonacci
sequence!"). When and if the time comes, I would be happiest with a
one-week-at-a-time schedule, though.
> Burcin wrote:
> Perhaps we should come up with a locking mechanism, to prevent two
> different people from trying to sort the same issue at the same time,
> but it feels like too much organization at the beginning.
Maybe there would not need to be a locking-mechanism to begin with,
but surely a mechanism so that a bug-wrangler could see that no other
bug-wrangler has already looked at this new trac.
Cheers,
Johan
On Oct 20, 11:37 am, Martin Albrecht <martinralbre...@googlemail.com>
wrote:
> > > The idea of having one piece of a Sage days devoted to
> > > people sharing ideas from books they read in a coordinated way sounds
> > > plausible as well, though probably it would really depend on the Sage
> > > days in question.
>
> > That would sound good. If each person read a chapter of a book on a topic,
> > and gave a short talk to everyone else, it should at least make people
> > aware of the other issues.
>
> > I bought this book
>
> >http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/013...
> > 2/ref=sr_1_1?ie=UTF8&qid=1287529714&sr=8-1
>
> > though I'm not over-impressed with it.
>
> > Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of
> > this book
>
> >http://www.amazon.com/Software-Engineering-Practitioners-Roger-Pressm...
> > 0073375977/ref=sr_1_4?ie=UTF8&qid=1287529714&sr=8-4
>
> > to be very useful.
>
> > You can pick up a used copy of the 6th edition (2004) for less than $2 on
> > Amazon.
>
> I'd like to return to Burcin's original proposal if possible. He made a
> *concrete* proposal for what to do with the growing number of bugs in Sage and
> somehow this turned into a threat discussing which books on Software
> Engineering we should read and how early one should should fix bugs.
>
> Don't get me wrong, this is a useful discussion to be had but it is a shame
> that discussions move from concrete to abstract instead of the other way
> around quite often these days ([sage-general] anyone? :))
>
> It seems clear to me even if we do employ all kinds of software engineering
> techniques that there will still be bugs we'll have to tackle and our current
> approach as serious issues. Even OpenBSD has bugs which they have to address
> despite the fact that they make quite an effort to scrutinize code.
>
> To get back to Burcin's proposal it seems while there is some support, it
> doesn't seem to spur enough interests to have enough people to distribute the
> load to or am I mistaken?
>
> Cheers,
> Martin
>
> --
> name: Martin Albrecht
> _pgp:http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
> _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF
> _www:http://martinralbrecht.wordpress.com/
> _jab: martinralbre...@jabber.ccc.de
--
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
