David Fraser wrote:
Jim Gallacher wrote:
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
-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.
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
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
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. :)