On 29 Jul., 23:37, Francois Bissey <francois.bis...@canterbury.ac.nz> wrote: > On Fri, 29 Jul 2011 13:44:01 kcrisman wrote: > > So it would be helpful to have some clarification, if only to avoid > > rebasing. > > What I did last time I had a problem like that was to make my ticket dependent > of the ticket already in the unofficial release. That way there is an explicit > dependency chain.
Of course, but not really a solution. What happens if the patch(es) / ticket(s) you based your changes on get unmerged again for some reason? The same as if you hadn't based your ticket on the "candidate(s)" but these stay in. And people wanting to try / review your ticket (patchbot included) also need to apply the whole, perhaps "artificially grown" dependency chain. Things get worse with spkgs that require rebuilding others or applying some patches in addition. There's no stays-merged probability field for the tickets on the list... ;-) (And trying to judge that from the "candidate" tickets is more work, if at all possible, since further tickets you probably didn't think of because they weren't listed might break them at any time.) I actually ran into the situation having to rebase a patch of an already (quite long) positively reviewed ticket on a new patch merged into devel release N+2 (N: current official devel version). I provided an alternate patch for that version, and in fact the ticket I rebased the patch to still remained in version N+2 when it was officially announced quite a while later, but my ticket now again needs review, thereby delaying another positively reviewed one which depends on the former. [Maybe it would have gotten re-reviewed if I attached the rebased patch earlier, but who wants to test against an unofficial release with in general arbitrary dependencies?] IMHO the more or less volatile (nobody knows) unofficial releases cause more confusion, at least if one follows Francois' suggestion and "ignores" what the README.FIRSTs state: "[...] There is no point in testing it. [...]" "That being said, it can still be useful to use a non-released Sage version for rebasing a patch, but don't complain if the version changed and broke your patch. [...]" (The older ones didn't say that IIRC.) A few people will base their patches on the current devel, others on some uncertain, sometimes frequently changing future release. Things would be a little easier if trac supported different branches, though it wouldn't be clear whether some dependencies are of functional or just "syntactical" nature. -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
