Gary Shewan <[EMAIL PROTECTED]> writes:
> 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
> 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.
One migration broke because the Postgres database adaptor doesn't work
well when you add a table that only has an id column. Not something I
could really anticipate when I wrote the patch. Thankfully the
migrations fail to safety with no information lost and as soon as
someone who'd tried the migration while running postgres popped up
with details of what was going wrong it was fixed very quickly.
The broken aggregation sidebars were breaking because of something
else entirely, which took a little longer to track down. Again, once
we had the bug reports in, it wasn't hard to fix.
Why did they get fixed so quickly? Because the changes went on the
trunk and our intrepid bleading edge users tripped over the bugs and
reported them so we could fix them.
Typo sidebars are currently almost entirely untested and bordering on
the (un|de)testable. Which tends to mean we make changes, push them
onto the trunk and hope there aren't any bug reports. We're not happy
about this situation, and rest assured we're working on it.
> 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?
It's free software, it *has* to be fun for developers to work on or it
simply won't get developed.
> 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.
There are 8 open tickets on the 4.0 milestone, one of which is
multiblog support; it's been there for ages. The others are:
#237 Sidebar issues in IE6
Can't work on that one; no Wintel boxes in the house
#299 markup-help.diff
Hmm... hang on, why haven't I applied this one yet?
Ah... because it doesn't quite work. Nice idea though.
#315 Google sitemaps
No tests with the patch. With an even half decent test suite,
this would go straight in. Without tests I'm worried I'll break
it and not realise.
#343 Beef up typo spam protection
More of an ongoing issue than anything else. We've been talking
on IRC about at least instituting a comment/trackback queue for
approving or nuking comments and trackbacks rather more quickly
than having to find the right article. Am I right in thinking
that you've been doing some work in this area? A patch would be
welcome; ideally with tests, but for something like this I'd be
far more inclined to look favourably on it and write any
necessary tests if someone came up with a good framework
#392 Resources that are attached to an an article don't show up on the
edit article page
I've not attacked this one because I'm not at all sure of a good
way to proceed. I think that we need to think rather carefully
about the the interface for adding articles and their resources
on the content page -- what we have isn't desperately good right
now. We could really use some good user stories from people who
want to use typo for podcasty type things.
There is a podcasting patch, which looks at first glance, to be
pretty good, but it has no tests and it adds an awful lot of
feature, so it's currently in limbo.
#421 Fix RSS converter to use a better parser
Kevin Ballard's been working on this; from the look of the
patches he's been adding and IRC conversations, we're damned
close to being able to close this one. Again, the issue of
tests arises, but we've got problems along those lines with all
our converters.
#304 Remote server communication (at sidebar admin) is not very
transparent
I'm actually working on this one (or on something that will
hopefully close it as a side effect) at the moment. I'm not sure
I'll finally have it knocked on the head with this iteration, if
only because my javascript skills are... well, 'skills' is
probably the wrong word. Rails 1.1 will make this sort of thing
*way* easier.
Oops, 9 open tickets, I just added:
#725 Typo installation is about as friendly as a cornered rat
Scott's working on this one.
Actually, once Scott's got #725 nailed (and he's bullish about it) we
should be able to start releasing some 'pre4.0' distributions. The
current sketchy plan is that these will get pushed out weekly or
monthly until at least 4.0
There will always be the bleading edge, and we'll always be grateful
for the people who stay on it and report back when they get cut by
it.
We're trying to make it less likely that they'll get badly cut (for
instance, migrations 38 and 39 were the two most robust migrations
I've ever written. Although there was a problem with Postgres, the
transactions got unwound properly and nobody (except me when I was
writing them) had to recover anything by hand -- not something we've
been able to say for every migration in the past), but we can't
guarantee it. I can, however, assure that nothing goes into the trunk
if we think it doesn't work.
Hopefully the forthcoming pre4.0 series will let people get a good
deal nearer to the edge without hurting themselves.
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
_______________________________________________
Typo-list mailing list
Typo-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/typo-list
