Forum: Typo Recent Multi-Blog update Breaks

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
7c9669bd19c08f8adc0b7cc92881b04c?d=identicon&s=25 Kevin Kubasik (Guest)
on 2006-03-17 14:47
(Received via mailing list)
Just a note, I found that when attempting to update to the latestTrunk,
rev 915 breaks (it can't seem to add the new blogs tablecorrectly) 914
is good though. It seems to me that a multiblog branchshould be handled
that way, in its own branch, not in the trunk(although the comment seems
to imply that it is being done in abranch, maybe im just SVN illiterate)
--Cheers,Kevin Kubasikhttp://blog.kubasik.net/
Fe351aa18bdb90281044828701d67d08?d=identicon&s=25 cedric (Guest)
on 2006-03-17 15:34
(Received via mailing list)
Yes, I made the same experience, I think that's a mistake... comments
are
suggesting a new branch, but changeset #915 appears in trunk. I believe
that it will be corrected soon...

Kob. http://kobayazen.ath.cx
0196ff65610046d2f8ba58bc4a45f144?d=identicon&s=25 Piers Cawley (Guest)
on 2006-03-17 17:21
(Received via mailing list)
"Kevin Kubasik" <kevin@kubasik.net> writes:

> Just a note, I found that when attempting to update to the
> latestTrunk, rev 915 breaks (it can't seem to add the new blogs
> tablecorrectly) 914 is good though. It seems to me that a multiblog
> branchshould be handled that way, in its own branch, not in the
> trunk(although the comment seems to imply that it is being done in
> abranch, maybe im just SVN illiterate)

It's staying in the trunk -- the comment about the branch was from my
local SVK based repository which I'd not edited out.

What errors were you getting when you tried to run the migrations?
Could you send me a the relevant log section?
D6f24842b973de6cb75203c4c57dfbcb?d=identicon&s=25 Gary Shewan (Guest)
on 2006-03-17 18:02
(Received via mailing list)
On 17 Mar 2006, at 16:19, Piers Cawley wrote:

> local SVK based repository which I'd not edited out.
> http://rubyforge.org/mailman/listinfo/typo-list
Sigh, well that's me not upgrading in trunk.  Multi blog support is
bloat for those of us running Typo on single sites.  I think it's a
bad move to keep this in trunk.  If you want me to throw a penny in
I'd say split it now.  The initial attraction of Typo because it was
lean.  Why keep multi blog in trunk when not everyone wants it?  It's
screaming out for a separate branch.

God I hate bloat.
7c9669bd19c08f8adc0b7cc92881b04c?d=identicon&s=25 Kevin Kubasik (Guest)
on 2006-03-17 19:22
(Received via mailing list)
When I get back home, I'll get you a copy of the log, I'm not surewhere
the migration failed, but I just kept getting errors abouttypo.blogs
table not existing.
I have to say, I'm with Gary on this one, multiblogs would be a
nicebranch, but typo's lean 1 blog setup was part of its
attractiveness.The svn comment notes this, in order for multi-blog
support to be done'right' it must be done slowly first. I feel that
keeping this in itsown branch until its ready for prime time would be
nice, but that'sjust my $0.02
Cheers,Kevin Kubasik
On 3/17/06, Gary Shewan <gpsnospam@gmail.com> wrote:>> On 17 Mar 2006,
at 16:19, Piers Cawley wrote:>> > "Kevin Kubasik" <kevin@kubasik.net>
writes:> >> >> Just a note, I found that when attempting to update to
the> >> latestTrunk, rev 915 breaks (it can't seem to add the new blogs>
>> tablecorrectly) 914 is good though. It seems to me that a multiblog>
>> branchshould be handled that way, in its own branch, not in the> >>
trunk(although the comment seems to imply that it is being done in> >>
abranch, maybe im just SVN illiterate)> >> > It's staying in the trunk
-- the comment about the branch was from my> > local SVK based
repository which I'd not edited out.> >> > What errors were you getting
when you tried to run the migrations?> > Could you send me a the
relevant log section?> >> > --> > Piers Cawley <pdcawley@bofh.org.uk>> >
http://www.bofh.org.uk/> >
_______________________________________________> > Typo-list mailing
list> > Typo-list@rubyforge.org> > http://rubyforge!
.org/mailman/listinfo/typo-list>> Sigh, well that's me not upgrading in
trunk.  Multi blog support is> bloat for those of us running Typo on
single sites.  I think it's a> bad move to keep this in trunk.  If you
want me to throw a penny in> I'd say split it now.  The initial
attraction of Typo because it was> lean.  Why keep multi blog in trunk
when not everyone wants it?  It's> screaming out for a separate
branch.>> God I hate bloat.>
_______________________________________________> Typo-list mailing list>
Typo-list@rubyforge.org>
http://rubyforge.org/mailman/listinfo/typo-list>

--Cheers,Kevin Kubasikhttp://blog.kubasik.net/
Fe351aa18bdb90281044828701d67d08?d=identicon&s=25 cedric (Guest)
on 2006-03-17 19:22
(Received via mailing list)
On my point of view, single blog is just a particular case of a
multi-blog
implementation. This should becomes the default typo blog with a default
setting to "single blog" for all people who want to install their
personal
typo. But I don't know if it's possible... if not there must be 2
different
typo branches.
It's just my humble opinion, to bring some ideas to community.

Le Vendredi 17 Mars 2006 18:00, Gary Shewan a écrit :
7c9669bd19c08f8adc0b7cc92881b04c?d=identicon&s=25 Kevin Kubasik (Guest)
on 2006-03-17 23:06
(Received via mailing list)
Following up on my earlier promise, this seems to be the issue withthe
update script, I'm goin to fiddle a bit now and see if I can't getthis
to go away, but wanted to get the exact log out there for anyonewho
wanted to help.
Processing GeneralController#index (for 69.140.109.194 at
2006-03-1717:01:44) [GET]  Parameters: {"action"=>"index",
"controller"=>"admin/general"}Redirected to
http://blog.kubasik.net/admin/general/update_datab... in
0.00812 (123 reqs/sec) | DB: 0.00051 (6%) | 302
Found[http://blog.kubasik.net/admin]

Processing GeneralController#update_database (for 69.140.109.194
at2006-03-17 17:01:44) [GET]  Parameters: {"action"=>"update_database",
"controller"=>"admin/general"}Rendering  within
layouts/administrationRendering admin/general/update_database

