Hi there, > > Note that I've no idea how hard it is to implement in trac, neither if we > > have the necessary hardware to support this load. > > >From reading the Sage merge script, I think one could use that script > or write something along similar lines to implement a (simple) > proof-of-concept continuous buildbot. That is, without adding any new > fields to trac. I just want to point out that the current number of > fields on a trac ticket can overwhelm a beginner, indeed anyone. More > fields added would mean more time spent thinking about what > information to add to which field. In many cases, one could easily > write a lot of information clearly and concisely as a ticket comment. > If the information is critical for reviewing a ticket, such > information could be written in the ticket description. If you have > been following how David Kirkby writes his descriptions for Solaris > and portability tickets, you would see what I mean.
I surely agree with all of that. However, I'm not sure it would be easy to write a sufficiently clever buildbot that is able to automatically find the necessary information from the ticket description. Hence my suggestion to add more field. Another maybe simpler solution is to be able to launch the buildbot by hands say from a trac webpage, after giving him the lists of patches. This should not be a time consuming task for the author/reviewer. As Robert very nicely pointed out, the ultimate goal is that "[...], the review focus away from making sure the patch "applies and passes tests to actually refereeing the code, documentation, "and examples themselves." Cheers, Florent -- 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
