On 26 Okt., 09:29, "Johan S. R. Nielsen" <j.s.r.niel...@mat.dtu.dk> wrote: > On Oct 22, 9:26 pm, Jason Bandlow <jband...@gmail.com> wrote: > > On 10/22/2010 12:20 PM, Robert Bradshaw wrote: > > > > Given the difficulty of finding reviewers, are you arguing we > > > shouldn't try to make things even easier? Yes, it's not to bad ([copy > > > the url, qimport, qpush] * n, build, test, run doctests, qpop, ...), > > > but could be a lot better. Oh, and by "test" I mean not doctests, but > > > interactively test, where it's more of a pain to context switch and > > > wait for the build to complete. I'd rather be reading the code and say > > > "hmm... I wonder if this works..." and just try it out. > > > This has annoyed me on more than one occasion. Can any trac gurus speak > > to the possibility of adding two fields to trac tickets? > > > 1) Patches to be applied for the current ticket > > 2) Tickets on which this patch depends
+N > > It seems to me that if we had machine-readable fields of this type, it > > would be possible (easy?) to write a shell script where one would write > > > $ test_ticket #1234 > > > and the script would > > > a) Download and apply the appropriate patches to a mercurial queue > > b) Build and run the patched version for interactive testing > > c) Clone the patched version, run all tests, email me the tail of the > > test log and delete the cloned version. (Works in a clone so I can > > review other tickets while this is going on.) > > > This little bit of automation would make me a much more productive > > reviewer, I think. But getting the collection of patch URLs is > > currently too hard to automate. > > > -Jason Are you aware of "./sage -merge ..." (which calls sage-apply-ticket)? This would certainly benefit from such fields as well. I think currently it's often even hard for a human (for tickets not having a "To the release manager / How to merge" section in the description) to find out which of the attachments to apply (if at all) to what repository in what order, and perhaps also fetch and install an spkg linked to in some comment. > +1. Nice and easy as a first step (and necessary for all the later > things). If that is not a rather doable thing in Trac, then I think we > have an answer to the earlier question in the "bug wrangler" thread on > whether Trac is the best solution for our needs ;-) > > Johan ;-) Also, trac should support concurrent posting... (Not to mention one rather unpredictably, i.e. occasionally, gets logged off in the "wrong" moment s.t. comments get lost unless one manually "saves" them prior to "submit" or even "preview".) ... and at least a little period of time to correct a submitted comment. -Leif -- 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