ActionView::TemplateError (undefined local variable or method`this_blog'
for #<#<Class:0xb7aa7538>:0xb78cd39c>) on line #24
ofapp/views/layouts/administration.rhtml:21:             <%= link_to
'your blog &raquo;', :controller => "/" %>22:23:           </div>24:
<h1><%= link_to "Typo admin - #{this_blog.blog_name}",:controller =>
"/admin/" %></h1>25:           </div>26:         <!-- /HEADER -->27:
    #{RAILS_ROOT}/app/views/./layouts/administration.rhtml:24
/usr/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_view/base.rb:268:in`compile_and_render_template'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_view/base.rb:244:in`render_template'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_view/base.rb:205:in`render_file'
#{RAILS_ROOT}/app/helpers/application_helper.rb:26:in `render_file'
#{RAILS_ROOT}/app/helpers/application_helper.rb:19:in `render_file'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/layout.rb:226:in`render_without_benchmark'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/benchmarking.rb:53:in`render'
/usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/benchmarking.rb:53:in`render'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/base.rb:854:in`perform_action_without_filters'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/filters.rb:332:in`perform_action_without_benchmark'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/benchmarking.rb:69:in`perform_action_without_rescue'
/usr/lib/ruby/1.8/benchmark.rb:293:in `measure'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/benchmarking.rb:69:in`perform_action_without_rescue'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/rescue.rb:82:in`perform_action'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/base.rb:369:in`process_without_session_management_support'
/usr/lib/ruby/gems/1.8/gems/actionpack-1.11.2/lib/action_controller/session_management.rb:116:in`process'
/usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/dispatcher.rb:38:in
`dispatch'
/usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:141:in`process_request'
/usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:53:in`process!'
/usr/lib/ruby/1.8/fcgi.rb:600:in `each_cgi'
/usr/lib/ruby/1.8/fcgi.rb:597:in `each_cgi'
/usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:52:in`process!'
/usr/lib/ruby/gems/1.8/gems/rails-1.0.0/lib/fcgi_handler.rb:22:in`process!'
#{RAILS_ROOT}/public/dispatch.fcgi:24

On 3/17/06, cedric <cedric@feelfree.homelinux.com> wrote:> On my point
of view, single blog is just a particular case of a multi-blog>
implementation. This should becomes the default typo blog with a
default> setting to "single blog" for all people who want to install
their personal> typo. But I don't know if it's possible... if not there
must be 2 different> typo branches.> It's just my humble opinion, to
bring some ideas to community.>> Le Vendredi 17 Mars 2006 18:00, Gary
Shewan a écrit:> > On 17 Mar 2006, at 16:19, Piers Cawley wrote:> > >
"Kevin Kubasik" <kevin@kubasik.net> writes:> > >> Just a note, I found
that when attempting to update to the> > >> latestTrunk, rev 915 breaks
(it can't seem to add the new blogs> > >> tablecorrectly) 914 is good
though. It seems to me that a multiblog> > >> branchshould be handled
that way, in its own branch, not in the> > >> trunk(although the comment
seems to imply that it is being done in> > >> abranch, maybe im just SVN
illiterate)> > >> > > It's staying in the trunk -- the comment about the
branch was from my> > > local SVK based repository which I'd not edited
out.> > >> > > What errors were you getting when you tried to run the
migrations?> > > Could you send me a the relevant log section?> > >> > >
--> > > Piers Cawley <pdcawley@bofh.org.uk>> > >
http://www.bofh.org.uk/> > >
_______________________________________________> > > Typo-list mailing
list> > > Typo-list@rubyforge.org> > >
http://rubyforge.org/mailman/listinfo/typo-list> >> > Sigh, well that's
me not upgrading in trunk.  Multi blog support is> > bloat for those of
us running Typo on single sites.  I think it's a> > bad move to keep
this in trunk.  If you want me to throw a penny in> > I'd say split it
now.  The initial attraction of Typo because it was> > lean.  Why keep
multi blog in trunk when not everyone wants it?  It's> > screaming out
for a separate branch.> >> > God I hate bloat.> >
_______________________________________________> > Typo-list mailing
list> > Typo-list@rubyforge.org> >
http://rubyforge.org/mailman/listinfo/typo-list>>
_______________________________________________> Typo-list mailing list>
Typo-list@rubyforge.org>
http://rubyforge.org/mailman/listinfo/typo-list>

--Cheers,Kevin Kubasikhttp://blog.kubasik.net/
6451ee8093c9cedc94f6c813b4dde2c5?d=identicon&s=25 Kevin Ballard (Guest)
on 2006-03-18 03:38
(Received via mailing list)
Doing such would kill the Typo project. Maintaining two parallel
branches like that would be an absolute nightmare for maintenance,
and either one branch would wither and die or both would.
37f7d82de86bf788d3e6529341280305?d=identicon&s=25 Aaron Spiegel (Guest)
on 2006-03-18 04:06
(Received via mailing list)
> God I hate bloat.

How much bloat are we really talking about?  AFAIK, multi-blog is
adding just one "blog" model, and related the rest of those tables to
that... so we add one table, and one column to each model within a
blog.  Is that really significant enough to warrant a branch?

Just think we should identify what we're talking about...

Aaron
D6f24842b973de6cb75203c4c57dfbcb?d=identicon&s=25 Gary Shewan (Guest)
on 2006-03-18 11:23
(Received via mailing list)
On 18 Mar 2006, at 02:34, Kevin Ballard wrote:

>> lean.  Why keep multi blog in trunk when not everyone wants it?  It's
>> screaming out for a separate branch.

That's nonsense.  Since when has adding multiblog support to a
blogging engine killed the project?  You're scare-mongering and that
doesn't help.

I still say I don't like the idea of multiblog support being wedged
into the main trunk.  If it's going to be done, it needs to be done
right.  Textpattern still doesn't provide full multiblog support,
Wordpress has an entirely different project (Wordpress MU) and
Moveable Type worked on it in the background until it was ready.
Learn a lesson there.  Stamp on all the outstanding bugs.  Get
another good stable release out of the door and then look at
multiblog support.  One minute there's talk about the run up to 4.0
then the next multiblog support is jammed into trunk.

Madness.

But that's just my opinion ;)
F8534a86421283c6c2e3beb067d82fbb?d=identicon&s=25 Andrey Nikanorov (Guest)
on 2006-03-18 12:43
(Received via mailing list)
I think the same. Don't we have too much bugs in track to add "so big
feature"?
When this was committed, we get new bugs (postgres e.t.c.). If it's
impossible to do safe, maybe try it on branch an then commit to trunk?

On 3/18/06, Gary Shewan <gpsnospam@gmail.com> wrote:
> >> bloat for those of us running Typo on single sites.  I think it's a
> into the main trunk.  If it's going to be done, it needs to be done
> But that's just my opinion ;)
> _______________________________________________
> Typo-list mailing list
> Typo-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/typo-list
>


--
Nikanorov Andrey <nikanorov@gmail.com>
http://blogru.nikanorov.com
This email is: [ ] blogable [ x ] ask first [ ] private
0196ff65610046d2f8ba58bc4a45f144?d=identicon&s=25 Piers Cawley (Guest)
on 2006-03-18 18:08
(Received via mailing list)
Gary Shewan <gpsnospam@gmail.com> writes:
>>
>> Typo-list mailing list
> God I hate bloat.
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.
6451ee8093c9cedc94f6c813b4dde2c5?d=identicon&s=25 Kevin Ballard (Guest)
on 2006-03-18 21:39
(Received via mailing list)
On Mar 18, 2006, at 2:22 AM, Gary Shewan wrote:

>>> bad move to keep this in trunk.  If you want me to throw a penny in
>>> I'd say split it now.  The initial attraction of Typo because it was
>>> lean.  Why keep multi blog in trunk when not everyone wants it?
>>> It's
>>> screaming out for a separate branch.
>
> That's nonsense.  Since when has adding multiblog support to a
> blogging engine killed the project?  You're scare-mongering and that
> doesn't help.

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.
D6f24842b973de6cb75203c4c57dfbcb?d=identicon&s=25 Gary Shewan (Guest)
on 2006-03-19 15:23
(Received via mailing list)
On 18 Mar 2006, at 20:36, Kevin Ballard wrote:
> 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?

> 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.
7c9669bd19c08f8adc0b7cc92881b04c?d=identicon&s=25 Kevin Kubasik (Guest)
on 2006-03-19 16:38
(Received via mailing list)
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 <gpsnospam@gmail.com>
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/
0196ff65610046d2f8ba58bc4a45f144?d=identicon&s=25 Piers Cawley (Guest)
on 2006-03-19 19:48
(Received via mailing list)
Gary Shewan <gpsnospam@gmail.com> writes:

>> of the branches and for it to basically become a fork. But that's
> nonsense. I still say you're scare-mongering.  Nobody mentioned
>> because they're paving the way to *removing* bloat. In fact, they have
>> 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.
Fe351aa18bdb90281044828701d67d08?d=identicon&s=25 cedric (Guest)
on 2006-03-20 12:24
(Received via mailing list)
We need to have something really attractive to new users to have new
testers.
The "typosphere.org" is waiting for an evolution for a long time now.

The new users just have a 2.6.0 stable version, but if they want
something
attractive they must dive in the unstable version or the trac and its
patches...

I don't think it's the best way to be attractive.

I read something about pre4.0 version, but perhaps could we freeze for a
while the trunk to have a good intermediate release after a bug hunt
week
or day?

Typo is the toy of the brave developpers, and it must stay fun. But It
also must be attractive and rich for the users.

I respect the will of everyone, but it's perhaps the time to clarify the
status of all the Typo related stuff (i.e typosphere, versions, etc...)

I only want to ask everybody to clearly think about what they want Typo
to
be, explain it and then we can see if there's a common path to follow.

Regards
D6f24842b973de6cb75203c4c57dfbcb?d=identicon&s=25 Gary Shewan (Guest)
on 2006-03-20 12:48
(Received via mailing list)
On 19 Mar 2006, at 18:47, Piers Cawley wrote:
>
> simply won't get developed.
> for the people who stay on it and report back when they get cut by
>
> Hopefully the forthcoming pre4.0 series will let people get a good
> deal nearer to the edge without hurting themselves.

Thanks for that Piers, it's appreciated because you didn't have to
outline all that at all.  Much better attitude than some development
communities where any questions are met with "It's open source, we
give our time for free, deal with it or disappear"

I understand that it needs to be fun, and I've never met a developer
that really enjoys a good bug hunt over new functionality ... think
I'd have a heart attack if I did ;)  There is a growing interest in
Typo, but until there is a 4.0 release I never really recommend it to
anyone unless they feel confident about it.  Everybody I know who
isn't too technically minded - and has tried Typo - has pulled their
hair out in frustration.  I've been bitten hard a couple of times
with migrations, but that isn't a problem for me because I know what
working on the edge of trunk means.  I still have just over a
thousand legacy blog comments sitting in an sql file that I have to
reinclude because they got lost on one migration.  But that's what I
get if I only check 99% of everything after a trunk migration :)

I like the Typo system, I think you fellas are doing great work.
Just that a few of us went "Woah!" when we thought we saw a large bit
of new functionality (that not all users would use) get wedged in
just after talk of an imminent point release.  After all the first
line in Trac is "Typo is a lean engine..." ;)

