Ask Your Question

On what versions should Trac patches be based?

asked 2011-05-28 02:22:58 +0200

Kelvin Li gravatar image

updated 2011-05-28 04:47:28 +0200

I see that alphas and release candidates come out a lot faster than "released" versions of Sage. Should development patches be based on these pre-releases or on the current release? Furthermore, if I spot a patch on Trac that is based on an older version of Sage, should I go ahead and re-base the patch?

Notably, I have not found a clear answer in the Developer's Guide.

UPDATE: When producing the next stable, are the patches which are based on pre-releases "back-rebased" to the current stable? If so, is this a reason at all to favor basing on the current stable, rather than on the latest pre-release?

edit retag flag offensive close merge delete

3 Answers

Sort by ยป oldest newest most voted

answered 2011-06-01 13:17:07 +0200

kcrisman gravatar image

I would actually disagree (respectfully) with Niles, in a subtle way.

  1. First, develop on whatever version of Sage you have. Don't waste time downloading or building if you have an idea!

  2. But once you are at the point to think about committing it, then it is worth going to the sage-release Google group and finding the latest alpha or release candidate and making sure that your patch at least applies to that. It is not correct to say that each patch builds on the released version; each alpha is based on the released version, but there are still patches that need to be rebased on other patches. There is certainly no 'back-basing' as in the update to the question.

    This is annoying, I agree, but is worth doing. Many (most?) patches won't conflict, but it's worth knowing ahead of time; at least for me, rebasing is a long and tedious business.

  3. Once one gets developing a fair amount, one will know where to look for "usual suspect" tickets or authors. Doing occasional searches in (say) symbolics will give you a sense of whether any symbolics patches are about to be merged, so that if you are going to do something in symbolics, you can be ready to base off of patch X with your patch Y.

edit flag offensive delete link more


+1 to making Jeroen's (the release manager) life easier. Test your patches against the latest alpha.

Volker Braun gravatar imageVolker Braun ( 2011-06-01 14:11:36 +0200 )edit

Notwithstanding that for the kdiff-ly challenged (like me) this is really annoying. Hopefully at Sage Days 31 I'll finally figure out how to rebase easily.

kcrisman gravatar imagekcrisman ( 2011-06-01 16:36:48 +0200 )edit

I think we're totally agreed on your point 1! Point 2 is fair; should patch *reviewers* also be encouraged to test the patch on the latest (pre-)release?

niles gravatar imageniles ( 2011-06-01 17:00:44 +0200 )edit

Well, I think that nowadays that might be the case. However, it would be worth pointing out that someone could definitely test everything except whether it applies to the latest alpha, and then try to recruit someone else to test just that. If the patchbot/alpha system made any sense, this would be easier, but currently with the "from scratch" alphas that makes things hard.

kcrisman gravatar imagekcrisman ( 2011-06-01 23:45:24 +0200 )edit

Anyway, the point is that people should not be *discouraged* from reviewing, but rather say "positive review except it's too hard for me (given internet or machine or whatever) to test whether it applies to the latest alpha".

kcrisman gravatar imagekcrisman ( 2011-06-01 23:46:08 +0200 )edit

answered 2011-05-28 03:32:03 +0200

niles gravatar image

updated 2011-06-01 17:20:25 +0200

I think the goal is to have patches based on the latest version possible, but not to make this a barrier to people working on patches. Here are some more expanded comments, based on my limited experience:

Personally, I would develop patches based on stable releases of Sage. Sometimes alphas or release candidates have some test failures that are known to the release manager and will have to be resolved before the final release; these could be potentially confusing as a developer if your patch is working on a related component, since it may be difficult to tell which failures are caused by known issues, and which are caused by bugs in your patch. But there may be good reasons in some circumstances to base your patch on a pre-release version (e.g. it fixes something relevant to your patch). In the end, I think this is up to the developer.

As for developing with older stable releases, patches have to apply to the latest stable release in order to be finally included in a new release. Sometimes patches simply apply without problems to later releases, and then nothing has to be done. But if they don't, these problems definitely have to be fixed. I think most patch authors would be happy to have you rebase their patches -- I certainly would!

However, for the purposes of actually solving the programming or mathematical problems relevant to the patch, one doesn't have to necessarily work with the latest release of Sage. Since rebasing is usually a straightforward task, the real value in a developer's work is in writing the initial patch. Get something that works correctly in some version of Sage, and then make sure it works with the latest stable release. Of course the greater the gap between the version you develop with and the latest version, the more difficult the rebasing will be, but working two or three point releases behind the latest probably isn't a big deal.

Update: As @kcrisman points out, having a patch apply successfully to the latest stable release is necessary---but not sufficient---for the patch to be included in Sage. The patch must also apply to the latest pre-release, and not conflict with other patches to be merged in the next (pre-)release. He is right (of course!) to point out that testing against the latest pre-release is the best way to be sure your patch is ready to be merged.

However, motivation to test on the latest pre-release should be tempered by the understanding that the review process will probably take longer than expected (several pre-releases, and maybe several stable releases), and (as far as I know) binaries for pre-release versions are only available for the machines at the University of Washington. A person without access to these would have to build each pre-release from source just to test the patch. This can be tedious and time consuming, depending on one's resources, so I wouldn't necessarily recommend it for everyone.

edit flag offensive delete link more

answered 2011-06-01 16:33:52 +0200

Kelvin Li gravatar image

updated 2011-06-01 17:27:40 +0200

niles gravatar image

Thank you everyone for your answers! I wish I could favorite all of them. :-) Since I am just starting out and don't have any mega-refactoring ideas (yet), I don't feel that basing off of the latest pre-release is a bother at all. If spending a little more of my time saves 10 other peoples' time, I think it is a good trade off. :-)

Maybe I will open a ticket to fix the Developer's Guide!

UPDATE: This is now #11420

edit flag offensive delete link more


Yeah, why not?

kcrisman gravatar imagekcrisman ( 2011-06-01 16:37:22 +0200 )edit

I think updating the developer's guide would be a great idea!

niles gravatar imageniles ( 2011-06-01 16:56:19 +0200 )edit

hmm. I thought AskSage used to automatically link Trac tickets...

Kelvin Li gravatar imageKelvin Li ( 2011-06-01 17:37:48 +0200 )edit

you're right, but I forgot the syntax . . . I finally looked it up again, and noted it at

niles gravatar imageniles ( 2011-06-01 17:49:44 +0200 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2011-05-28 02:22:58 +0200

Seen: 616 times

Last updated: Jun 01 '11