Follow-up Comment #7, bug #2880 (project savane): > I am not trying to besmirch your *n*x skills! Just a difference of > philosophy. Some of us like to keep our system bin, lib, and so on > directories very "clean", and keep binaries and the like that relate > only to a particular application inside subdirectories of that application's > installation directory. It'd be nice to have the option to do so with savane, > that's all. > If it's not something that a human user will ever run, some of us don't like
http://www.debian.org/doc/debian-policy/ch-files.html#s-config-files > to be concise and fast. A common problem with online communication, lacking > voice tone, facial expression, etc. And I don't use smileys enough maybe. > :-) Sure, it makes a difference :) Even if smiley looks childish, in many cases it truly helps to get the state of mind of persons, and that very helpful. > Anyway, as to the documentation and your note on another thread about > submitting actual code/doc contributions before attempting to join the > savane-doc project, I certainly understand that and could happily do an edit > of those docs with various suggested clarifications In fact, I think my reply was only about the project savane itself, not savane-doc, which project I'm not an admin of. > savane.mysite.com/projects/%PROJECT as "the homepage" of the > project; having something else called "Homepage" is confusing. It > strikes me that what Savane calls "Homepage" is really something > more like a "Documentation and Additional Project Info" page. Given > that, and the ability to add an admin documentation "extra" page, > AND that the link presently called "Server Admin Docs" isn't docs at > all but admin features, I think the conceptual structure of this stuff could > be adjusted a little to be less confusing by doing the following: > > * Change "Homepage" in Group Type to "Documentation & > Additional Project Info Page", explain that it can be a local page or a > remote one, and that it is NOT the auto-created /projects/%PROJECT page (this > last part in particular had confused me all along) I get your point, but that change is not feasible for now since there are case where /projects/%PROJECT is actually not the project homepage, while the other page with the link homepage is, and projects that would absolutely not have their savane main page confused with their homepage. I know that the menu can be confusing. It surely could be improved somehow. But each change have to take into account different usages among savane installation, and some things are hard to change. The best we found to distinguish the savane homepage and another homepage that could in several cases be the real project homepage is to call the savane homepage "main" page in the interface. > * Change left menu's "Server Admin Docs" to "Admin > Options" and move it to the first spot under "$sys_name > Administration" in the left menu, since it really admin options, not > admin documentation at all Server Admins Docs is nowaday irrelevant, but Admin Options would clearly lead to think there are "option" to configure there. While it is not the case. (I havent seen any option there) > * Change "Get Support" under "$sys_name Help" in left menu > to "%sys_name Support". What problem would it solves? We decided to use this expression one or two years ago, it was the less confusing we could find for the site support. Since then, only few requests were misdirected. So it apparently works. So if it works, why changing it? There's deliberately nothing in the left menu related to the group at hand, or only in some case the search box (behavior which is unclear anyway, it should somehow be changed). The left menu should be treated as a "site menu", while other more specific menu are on the top of pages, like the "project menu". > At any rate, my personal main concern at this point is the inability to turn > on the Bugs Tracker (in any project or project group) in my setup (Savane > 1.1.0, Fedora Core 4, PHP 5, MySQL 4). It's awesome that twiddling two > variables in php.ini enabled the tasks/requests in the Trackers to be > editable. I'm suspecting there must be a similar PHP5-related problem > responsible for the fact that Bugs Tracker cannot be turned on even if Group > Type says it should be available. If there is any php.ini or other suggestion > you'd like me to test, I'll be quite happy to, as well as reporting any > logfile stuff you'd like to see. That should probably contribute to a full > understanding of how to get Savane running under PHP5. Yes, we need to sort this out. I'll try to come up with other suggestions. Considering the number of software based on PHP, somehow these guys should provide an option to force PHP to run like if it was PHP 4, like one can do with perl. > It SEEMS like this shouldn't be too hard to figure out. What is different > about the the Bugs tracker compared to the Support and Task trackers? Those > two are working fine under PHP5. It's only the Bugs one (which I guess is > kind of ironic! >;-) So that's probably where the problem is, I would have > to guess. That's actually very weird. All trackers share the same code, so they work the same. There may simply be a bug in the form, or maybe something goes wrong with the database when you created the project while there was not the necessary PHP options. Have tried creating another project? > I tried just sv_membersh by itself, and then tried 'sv_membersh cvs' and got > the same error (except that the second one mentioned cvs as the command that > wasn't allowed, and the first one had a blank in that part of the error > message of course). I did not try providing any commandline options to 'cvs' > after 'sv_membersh' if that is what you mean. I wasn't actually trying to do > anything functional with it, just seeing if it would do anything at all. Like > when I run 'cvs' from my regular shell, I get the "Usage:" message. > when I run 'sv_membersh cvs' I would expect to get the same thing, since > sv_membersh is told by membersh-conf.pl that 'cvs' is one of the very few > allowed commands. But I don't get the "Usage:" message from cvs, > just a sv_membersh error that I'm not allowed to run the command 'cvs'. > Seemed kind of weird. That's what is in fact expected. sv_membersh is a restricted shell that will, if you configure it to accept cvs login, only "cvs server" commands, which are the only necessary to remotely work on a cvs repository. _______________________________________________________ Reply to this item at: <http://gna.org/bugs/?func=detailitem&item_id=2880> _______________________________________________ Message posté via/par Gna! http://gna.org/ _______________________________________________ Savane-dev mailing list Savane-dev@gna.org https://mail.gna.org/listinfo/savane-dev
