On Mon, Mar 8, 2010 at 10:05 AM, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Mar 7, 2010, at 9:21 AM, Florent Hivert wrote: > >> 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. > > Single ticket patches (the majority of them) are easy to handle. If there is > more than one ticket, it can try applying them all, and that failing, > applying only the last one, noting that it needs more information on > failure. As for specifying more complicated orders, we were talking about > this during the last Sage days and the best idea was that it would look for > the last bulleted list that consisted of patch file names. Thus the author > would write something like > > Apply the patches in this order: > > * integrate-fix.patch > * referee-comments.patch > * doctest-fix.patch > > And both the automated system and build bot could figure this out. >
And humans can easily read this too. This could just be the last comment on the ticket (of that form). William -- 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