Keep it fun, but also take some pride in the fact that people are
using it and as the number of users grow it speaks volumes about your
work.

Gary
0196ff65610046d2f8ba58bc4a45f144?d=identicon&s=25 Piers Cawley (Guest)
on 2006-03-20 13:46
(Received via mailing list)
Gary Shewan <gpsnospam@gmail.com> writes:
> On 19 Mar 2006, at 18:47, Piers Cawley wrote:
> Thanks for that Piers, it's appreciated because you didn't have to
> outline all that at all.  Much better attitude than some development
> communities where any questions are met with "It's open source, we
> give our time for free, deal with it or disappear"

Well, you know, I was tempted, but I thought of the three virtues of a
programmer (Laziness, Impatience and Hubris). The whole 'deal with it
or disappear' attitude is more along the lines of arrogance than
Hubris. Operating with those virtues tends to mean that stuff goes in
the trunk. If it turns out to be misguided, it gets rolled back. (For
instance, I just rolled back the change that replaced the global
config method with a this_blog method; I had temporarily forgotten
that there are more themes out there than Azure and they all of 'em
use config, not this_blog. Oops.)

> I understand that it needs to be fun, and I've never met a developer
> that really enjoys a good bug hunt over new functionality ... think
> I'd have a heart attack if I did ;)

