[typo] Recent Multi-Blog update Breaks
gpsnospam at gmail.com
Sun Mar 19 09:23:00 EST 2006
On 18 Mar 2006, at 20:36, Kevin Ballard wrote:
> You've taken what I said and interpreted it completely opposite to
> the meaning. I didn't say adding multiblog support would kill the
> project. I said trying to maintain two branches in parallel
> development, one as single-blog and one as multi-blog, would either
> kill a branch or kill the entire project (parallel development
> meaning any features/bugfixes written for one branch would, if
> applicable, have to be re-written for the other branch as well).
> The other option would be for someone else to start maintaining one
> of the branches and for it to basically become a fork. But that's
> certainly not desirable either.
> And see Piers's post for why Gary's original assertion is wrong.
Jayzuz line me up against the wall and shoot me for opinions why not ;)
That's exactly what I meant about two branches. It probably was me
who wasn't making it clear. There's no way I'm buying that running
two branches would kill a project. I still think that's complete
nonsense. I still say you're scare-mongering. Nobody mentioned
forking. The concerns being raised was why is such a significant
change being jammed into trunk when there are bugs that could be
hammered first for the release of Typo 4? Trunk seemed to be broken
because of multi-blog support which is pretty annoying for those of
us who don't intend using multi-blog support ... can't you see that
> Have you even read the patch?
> The reason that the current changes have gone into the trunk is
> because they're paving the way to *removing* bloat. In fact, they have
> already done so by eliminating the settings table and a bunch of
> structural code to manage it. You could think of r914 as a refactoring
> of the config object if you prefer.
> I have no desire to run multiple typo blogs on my site, but a blog
> object makes a lot of things that I do want to do a good deal easier
> to manage. I have every intention of making it so that the single blog
> case is at least as efficient as the (so far hypothetical) multiblog
> case, but I also need somewhere to stash a bunch of structural
> currently implemented in controllers that really doesn't belong
> there. That place is the blog object.
> I've not benchmarked it, but I'm willing to be that the new blog
> object is at least as efficient as the old Configuration and Setting
Admirable Piers. But this is still a significant change
(seemingly). Any particular reason that this was looked at now with
all the bugs outstanding, when there was supposed to be a push to
stable release 4? Could it not have been handled in a branch or do
you think it can be implemented pretty quickly? Can you see why
users get irked when trunk breaks because of what is perceived to be
multi-blog support when we aren't going to use it? Why should I test
that in trunk? See my point? Stamp on the bugs and get a release 4
out and I bet there wouldn't have been a peep.
Listen lads, I'm not knocking your work at all. I'm just trying to
put the argument forward from the users perspective. Devils advocate
if you like, so don't send hate my way ;) Surely you've had this
conversation a million times before in your real life development
work? Is Typo a developers plaything or something people can really
use? Because if it's for us to use those bugs need to go and we need
a stable release. Not as cool as new or reordered code ... but needed.
More information about the Typo-list