Robert Bradshaw wrote: > On Aug 19, 2008, at 2:45 AM, Dag Sverre Seljebotn wrote: > >> There's been some talk already but now seems the time to make votes >> etc. >> >> I propose that bugfixes that a) are relatively simple, and b) >> doesn't rely >> on or interfere features implemented since the last release, are coded >> against and pushed to "cython" and then merged into "cython-devel". >> >> "cython" should still be considered relatively stable, so every commit >> there is like a micro-patch-release of Cython. > > +1 > >> This should take some pressure off cython-devel (although keeping >> it as >> stable as possible is still good). Cython 0.9.8.2 may then come >> entirely >> from "cython" if it is primarily a bugfix release, or from "cython- >> devel" >> if it stabilizes. >> >> One should think about some of the things that may be done to >> cython-devel >> soon, especially import Greg's result_code-calculation-in- >> generation-phase >> changes, and the other refactorings related to/made possible by that. >> These are mildly dangerous (at least they lead to changes >> "everywhere") >> but also needs to be in the main stream of development. >> >> An alternative would perhaps be renaming "dagss" to >> "experimental" (but >> IMO all new features as well as new framework changes so go into it >> then). >> >> Thoughts? > > One thing to consider is that a single repository can have multiple > branches.
Yes, but they seem to be more hidden, i.e. the web interface for instance won't make the fact that there are multiple branches obvious to a visitor? So they seem to be more useful for private use but since one would have to know about them they seem less useful for sharing stuff. If you know of a good way to use them please share... (svn branches are actually more useful here as they are obviously present as directories in the folder structure) > I propose that cython-devel be relatively stable, i.e. the entire > test suite should pass before pushing there (I've been trying to do > that, but we should formalize this requirement) but can still do some > bolder things. I'm happy to set up a repository for anyone to wants Fine. Though I think it should actually be possible to push failing testcases without a fix if a bug is discovered? If one doesn't have time for a fix it is better to push a testcase than not? (and stick a ticket in trac) > On a related note, I had a lot of people ask me "so, what's new in > Cython lately." It would like to start using http://trac.cython.org/ > cython_trac more to keep track of everything of significance that > goes in. Yes I had almost completely forgot about trac -- I'll start using it to track anything non-trivial I do (i.e. create tickets and assign to myself). Will I be warned if a ticket (i.e. typically towards buffers) is assigned to me? -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