I dunno, there's a lot to be said for squashing a good bug. When a bug
comes up in the trac that I can fix, I set to it with a will. Problems
arise when I'm either not convinced that something's a bug or I don't
have the knowledge or software to test it (the IE 6 issues, for
instance), or when the defect is obvious, but the design insight
needed to sort it out just isn't forthcoming. Then I go and work on
something that I know how to do.

> There is a growing interest in Typo, but until there is a 4.0
> release I never really recommend it to anyone unless they feel
> confident about it.

The "Typo installation is as friendly as a cornered rat" issue again
eh? From some of the things he's been saying about this on IRC, I'm
pretty sure you'll like Scott's work on this.

> Everybody I know who isn't too technically minded - and has tried
> Typo - has pulled their hair out in frustration.  I've been bitten
> hard a couple of times with migrations, but that isn't a problem for
> me because I know what working on the edge of trunk means.

And it's because we have to deal with the support issues that arise
when these things happen that we've been working on making the last
few migrations as painless as possible. The new BareMigration system
is a massive improvement here and a thousand thanks are owed to
bronson@rinspin for the fabulous patch that introduced BareMigrations
and rejigged all the migrations to use them. I now have a great deal
more confidence that I can make a migration work independently of any
future changes in the behaviour of typo's model objects and that's an
enormous godsend. I'm now pretty confident that you can migrate up to
the bleading edge from any schema version you like, and that's a
massive improvement on the the bad old days of, um... not all that
long ago recently.

