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 K.http://blog.kubasik.net/
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…
“Kevin K.” [email protected] 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?
On 17 Mar 2006, at 16:19, Piers C. 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.
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 K.
On 3/17/06, Gary S. [email protected] wrote:>> On 17 Mar 2006,
at 16:19, Piers C. wrote:>> > “Kevin K.” [email protected]
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 C. [email protected]> >
http://www.bofh.org.uk/> >
_______________________________________________> > Typo-list mailing
list> > [email protected]> > 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>
[email protected]>
http://rubyforge.org/mailman/listinfo/typo-list>
–Cheers,Kevin K.http://blog.kubasik.net/
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 S. a écrit :
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_databaseCompleted 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 »’, :controller => “/” %>22:23: 24:
<%= link_to "Typo admin - #{this_blog.blog_name}",:controller => "/admin/" %>
25: 26: 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:24On 3/17/06, cedric [email protected] 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 C. wrote:> > >
“Kevin K.” [email protected] 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 C. [email protected]> > >
http://www.bofh.org.uk/> > >
_______________________________________________> > > Typo-list mailing
list> > > [email protected]> > >
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> > [email protected]> >
http://rubyforge.org/mailman/listinfo/typo-list>>
_______________________________________________> Typo-list mailing list>
[email protected]>
http://rubyforge.org/mailman/listinfo/typo-list>
–Cheers,Kevin K.http://blog.kubasik.net/
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
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.
On 18 Mar 2006, at 02:34, Kevin B. 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 
Gary S. [email protected] 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.
On Mar 18, 2006, at 2:22 AM, Gary S. 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.
On 18 Mar 2006, at 20:36, Kevin B. 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.
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 S. [email protected] 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
[email protected]
http://rubyforge.org/mailman/listinfo/typo-list
–
Nikanorov A. [email protected]
http://blogru.nikanorov.com
This email is: [ ] blogable [ x ] ask first [ ] private
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 K.On 3/19/06, Gary S. [email protected]
wrote:>> On 18 Mar 2006, at 20:36, Kevin B. 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 waySurely 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>
[email protected]>
http://rubyforge.org/mailman/listinfo/typo-list>
–Cheers,Kevin K.http://blog.kubasik.net/
Gary S. [email protected] 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
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 B.'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.
On 19 Mar 2006, at 18:47, Piers C. wrote:
simply won’t get developed.
for the people who stay on it and report back when they get cut byHopefully 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
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
Gary S. [email protected] writes:
On 19 Mar 2006, at 18:47, Piers C. 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
$ < 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.
The number of tickets for 4.0 left is a small number. Hopefully we
can get them dealt with fairly quickly.