On Wed, Oct 20, 2010 at 5:10 AM, Johan S. R. Nielsen
<j.s.r.niel...@mat.dtu.dk> wrote:
> 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.
+1 I have definitely seen that the level of bureaucracy has going up,
especially in the last year or two, has turned off a lot of potential
and even former developers. The focus on software engineering and
testing can certainly be good for quality (though that's not an
immediate or certain implication), but the problem is that too much
emphasis on it has a significant chilling effect on contributions. The
lag time between hacking out some code and getting it in is way too
high these days discourages contribution and sucks up a lot of
development time and energy with endless rebases and waiting. And
though we all want to produce bug-free code, holding that up as the
primary objetive (as opposed to producing useful code) I think
dissuades people from submitting or refereeing code.
I'm not sure I have a solution, but one thing that keeps coming to
mind is that Sage is trying to span several audiences with different
goals and criteria, and perhaps the various audiences would be best
met by a stable vs. unstable model like Debian. Purple sage is an
extreem move in this direction (more like Debian experimental)--I can
certainly see the attraction and value, but I just hope it doesn't
become an incompatible fork.
> 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.
I agree that a big part of the problem is that it's hard to get a big
picture of all the bugs being worked on. The idea of a weekly
"bug-wrangler" is an interesting one. I have a simpler proposal (which
may be insufficient, but would complement a bug-wrangler's role and is
much easier to implement).
First, have the initial status of tickets be some pre-new stage.
(Something like "unclassified".) This woud make it so you don't have
to be an expert to classify a bug. Volunteers could go and look at all
unclassified tickets and file them appropriately (severity, defect vs.
enhancement, component, duplicate, etc.) Of course, there could be a
rotating bug-wrangler, but if it was easy enough for a "veteran" to
hop on and categorize a bunch of them in one sitting this might not
even be necessary.
Second, rather than have the default milestone be the next release,
have some default future milestone. Only tickets that are actively
being worked on get put on the current release. This would make it
much easier to see what's being worked on (or at least cared about)
and what to expect in the next release. Sufficiently important items
(blockers) would also get added here.
Thirdly, I think the list of components could be cleaned up.
All of these would help us get a better picture of the overall state
of Sage. Finally, we need more automation. Refereeing code shouldn't
have to involve downloading and applying patches and running all
tests--that should all be done automatically (with failing tickets
bounced right away, or at least in a 24-48 hour window). We should
have a notebook server with sessions of Sage with various tickets
already applied for quick refereeing (or a CLI interface on, say,
boxen for those who prefer that--"telnet/ssh
10921.sage.math.washington.edu" would be cool, opening you immediately
into a jailed sage session). I'll plug
http://trac.sagemath.org/sage_trac/ticket/9967 which is a requirement
for this and I just recently started to write a per-ticket build bot.
This would help close the gap and lag between writing code and getting
it into Sage, and I think that having such a small gap was one of the
key ingredients in letting Sage explode like it did.
- 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
