Trackbacks

I’m seriously considering a series of patches that will turn off
trackback sending and other notifications entirely (probably to the
extent of removing the code for a while) while I sort out the
semantics of publication. By stripping out the ‘extras’, I hope to be
able to see what’s needed a little more clearly, once there’s a
publishing pipeline in place it shouldn’t be hard to reinstate
notfications.

The question is, to branch, or not to branch? I’m generally gung ho
about not branching, I’d far rather get feedback on changes/bugs from
as wide a constituency as possible, but I’m also aware that I’m
proposing to strip away quite a bit of functionality while I work on
something that won’t immediately have fabulous benefits for people who
aren’t working on the code.

My hope is that, by doing this, we’ll end up with a clearer, cleaner
codebase that should be easier to extend in interesting ways, complete
with a rather more comprehensive test suite than we have now.

Thoughts?

On May 6, 2006, at 11:13 , Piers C. wrote:

I’m seriously considering a series of patches that will turn off
trackback sending and other notifications entirely (probably to the
extent of removing the code for a while) while I sort out the
semantics of publication. By stripping out the ‘extras’, I hope to be
able to see what’s needed a little more clearly, once there’s a
publishing pipeline in place it shouldn’t be hard to reinstate
notfications.

The question is, to branch, or not to branch?

How about a stable release before starting a bunch of major
disruptive work?

mathew

mathew [email protected] writes:

How about a stable release before starting a bunch of major
disruptive work?

Bah! Stability is overrated. But you might have a point here.

+1 for stable release.