[isf-wifidog] errors in fresh install of cvs head

[Rob Janes]

> In short, yes Rob we would be pleased contributions from you, but  
> without a good roadmap and without making sure developpers know where  
> the project is heading we cannot engage in serious modifications to  
> the core foundations (database etc...). 


This is the problem.  I have no idea what you guys consider acceptable 
for me to checkin, but have no other process for acceptance than 
check-in.  I am sitting on about 6000 lines of changes to wifidog-auth 
dealing with installation, language selection, database abstraction, 
logging, stylesheets and code locating, all of it integrated, tested, 
working, and maintained up-to-date with mergings from cvs head.  I am 
lacking guidelines, coding standards, a clear definition of what is core 
(database etc), a roadmap, where the project is heading, etc etc, and am 
simply at a loss at what to do or if my work is of any relevance.  Here, 
this most tame, most innocuous of changes, a three line fix I thought 
was a slam dunk, is rolled back for a few weeks of peer review.

Fine.

Perhaps one of you would enlighten me as to what process I should follow 
so as to contribute productively to wifidog.  You know, things like what 
is welcome and what is unwelcome, what is friendly and what is not, 
who's working on what and who's toes I might possibly, likely, 
unknowingly, step on.  I mean, I feel like I'm walking through a mine 
field here.  A map would be nice.

Let me put this out.  I have three pieces of code I think will help 
wifidog (well, I have lots of pieces, but this is a place to start).  
Maybe they aren't at the top of your priority list (whatever the heck 
that is), but this is what I have:

1.  Event logging, which is intended to encapsulate php errors for 
proper css styling and also for logging to file so that developers don't 
have to reproduce the error to see what went wrong.  I already checked 
the class in.  From my encounter with Benois, it seemed like this was 
the most welcome of what I had done, or perhaps the least unwelcome.  To 
carry through with this I would have to make changes to the MainUI to 
use it.  I have had those changes for some time now, of course.  They 
were developed at the same time I wrote EventLogging.  They are based on 
sourceforge though, and from Max I infer that the way smarty assembles 
the page has changed considerably.  Still, I could get the ball rolling 
- if the ball wants to roll.

2. Style sheet.  It's been noted that the smarty include of the 
stylesheet in every html page is ponderous, and moreover doesn't work 
when included from other levels in the directory hierarchy.  I have a 
solution to this.

3. language selection.  What's at cvs head is still not right, but at 
least there are no errors if you follow the instructions carefully, and 
change en_US to en_CA, cause unlike ny wireless we have en_CA as our 
locale.  I have some changes to make the defaults work better within 
apache, HTTP_ACCEPT_LANGUAGE, and the os locale settings.

As to why I worked these through rather than taking something off the 
todo list I saw float by a couple of months ago and work that to death, 
it's entirely about my experiences installing wifidog-auth for Wireless 
Toronto.  I fixed what was broken, made what was missing.  You guys 
maybe don't see this stuff because you don't do fresh installations too 
often.  Or maybe you do, but you've been through it so many times you 
fix the problem before it even happens.

I have been extremely reluctant to check anything in.  I can only 
imagine the fuss if BC Wireless ever comes through and checks their 
stuff in.  Should I just toss this off, or should I open up wifi-cat-dog 
on sourceforge and dump it all there?  Just kidding.

cheers
-rob

Proulx François wrote:

>>
>> In my opinion, it would be nice if the code on sourceforge didn't  
>> have these visibly apparent errors in it.
>>
>
> I will try to make sometime during this week to install from a fresh  
> CVS copy to sort it out ...
>
>> As an aside, you guys really need more developers involved more  
>> familiar with the rigours of installing wifidog on fresh systems,  
>> using the tools posted on sourceforge rather than somewhere in  
>> Montreal.  Am I really the first one in?  I am definitely getting  
>> mixed messages here, being taken to task by Benoit about Database  
>> stuff, and now Max thinking I haven't done my homework.  Do you  guys 
>> really want code checked in from other sister sites?  Do you  really 
>> want developers involved not physically in Montreal?  Sorry,  I just 
>> have to ask.
>
>
> We do want check in from people outside Montreal. In fact, Max is  
> from Berlin and we are very pleased of the contributions he made in  
> the past 2 months. As all of us are involved in this project on a  
> volunteer basis and have either school or work communications are  
> definitely not as good as they could be. Most of us are aware of many  
> of the issues, including improving the database abstraction etc...  
> but with most of the original creators pretty busy right now, we  
> don't have lots of time of actually sit down and write a bunch of  
> clean, comprehensive roadmap and documentation. I know it's really  
> painful for everybody. I will try to work a bit on wifidog this week,  
> but I also have to rest a bit, as the past few months have been  
> pretty exhausting.
>
> In short, yes Rob we would be pleased contributions from you, but  
> without a good roadmap and without making sure developpers know where  
> the project is heading we cannot engage in serious modifications to  
> the core foundations (database etc...).
>
> See ya
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>WiFiDog mailing list
>WiFiDog at listes.ilesansfil.org
>http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>