[kforge-dev] proposal: remove Routes from KForge

[John Bywater]

Hi Rufus,

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.

Details below....


Rufus Pollock wrote:
> On 11/09/08 19:26, John Bywater wrote:
>> Hello,
>>
>> 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,
>>
>> John.
>>
>> 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:

http://appropriatesoftware.net/buildbot/builders/Systems/builds/87/steps/shell_6/logs/stdio

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 
parameters together).

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,

John.

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.

>
> ~rufus
>
> 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
http://appropriatesoftware.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/kforge-dev/attachments/20080916/02670270/attachment-0001.html>