[kforge-dev] proposal: remove Routes from KForge
john.bywater at appropriatesoftware.net
Tue Sep 16 17:27:09 UTC 2008
In summary: there were no user stories for which we had failing tests,
for which Routes was the Simplest Thing That Could Possibly Work. KForge
wasn't broken, and Routes didn't fix anything. It was just factored in.
That was a technical mistake because it made things more complex, and
less stable. This is evidenced by the failed deployment test. We should
feel an imperative to remove it.
Rufus Pollock wrote:
> On 11/09/08 19:26, John Bywater wrote:
>> I would like to propose that we don't need to use Routes in KForge.
>> We've just got a very static resource location map, and we can
>> improve the stability of KForge (and reduce the testing requirements)
>> by replacing Routes with a simple lookup table.
> A big -1 here. Please can we stick with routes.
I'm really not sure. Can you explain why was it introduced in the first
place? I don't know why it was. I honestly can't identify the problem it
solves in KForge.
So, it seems rather unnecessary. Since Routes adds brokenness, but no
necessary functionality, there is a technical imperative to remove it:
what Routes accepted as valid input for 1.7 it doesn't accept for 1.9,
and this renders KForge completely useless. As we don't need it we must
dispense with it. Less is more!
> Routes does what it does nicely
Apart from when it just doesn't work. :-)
> and writing our own module to do (pretty much the same thing) does not
> make sense.
If replacing it with something very simple (ie a lookup table, or even
returning to in-lined location paths -- as we used to have before Routes
was introduced) would take *more* time than it is now taking to do all
this: to have noticed there is a problem; to fail to identify what the
specific problem is and to ask each other if we know; to describe it in
writing and write considered replies; to discuss it by email and face to
face; (and then I would hope) to write deployment tests across all
available Routes versions; then to fix KForge for this bug; to commit
the changes and rebuild the distribution; to test the new distribution
across all the variations of all the dependencies etc etc; then I would
certainly agree with you. But my estimation is that the low-energy route
is to remove Routes from KForge without further discussion. (But I won't
do it without a consensus.)
I find myself in disagreement with the above statement because KForge
had no identifiable requirement for Routes. When Routes was introduced
to KForge, there wasn't anything broken in KForge that it fixed. Also,
there was never a consensus to introduce Routes. I don't believe using
Routes magically makes for a better system. Now we've seen this bug,
it's clear that it's made KForge worse. Forming KForge URLs hadn't
previously caused anybody any problems. The uriPrefix stuff was messy in
the templates, but we could have simply factored that out as a simple
function, with a path string parameter that would receive the prefix.
That would have been wholly adequate, and very stable. Now KForge has a
problem (as does everybody who installs KForge who happens to have
Routes 1.9 installed). Therefore we have a problem. The problem is Routes.
> It also has a few features that could make it useful in the future
> (e.g. subdomain generation etc).
Oh, this is a total no brainer: You Aren't Going To Need It.
Let's just agree about this, and move on?
>> If I don't hear any objections, I'll do this at the next opportunity.
>> Best wishes,
>> PS I've got a green bar again with those tests running against Routes
>> 1.7. But that doesn't feel very satisfactory to me.
> What exactly what failing with Routes 1.9? It should not be hard to
> fix this up.
I don't know. This is part of the problem. Routes doesn't tell us! The
errors are on this page:
But I suggest we don't need to work it out. It should be a "no-brainer":
We don't need (never have needed) Routes in KForge. We do, however, need
to setup much more testing, so we can continuously verify KForge
functions across the range of dependencies. It was only remote testing
of the stable releases and release candidates that picked up this bug.
What other bugs are there that we aren't finding whilst we debate this?
We don't know. If we remove Routes we don't need to test KForge across a
range of Routes versions. And we know now that not all 1.x versions of
Routes work in the same way. That should be enough information for us to
agree to remove it (at least for the time being).
We wouldn't need to edit all the templates. Just replace the called
url_for() method with something dead simple (like adding its string
If there truly is no necessity to use Routes in KForge, I will ask you
to consent to the change I proposed. If there is such a necessity, I
will ask you to help me setup /provide/ to establish more comprehensive
continuous integration testing regime for KForge. :-)
All best wishes,
PS Can you (somewhere safe) deploy and test that KForge 0.15 actually
works when you use it in your browser? I've check most of the core stuff
manually, but none of the plugins.
> PS: I don't think we need to keep cc'ing this kforge-specific
> questions to okfn-help ;)
Sure - I wasn't sure if you were trying to converge all OKF dev lists to
okfn-help, but we established we don't want to move this list.
Appropriate Software Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kforge-dev