On Tuesday 13 June 2006 06:16, Mathieu Roy wrote: > Le 10/6/2006, "Mark Constable" <[EMAIL PROTECTED]> a écrit: > >On Sunday 11 June 2006 03:11, Sylvain Beucler wrote: > >> I guess creating a SVN branch would be ok. Maybe you'll need to > >> separate the "clean-up" changes and the user interface > >> improvements. Mathieu, what do you think? > > I have nothing against the idea of opening a branch, but I'm very > doubtful of the feasibily of such approach. In my experience, forking > and merging over a long period of time is simply something that does not > work. The merge cost more time than just doing everything from scratch.
But, perhaps, the freedom to experiment, and not being restricted by the current codebase direction, can lead to invigorating ideas. > The current SVN version got already a different menu system. This SVN > version should be release someday, there only a few things to test > regarding the "wiki-like" markup stuff (see related tasks). Ah right, I wasn't aware of that. > Actually, I can already tell you todo that restructuring all links would > probably never make it in a release. Most important promoters of Savane > are structure like CERN that definitely cannot afford to have changing > links and this kind of things. Dont try to convince me, it is just a > no-go and it is not up to me. It's for reasons like this that I figure I would need to "fork" my own version. The difference would have to be something like... https://savane.shuttle.lan/account/login.php?uri=%2F vs https://savane.shuttle.lan/?o=account&m=login&uri=%2F where whatever was in account/ would become a class with login() being a method. I haven't look at exactly how feasible this example would be but something along these lines is how I would refactor the code. > I'm surely very happy whenever we clean up how Savane works. But the > user-base cares more about keeping something that properly works it used > too than having brand new stuff. I am aware of this need which is why I keep mentioning "fork" in the most cooperative and benign way possible. > As said before, in places where Savane is actually used, you have plenty > of configurations used (not speaking about a few MSIE and GNU/Linux, > really plenty, and some very very old crappy things), and for the next > coming years, javascript simply cannot be required to perform a task, > because it is simply not reliable. See my comment above. > Actually, the current approach is already documented, and works properly > I think. Plenty of pages now area actually working with register global > off. But not everything, and what matters is definitely that everything > works - because that's what matter to the user-base. Not that they are strictly errors at all but setting error_reporting(E_ALL) is rather scary. > That would surely not make it into mainstream release. Ask me and I'll > tell you PHP is total crap, most of the recurrent problems into Savane > are caused because this a very very dumb langage, and all these register > globals stuff exists only to fix problems that does exists in first > place with a decent langage like perl (and I do not even talk about how > list/hashes work in PHP, without mentioning the very unconsistent > function naming policy). The only good thing into PHP are the docs. > Apart from being not very smart, it is slow and it is very doubtful that > PHP would be able to do what the backend do in a decent time. To be fair, I would agree with you about legacy PHP3 based code where the code logic was sprinkled throughout the HTML presentation files... that leads to a disaster for long term maintenance. > But the thing is not simply that PHP is a pain in the ass, the fact is > Savane requires a real system, not a ftp account, to work properly for > usages like providing CVS, download area, etc, because the point is to > provide developer-level tools based on SSH. And if you can have SSH, you > definitely can have perl. That also leads to potentially very nasty security issues which then have to be coded around. My approach would be to offer whatever was needed to be done via ssh via a web interface instead... if possible. In my case, if I were to seriously deploy, I would HAVE to disable all ssh access because my systems simply do not, and never will, have normal shell accounts available. I would provide the minimum functionality via ssh using authorized_keys commands... command="sudo /usr/local/bin/update_svn",no-port-forwarding ssh-dss etc > So servers without shell accounts are not really a good place to install > Savane, unless you really only want the trackers (bugs, tasks). In this > case, most scripts are anyway useless. You would just have to rewrite > sv_aliases, I guess. That is mostly the case. It's the web interface I am mainly interested in... along with svn and mailing-list management. > Bash is slower than perl to do anything complicated, it has not strict > mode, lists are way more limited, it is unsecure in many way, it has not > direct interface to access database, etc. Bash is good for two lines > stuff, but if you ever need to access database and deals with big lists, > there's no match. Exactly, simple things that only require a dozen lines are fine in bash. For anything else I use PHP, mainly because I can tap into some backend libraries already written for the web frontend. > >> > PHP5 picked up one bug so far... line 33 in include/graphs.php > >> > was "break;" instead of "return;". > Fixing code errors are definitely wanted. :) Well that was one. It's probably only a warning in PHP4 but using a continue outside of a for or while loop is a no-no. That perfectly illustrates my point about legacy PHP code, especially in a large codebase such as Savane. If Savane was to be rewritten from scratch using PHP5 today it would not be anywhere near as fragile and "stiff" as it is now. I say "stiff" in the sense that Savane works fine for exactly what it's meant for and as long as it's installed under fairly restrictive conditions (which is all that is demanded of it) but it doesn't lend itself to being used outside of it's scope. That is not a bad thing and I'm probably just stating the obvious. FWIW I have now had more time to look at the Savane codebase and it is indeed HUGE. I could well imagine it could take me a year to reach the goals I envisage. I might be better off starting with websvn and building up a project than restructuring Savane for my needs. --markc _______________________________________________ Savane-dev mailing list [email protected] https://mail.gna.org/listinfo/savane-dev
