[typo] Recent Multi-Blog update Breaks

Gary Shewan 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
> objects.

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 mailing list