On Mar 6, 2:35 pm, "Georg S. Weber" <georgswe...@googlemail.com> wrote: > The downside is, that if two (or more) patches collide (which may not > easily (or shall not) be put in one and the same "series of patches", > for whatever reason), only one can win --- and all the others have to > be rebased on the "then next" official Sage version.
Well, in my opinion it is -- to some extent -- [also] up to the release manager to coordinate concurrent or conflicting changes (as he/ she is very likely to notice them, provided he/she attempts to merge the corresponding tickets, and performs tests -- note that some conflicts may show up only later, during builds or testing), during the preparation of a release, such that one (or a ticket) doesn't necessarily have to "wait for the next [official] release". Some conflicts are easy or even trivial to solve, others are not; but it's also an important task to (asap) make developers aware of potential conflicts, and tell them on which tickets/patches they'll have to or should [re]base their work. -leif > A downside that > is the more acceptable, the higher the Sage release frequency is --- > simply because then, the probability of such collisions decreases. I > had this "old scenario" in mind when I wrote my answer, but didn't say > so expicitly, sorry! > > Cheers, > Georg -- 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