> I still have just over a thousand legacy blog comments sitting in an
> sql file that I have to reinclude because they got lost on one
> migration.  But that's what I get if I only check 99% of everything
> after a trunk migration :)

Ow! Ow! Ow!

I'd suggest copying your production data into a development database
and then, assuming N is the schema version that the comments you have
come from, do:

  $ rake migrate VERSION=N
  $ <appropriate rdbms commandline> < all_those_comments.sql
  $ rake migrate

and test like crazy.

If it works you can take the production version down for a few minutes
and do the same thing with the production database. If it doesn't,
it'd be good to know why no.

> I like the Typo system, I think you fellas are doing great work.
> Just that a few of us went "Woah!" when we thought we saw a large
> bit of new functionality (that not all users would use) get wedged
> in just after talk of an imminent point release.  After all the
> first line in Trac is "Typo is a lean engine..." ;)

I'm not entirely sure how true that still is. Probably more of an
aspiration than a fact on occasions.

> Keep it fun, but also take some pride in the fact that people are
> using it and as the number of users grow it speaks volumes about
> your work.

Oh yeah; gaining users is good. Admittedly, the whole "More cattle;
more care" thing rears its head, but but the relationship's more along
the lines of O(logN) than O(N), so that's okay.
D6f24842b973de6cb75203c4c57dfbcb?d=identicon&s=25 Gary Shewan (Guest)
on 2006-03-20 14:33
(Received via mailing list)
On 20 Mar 2006, at 12:46, Piers Cawley wrote:

