On Sat, 30 Jul 2011 02:31:33 leif wrote: > 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. > > Of course there is always a risk. Providing an alternate patch based on the current official release is a must. Also you should be able to assess the probability that the patch set in the unreleased will stay merged. If the change is trivial you should be safe.
You probably also should do a review of the dependency you depend on for yourself. None of that will prevent unmerging if a major concern arises. Francois This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- 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
