On Apr 5, 2011, at 7:01 PM, Ronan Lamy wrote: > Le mardi 05 avril 2011 à 15:32 -0700, Ondrej Certik a écrit : >> On Tue, Apr 5, 2011 at 2:36 PM, Aaron Meurer <asmeu...@gmail.com> wrote: >>> On Tue, Apr 5, 2011 at 11:07 AM, Brian Granger <elliso...@gmail.com> wrote: >>>> I am +1 on this plan. >>>> >>>> Brian >>>> >>>> On Tue, Apr 5, 2011 at 9:59 AM, Ondrej Certik <ond...@certik.cz> wrote: >>>>> Hi, >>>>> >>>>> I have talked with Mateusz over a dinner last Sunday, and Aaron over >>>>> the phone, and also Ronan over the phone just now, and we discussed >>>>> what has to be done to merge this branch, and I think we are all on >>>>> the same page, and want to get this merged as soon as possible. Now >>>>> the only question is to setup a plan and do it. >>>>> >>>>> >>>>> So I wanted to share the results from our call with Ronan today, and >>>>> ask everyone for feedback: >>>>> >>>>> 1) We should release before the merge, because it's a huge branch, and >>>>> we shouldn't be pressured by the release to fix things in master, we >>>>> should simply release what we have, which is well tested, and then >>>>> merge the polys >>> >>> Is Mateusz +1 on this? polys12 fixes a lot of bugs in master that >>> were introduced with the original merge of the new polys. For >>> example, all of these >>> (http://code.google.com/p/sympy/issues/list?can=2&q=label%3ANeedsReview+owner%3Amattpap%40gmail.com+&colspec=ID+Type+Status+Priority+Milestone+Owner+Summary+Stars&cells=tiles). >>> I would argue that polys12 *has* been tested because every time >>> something polys related fails in master we check it in polys12 (and >>> usually it works there). Also, I have been working off of Mateusz's >>> work all summer, so at least the older commits have been well used by >>> me. >>> >>> Also, aren't there some backwards compatibility breaks in polys12 that >>> aren't in master? If that's the case, we should consider merging >>> before the 0.7.0 release. >>> > Well, we will have to break backwards compatibility again when we > finally sort out assumptions or fix functions. I don't think we can > guarantee perfect backwards compatibility for 0.7.1 either way. > >>> I'd say we have about as many things to do for the release from master >>> as we do for polys12 (see the milestone0.7.0 and priority-critical >>> issues), so it might be worth it to try to get polys12 in before the >>> release (also, I really don't want to postpone it any further; I think >>> Mateusz will agree). >> >> This is ok with me too. Ronan, would you be ok with this idea? > > Yes, as long as we do a proper review and fix everything before the > merge. On the other hand, if we didn't commit ourselves to releasing > with all of polys12, we could create a release branch real soon and > merge polys12 immediately after. That way, we'd be able to release > faster and, probably, to assimilate the changes from polys12 faster. >
Well, let's work on both. I suspect we will have polys12 ready to go in (in the form of p12) sooner than we will be ready to release. Also, unless anyone (you?) is volunteering, it is me who is going to be doing the release, which means that it will happen as I have time to get things done for it. Aaron Meurer -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
