David Fraser wrote:
Jim Gallacher wrote:
-1 (On including in 3.3)

We need to have some release discipline. The beta cycle for 3.2 was something like 8 months long and I don't want to see that happen again. One of the reasons for that long cycle was the feeling that "it might be a long time before we do another release, so let's make this change now", which ultimately *caused* the delay.

There are a lot of really great things in 3.3 (new importer) and I think we should get it out as soon as possible. I'd also like to see a 3.4 release fairly soon (4-6 months?) after a though audit for python 2.5 64-bit support. If the new handler is accepted it may not have to wait too long. Also, if it's pure python it would be pretty painless for people to backport it if they want to use it in the mean time.

Maybe we should adopt some sort of calendar release policy. If we aim for a minor point release every 6 months then people will always know that they won't have to wait too long for the latest and greatest features to appear. This would alleviate the urge to stuff too much into any one release. I'm not suggesting that we be a slave to the calendar - just use it as a guideline.

Jim
I agree with the need for release discipline, however I think we need to have a compromise where either - the optimal minor point release cycle for mod_python is more frequent than 6-monthly (6 months is a fairly large delay for a simple feature like this), or

I'm all for a more frequent release cycle, just as I'm also in favour of peace in our time. I'm just not sure either is realistic. I don't think 6 months is necessarily optimal, but rather based on observation of what is possible. I suggested 6 months so that we at least have something predictable.

In this particular case we are just days away from a full beta, which I'm pretty confident will become 3.3.0 final. There is just a small delay in cleaning up a couple of points in the documentation and we are then ready to roll. Plopping new features in this close to the wire just slows the process down. Without addressing the specifics of this particular proposal (which I'm sure is on par with Graham's usual great work), it is entirely possible that it could delay the 3.3.0 release by another 2 to 4 weeks. By then some wonderful code I've been working on (well hypothetically at least ;) ) should be ready, so what the heck, let's include it as well... just need a few more days to give it some polish... tick tick tick... more fiddling... tick tick... and suddenly it's February '07 and a full year has passed since 3.2 went out.

- there is a mechanism to allow certain kinds of new features more frequently than a minor point release.

I don't think there is any magic in the minor point releases. It's the appropriate place for new features, as long as any API changes are backwards compatible. We just need to be able to say "OK, we've got enough good new stuff in the development branch, let's release it". Making *that* decision seems to more difficult than writing code. Heck, it's almost as tough as writing documentation.

In some ways it may make sense to have different rules for base code and handlers that function on top of it.

I see your logic, but at this point most changes in the base code are likely to be bug fixes from which everyone would benefit. Any major changes in the base code, by which I mean the stuff written in C, might be treated differently, but it's not likely that new features would be introduced there first anyway.

I've always felt that the publisher handler in mod_python is problematic - it causes lots of queries and isn't really the best way to do a lot of things, but because it is included in the base distro most people seem to try it out first. This dispatcher seems like a better fit to mod_python. But perhaps both of them should be broken out into a separate package - it could be called modpython-utils or something like that. That way that package could have a faster release cycle,

I'm not sure that would actually result in a faster release cycle, as we'd then have 2 branches to manage. The idea has merit, but for other reasons.

I hope my response doesn't sound like too much of an angry rant - it may be a rant, but not angry. Just assume there there is a smiley face stuck at the end of each sentence. :)

Jim


Reply via email to