I would like to back this up also, what I was referring to by a brach,was not a permanent one, but either creating a branch for the 4.0release or for multi-blog support, which would be merged back into thetrunk upon its stability, simply because multiblog support was alittle bit of a... bumpy migration for some. Since most of that hasbeen resolved, its more or less ok now, I would just make a point ofkeeping the web-migration interface working smoothly. I like to runtrunk in an attempt to make my hacks as pertinent as possible, and toprovide worthwhile and relevant feedback. Cheers,Kevin KubasikOn 3/19/06, Gary Shewan <[EMAIL PROTECTED]> wrote:>> 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 m! e> 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> problem?>> > 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.> _______________________________________________> Typo-list mailing list> Typo-list@rubyforge.org> http://rubyforge.org/mailman/listinfo/typo-list>
--Cheers,Kevin Kubasikhttp://blog.kubasik.net/ _______________________________________________ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