>> There is a growing interest in Typo, but until there is a 4.0
>> release I never really recommend it to anyone unless they feel
>> confident about it.
>
> The "Typo installation is as friendly as a cornered rat" issue again
> eh? From some of the things he's been saying about this on IRC, I'm
> pretty sure you'll like Scott's work on this.

That's good news.  That's the first complaint I hear.  But in my
experience it's always been a platform/host issue that has caused the
problem.

> and rejigged all the migrations to use them. I now have a great deal
> more confidence that I can make a migration work independently of any
> future changes in the behaviour of typo's model objects and that's an
> enormous godsend. I'm now pretty confident that you can migrate up to
> the bleading edge from any schema version you like, and that's a
> massive improvement on the the bad old days of, um... not all that
> long ago recently.

That is even better news.  Migrations were always a 'Hold your
breath' issue ... part of the fun though ;)  Still, anything that
reduces potential pain is fantastic.

>
>   $ rake migrate VERSION=N
>   $ <appropriate rdbms commandline> < all_those_comments.sql
>   $ rake migrate
>
> and test like crazy.
>
> If it works you can take the production version down for a few minutes
> and do the same thing with the production database. If it doesn't,
> it'd be good to know why no.

Oh it's more exciting than that.  I went through two trunk jumps
before I realised that all the comments before a certain date were,
er, gone.  So the backup of the comments are actually sitting in an
sql file extracted from a Textpattern backup file so they have to be
converted to a Typo form and then reintegrated.

I'm going to have to really be in the mood to tackle that little task
- and probably have nothing better to do :)  My ego doesn't need all
those comments reintegrated in any hurry, so it's definitely a
backburner issue.

Gary
6451ee8093c9cedc94f6c813b4dde2c5?d=identicon&s=25 Kevin Ballard (Guest)
on 2006-08-03 13:29
(Received via mailing list)
The number of tickets for 4.0 left is a small number. Hopefully we
can get them dealt with fairly quickly.
This topic is locked and can not be replied to.