Re: [leaf-devel] Config system
Hello Chad, I really think we were miscommunicating,( we have different background ;) ) but I'll try again > > Packages Packages own templates of their configuration files or scripts to generate those packages ( even better) Packages own several variables ( necessary to configurate the package) The values of this variables are stored in a database A) Some of the variables are only used in scripts of this specific package ( f.e ppp0_dialnr) A change would have an effect only on this package B ) Others are used in several packages.(for.example eth0_ipaddress) a change to one of those would effect several packages A variable and a package cannot know if it ( variable) belongs to group A or B (someone could have added a new package that makes a variable belong to more than one package). So to be on the safe side, assume all packages belong to group B) The variable must know the scripts it is "tied to" The database is assessed only by a config-db api that reads and writes a "key" or a "tree" Some userinterface ( for example webinterface) requests variables from the database and uses them to create a webpage based on a script belonging to a "userinterface-script pool" . After input by the user, the now possible changed variables (in userspace) are presented to the config-db to be set in the database. (config-db.set var1 var2 ...) Now it is necessary to "commit" this changes so the config-files are still in sync with the database. At commit the config-files "tied-to" the changed vars are regenerated After change of config-files the belonging services are restarted. I think untill now we are communicating the same infrastructure. My proposition was to create a database in the same tree structure variable /tied-toscrip1.name (content script to run after changeing tied- toscript1.name) variable/ tied-to sciipt2.name (this was my "dependant" database. example #ls eth0 eth0/etc/interfaces eth0/etc/shorewall/interfaces #cat eth0/etc/interfaces ifdown eth0 ifup eth0 # cat eth0/etc/shorewall/interfaces shorewall restart ( ) after changeing a variable drop the tied-script.name s in a queue after finishing the interaction user <-> interface update all scripts in the queue These commits can be queued untill the end of the user configuration session ( so after making 3 changes the sripts don't have to run 3 times) () > - then I back myself up (heh. I don't know the intimates of how > this one is done, Mr. Wolzak) How, will depend on the packageing system to choose uptill now it will be lrcfg.back.script with some options. > > I am obviously not getting what you are saying here. Please elucidate > further. Please keep in mind that I am only speaking of the framework > and infrastructure here, and not in detail on the specifics of the web > interface. We need a firm concept and toolset before we start webbing! this is a misunderständing, I mentioned the webinterface to show one way of user interaction. I suggested that each package contains a file with the 1. names of the used vars 2. type of the vars ( to make it easier for the user interface) 3. possible values ( if a var can have only three different options ) the idea behind is to make the system of "validating changes" and presenting to user easyier We need only a few routines in the commit section that checks a value and can be used by each script that adaps config files. used as toolset. I thought about it as I was still considering that a script to create a config file would look like # this is xyz config $dev $ip_address # the hostname is $hostname $dialyesno dial $dialnr $option_1 $option_2 But the template script probably would be better in a form #!/bin/bash writecomment this is xyz config write $dev $ip_address write_if_set dial $dialnr writerepeat $option in this case that information is in the template script, a gui script could then easily be analog. Sorry dreaming above the infrastructure ; ) regards Eric Wolzak member of the bering crew --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Config system
On Sun, 2003-02-09 at 05:58, Eric Wolzak wrote: > Hello Chad, I really think we were miscommunicating,( we have different background > ;) ) but I'll try again > > > >Packages > Packages own templates of their configuration files or scripts to generate those > packages ( even better) > Packages own several variables ( necessary to configurate the package) > The values of this variables are stored in a database > A) > Some of the variables are only used in scripts of this specific package ( f.e > ppp0_dialnr) A change would have an effect only on this package > B ) Others are used in several packages.(for.example eth0_ipaddress) a change to > one of those would effect several packages > A variable and a package cannot know if it ( variable) belongs to group A or B > (someone could have added a new package that makes a variable belong to more > than one package). So to be on the safe side, assume all packages belong to group > B) > The variable must know the scripts it is "tied to" Not really. Why must it? Any interface that configures the variable simply fires the trigger that says it has done so, which means "run all the scripts in this directory" and it is done. If someone wants to tie into a variable in package B, he simply drops a script into the trigger directory for the event he wants to act upon, and when he is called, gets the current value from the config-db, remakes his templated config files, and restarts himself. > The database is assessed only by a config-db api that reads and writes a "key" or a > "tree" > Some userinterface ( for example webinterface) requests variables from the > database and uses them to create a webpage based on a script belonging to a > "userinterface-script pool" . > After input by the user, the now possible changed variables (in userspace) are > presented to the config-db to be set in the database. (config-db.set var1 var2 ...) > > Now it is necessary to "commit" this changes so the config-files are still in sync >with > the database. > At commit the config-files "tied-to" the changed vars are regenerated > After change of config-files the belonging services are restarted. > > I think untill now we are communicating the same infrastructure. Yes. The variables are "tied to" the scripts via the trigger mechanism. That way, the variable can be untied simply by deleting the script (or more likely just not installing the package). The beauty of the mechanism is that the variables and scripts are "tied" in a loosely coupled manner, which means that either can be removed or changed without effecting the other, as long as the interface (config-db value, trigger and args) remain unchanged. > My proposition was to create a database in the same tree structure > variable /tied-toscrip1.name (content script to run after changeing tied- > toscript1.name) > variable/ tied-to sciipt2.name > (this was my "dependant" database. > > example > #ls eth0 > eth0/etc/interfaces > eth0/etc/shorewall/interfaces > > #cat eth0/etc/interfaces > ifdown eth0 > ifup eth0 > > # cat eth0/etc/shorewall/interfaces > shorewall restart > > ( ) > after changeing a variable drop the tied-script.name s in a queue > after finishing the interaction user <-> interface > update all scripts in the queue > These commits can be queued untill the end of the user configuration session ( so > after making 3 changes the sripts don't have to run 3 times) > () Okay. We are speaking the same language, but mine is a bit more abstract (could be considered good or bad). A group of changes (say ip address, mask and gateway for an interface) may be aggregated into a single event using the trigger mechanism. The triggers are still in a tree like so: /leaf/trig ip/change ip/add ip/del network/change dhcpd/range/add dhcpd/range/del dhcpd/globals/change etc... I will think through your proposal a bit more. I am thinking it could be better, as long as we can resolve temporal coupling between the scripts (i.e. the system interfaces file must be updated and network restarted before shorewall interfaces and restart...) > > - then I back myself up (heh. I don't know the intimates of how > > this one is done, Mr. Wolzak) > How, will depend on the packageing system to choose uptill now it will be > lrcfg.back.script with some options. I figured you could shed more light on this when the time came ;-) > > I am obviously not getting what you are saying here. Please elucidate > > further. Please keep in mind that I am only speaking of the framework > > and infrastructure here, and not in detail on the specifics of the web > > interface. We need a firm concept and toolset before we start webbing! > > this is a misunderständing, I mentioned the webinterface to show one way of user > interaction. > > I suggested that each package contains a file with the > 1. names of the used vars > 2. type of the va
[leaf-devel] ML volume
Everyone, It has come to my attention that our leaf-user list volume is discouraging some/many users from using it. We have a variety of options to address this issue. a) Keep things as they are. b) NNTP support (news.gmane.org and/or nntp.sourceforge.net) c) Web support (SF forums for each LEAF release/branch) (note: we already use SF support trackers) d) New LEAF release/branch specific MLs. leaf-bering leaf-dachstein leaf-lince leaf-oxygen leaf-packetfilter leaf-wisp-dist Any suggestions, comments, or opinions are welcome. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
Mike Noyes wrote about "[leaf-devel] ML volume": > Everyone, > It has come to my attention that our leaf-user list volume is > discouraging some/many users from using it. We have a variety of options > to address this issue. I'd vote for separate mailing lists, at least for WISP-Dist. Apart from other reasons it is also hard for me to keep with all the traffic in leaf-user and basically what I do is filter out all messages which have "wisp" inside them and read the rest of leaf-user as time permits. -- Best Regards, Vladimir Systems Engineer (RHCE) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
On Sun, 2003-02-09 at 09:45, Mike Noyes wrote: > Everyone, > It has come to my attention that our leaf-user list volume is > discouraging some/many users from using it. We have a variety of options > to address this issue. > > a) Keep things as they are. > > b) NNTP support (news.gmane.org and/or nntp.sourceforge.net) > > c) Web support (SF forums for each LEAF release/branch) (note: we >already use SF support trackers) > > d) New LEAF release/branch specific MLs. > leaf-bering > leaf-dachstein > leaf-lince > leaf-oxygen > leaf-packetfilter > leaf-wisp-dist e) Split leaf-user by adding leaf-user-new -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
On Sunday 09 February 2003 11:45 am, Mike Noyes wrote: > b) NNTP support (news.gmane.org and/or nntp.sourceforge.net) I like NNTP, but it doesn't necessarily address the volume problem at all. > d) New LEAF release/branch specific MLs. > leaf-bering > leaf-dachstein > leaf-lince > leaf-oxygen > leaf-packetfilter > leaf-wisp-dist This would address the issue for most of the discouraged users, but would be a real PITA for NNTP front-ends. Seperating the mailing-lists this way might be the better route and make life easier for subscribers of multiple lists IMHO. -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
Mike Noyes wrote: > > On Sun, 2003-02-09 at 09:45, Mike Noyes wrote: > > Everyone, > > It has come to my attention that our leaf-user list volume is > > discouraging some/many users from using it. We have a variety of options > > to address this issue. > > > > a) Keep things as they are. > > > > b) NNTP support (news.gmane.org and/or nntp.sourceforge.net) > > > > c) Web support (SF forums for each LEAF release/branch) (note: we > >already use SF support trackers) > > > > d) New LEAF release/branch specific MLs. > > leaf-bering > > leaf-dachstein > > leaf-lince > > leaf-oxygen > > leaf-packetfilter > > leaf-wisp-dist Add to d) leaf-general, or some such. If this is divvied up to fine, then how will the generalists lend support? > e) Split leaf-user by adding > leaf-user-new -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
Michael D. Schleif wrote about "Re: [leaf-devel] ML volume": > Add to d) leaf-general, or some such. If this is divvied up to fine, > then how will the generalists lend support? I have a feeling that nobody will subscribe to it. IMHO you need to make lists for branches which have big differences from each other. I see at least two: Bering and WISP-Dist. From what I understand Bering is mostly backwards compatible with Dachstein, so maybe same mailing list can be used for both Bering & Dachstein. -- Best Regards, Vladimir Systems Engineer (RHCE) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
On Sun, 2003-02-09 at 10:19, Michael D. Schleif wrote: > Mike Noyes wrote: > > On Sun, 2003-02-09 at 09:45, Mike Noyes wrote: > > > d) New LEAF release/branch specific MLs. > > > leaf-bering > > > leaf-dachstein > > > leaf-lince > > > leaf-oxygen > > > leaf-packetfilter > > > leaf-wisp-dist > > Add to d) leaf-general, or some such. Michael, Please explain how a general/discuss list would reduce traffic on leaf-user. > If this is divvied up to fine, > then how will the generalists lend support? Agreed. I have a couple of additional problems with the release/branch split above. It almost doubles my ML admin load. Second, once a list is created on SF it can't be removed or renamed. If we had used the release/branch solution from day one we would have two dead lists currently (leaf-eigerstein, leaf-wrp). > > e) Split leaf-user by adding > > leaf-user-new I'm not sure how much of a traffic reduction would be achieved by splitting new user questions to a new ML. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Light a candle, curse the glare (was: Re: [leaf-devel] ML volume)
Mike --
It would be easier to develop an (informed) opinion on this if we (or at
least I) knew a bit more about what causes you to bring it up as a concern.
There is a big difference between "some" users and "many" users, since
"some" people will be dissatisfied with any approach. (Consider, for
example, the recent TV commercial that featured a yuppie complaining about
the long line to see St. Peter at the Pearly Gates; consider also his fate
in that commercial ... "Express Elevator Down".)
We currently have 2 avenues for getting personalized support
("personalized" excludes reading FAQs and other docs, though we should
remember that those options exist too):
leaf-user
Sourceforge Support requests
One way to cut down list traffic would be to separate the two more cleanly,
so that Sourceforge Support messages did not also appear on leaf-user.
Personally, I'd favor that, if only because the format of these messages
makes them hard to respond to, even to read, on leaf-user.
Another would be to create a couple of low-volume lists: leaf-announce and
leaf-security. (Or do we already have these, just in moribund form?) Their
names tell you what I have in mind as their roles ... and their volume
should be on the order of a dozen message per month, typically. This way,
ongoing users could keep up with the bare necessities, while new users
could subscibe to leaf-user while they get up to speed, then unsubscribe
without being completely cut off.
All of that is a Baid-Aid, though. The real question that needs to be asked
is how the people who *answer* requests for help want to do it. That's
mainly the branch lead developers; a few branch-agnostic developers like
Lynn and Tom; and a couple of kibbitzers like me. (There are others too,
but this is the group that answers questions on a day-in-day-out basis.)
Each of us has to answer that question for him- or herself.
Personally, my interest here is in helping people who want to develop their
own skills and knowledge, people who will some day cross to the other side
of the line and become the next generation of developers, troubleshooters,
and the like. People like many of you here on leaf-devel. In contrast,
people who want only to consume Open Source software do not interest me as
much, and they can turn to paid sources of support, buy closed source
products like Linksys routers, or endure the inconvenience of having to
read (or delete) "too many" messages. This interest leads me to favor a
general list like leaf-user, which has the virtue of exposing its
subscribers to a wide range of LEAF and routing problems, not just offering
a source of free, personal tech support.
I don't intend here to impose my view on those of us with different
priorities ... I'm not even trying to argue for this view here, just to
state it clearly ... I merely want to make clear where my personal
preferences lie.
Branch-specific lists are an interesting possibility, but here too the
issue of who would *answer* the queries comes to the fore. (How many people
answer Sourgeforge Support requests now, for that matter? I only notice you
and Lynn, though, as I said, I don't read those messages regularly.) I
suspect Bering would transition nicely to this sort of system, and probably
Dachstein ... but I see very little traffic on leaf-user about the other
branches, and I mostly wonder who would be on those lists to answer
questions. Still, trying it would at least be (mostly) harmless, as long as
we kept the general leaf-user list in place as well, as a backup
(identifying it as such in an updated SR FAQ).
In closing, I do note that this "problem" is pervasive to support mailing
lists. I'm on maybe a dozen others, outside LEAF, and they all from time to
time get queries that ask for private or cc'd responses "because I'm not
subscribed to the list". Before we worry very much about it, we really do
need to convince ourselves that the existing approach causes us to lose
users we care about in more than trivial numbers.
At 09:45 AM 2/9/03 -0800, Mike Noyes wrote:
Everyone,
It has come to my attention that our leaf-user list volume is
discouraging some/many users from using it. We have a variety of options
to address this issue.
a) Keep things as they are.
b) NNTP support (news.gmane.org and/or nntp.sourceforge.net)
c) Web support (SF forums for each LEAF release/branch) (note: we
already use SF support trackers)
d) New LEAF release/branch specific MLs.
leaf-bering
leaf-dachstein
leaf-lince
leaf-oxygen
leaf-packetfilter
leaf-wisp-dist
Any suggestions, comments, or opinions are welcome.
--
---"Never tell me the odds!"
Ray Olszewski -- Han Solo
Palo Alto, California, USA [EMAIL PROTECTED]
---
---
Re: [leaf-devel] ML volume
On Sun, 2003-02-09 at 10:27, Vladimir I. wrote: > Michael D. Schleif wrote about "Re: [leaf-devel] ML volume": > > > Add to d) leaf-general, or some such. If this is divvied up to fine, > > then how will the generalists lend support? > > I have a feeling that nobody will subscribe to it. > > IMHO you need to make lists for branches which have big > differences from each other. I see at least two: Bering and > WISP-Dist. From what I understand Bering is mostly backwards > compatible with Dachstein, so maybe same mailing list can be used > for both Bering & Dachstein. Vladimir, If we decide to create release/branch specific lists, I will create one for each of our releases/branches. It's the only fair thing to do. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
Mike Noyes wrote: a) Keep things as they are. b) NNTP support (news.gmane.org and/or nntp.sourceforge.net) c) Web support (SF forums for each LEAF release/branch) (note: we already use SF support trackers) d) New LEAF release/branch specific MLs. leaf-bering leaf-dachstein leaf-lince leaf-oxygen leaf-packetfilter leaf-wisp-dist e) Split leaf-user by adding leaf-user-new f) phpBB 2.04, http://www.phpbb.com/ This is a web based forum system. A working example group that uses phpBB is http://forums.etree.org/ Regards, Matthew --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Light a candle, curse the glare (was: Re: [leaf-devel] MLvolume)
On Sun, 2003-02-09 at 10:39, Ray Olszewski wrote:
> It would be easier to develop an (informed) opinion on this if we (or at
> least I) knew a bit more about what causes you to bring it up as a concern.
> There is a big difference between "some" users and "many" users, since
> "some" people will be dissatisfied with any approach.
Ray,
One of our project members sent me a message off-list expressing a
concern over leaf-user list volume. I have no idea how many of our users
are affected by the volume on leaf-user. Any enlightenment on this is
appreciated.
> We currently have 2 avenues for getting personalized support
> ("personalized" excludes reading FAQs and other docs, though we should
> remember that those options exist too):
>
> leaf-user
> Sourceforge Support requests
>
> One way to cut down list traffic would be to separate the two more cleanly,
> so that Sourceforge Support messages did not also appear on leaf-user.
> Personally, I'd favor that, if only because the format of these messages
> makes them hard to respond to, even to read, on leaf-user.
I can make this change easily. We made the original change because SF
SRs were not being taken care of in a timely manner.
> Another would be to create a couple of low-volume lists: leaf-announce and
> leaf-security. (Or do we already have these, just in moribund form?) Their
> names tell you what I have in mind as their roles ... and their volume
> should be on the order of a dozen message per month, typically. This way,
> ongoing users could keep up with the bare necessities, while new users
> could subscibe to leaf-user while they get up to speed, then unsubscribe
> without being completely cut off.
We already have two lists that are rarely used (leaf-announce,
leaf-hardware).
> All of that is a Baid-Aid, though. The real question that needs to be asked
> is how the people who *answer* requests for help want to do it. That's
> mainly the branch lead developers; a few branch-agnostic developers like
> Lynn and Tom; and a couple of kibbitzers like me. (There are others too,
> but this is the group that answers questions on a day-in-day-out basis.)
> Each of us has to answer that question for him- or herself.
Agreed. That is why I posted the question to our devel list.
> Personally, my interest here is in helping people who want to develop their
> own skills and knowledge, people who will some day cross to the other side
> of the line and become the next generation of developers, troubleshooters,
> and the like. People like many of you here on leaf-devel. In contrast,
> people who want only to consume Open Source software do not interest me as
> much, and they can turn to paid sources of support, buy closed source
> products like Linksys routers, or endure the inconvenience of having to
> read (or delete) "too many" messages. This interest leads me to favor a
> general list like leaf-user, which has the virtue of exposing its
> subscribers to a wide range of LEAF and routing problems, not just offering
> a source of free, personal tech support.
I agree. The only new list that makes sense to me is a new user list.
> Branch-specific lists are an interesting possibility, but here too the
> issue of who would *answer* the queries comes to the fore. (How many people
> answer Sourgeforge Support requests now, for that matter? I only notice you
> and Lynn, though, as I said, I don't read those messages regularly.) I
> suspect Bering would transition nicely to this sort of system, and probably
> Dachstein ... but I see very little traffic on leaf-user about the other
> branches, and I mostly wonder who would be on those lists to answer
> questions. Still, trying it would at least be (mostly) harmless, as long as
> we kept the general leaf-user list in place as well, as a backup
> (identifying it as such in an updated SR FAQ).
Agreed.
> In closing, I do note that this "problem" is pervasive to support mailing
> lists. I'm on maybe a dozen others, outside LEAF, and they all from time to
> time get queries that ask for private or cc'd responses "because I'm not
> subscribed to the list". Before we worry very much about it, we really do
> need to convince ourselves that the existing approach causes us to lose
> users we care about in more than trivial numbers.
I'd like some additional feedback from our project members on the amount
of off-list traffic they're receiving.
--
Mike Noyes
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
On Sun, 2003-02-09 at 10:55, Matt Schalit wrote: > f) phpBB 2.04, http://www.phpbb.com/ > This is a web based forum system. A working example group that > uses phpBB is http://forums.etree.org/ Matt, Thanks for adding this option. However, we wont be able to implement it until phpWS 0.9x is released and I update our website. A phpBB module for phpWS 0.9x is in development. Alternately, we could use the SF provided forums. They even support nntp read and write through the SF nntp beta. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Package Repository
Charles Steinkuehler wrote: > Also, I see room for multiple versions of similar packages, and even > different versions of the same package. Hi, I split this off into a new thread just to quickly talk about something that's been on my mind for a bit. *Global Package Repository* I'll be really sad if we go down the road of multiple versions of the same package without a complete overhaul of our system for dribbling packages around the website. If a package works on more than 1 LEAF version, please, O' Magnificent Ones, let it be stored in a single global package repository. Somebody is really going to need some help to find all the hundred or so packages David D. has tucked away in his devel tree. And I won't go into the rest. You all know what it's like out there. It's not fair that we don't do some organization as part of our attempt at a new package system! But what delimits if a package will run on a LEAF version? Libc? Regards, Matthew --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
Mike Noyes wrote about "Re: [leaf-devel] ML volume": > Vladimir, > If we decide to create release/branch specific lists, I will create one > for each of our releases/branches. It's the only fair thing to do. Mike, depends on how you view it. If we treat mailing lists as some kind of benefits to the branch authors, then yes, we need to be fair and everybody should have the same benefits. I wouldn't treat them like that. I'd rather treat mailing lists as a tool for communication and their splitting as a way to reduce load on the readers. As for web-based forums - personally I don't like them because they're inconvinient. Especially considering that I have 500+ ms ping to Sourceforge. -- Best Regards, Vladimir Systems Engineer (RHCE) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
On Sun, 2003-02-09 at 10:16, Lynn Avants wrote: > On Sunday 09 February 2003 11:45 am, Mike Noyes wrote: > > > b) NNTP support (news.gmane.org and/or nntp.sourceforge.net) > > I like NNTP, but it doesn't necessarily address the volume problem at all. Lynn, Correct. It just provides another way to look at the posts. > > d) New LEAF release/branch specific MLs. > > leaf-bering > > leaf-dachstein > > leaf-lince > > leaf-oxygen > > leaf-packetfilter > > leaf-wisp-dist > > This would address the issue for most of the discouraged users, but > would be a real PITA for NNTP front-ends. Seperating the mailing-lists > this way might be the better route and make life easier for subscribers > of multiple lists IMHO. The question is how many people that provide support, like you, will join each list. A list that never receives replies to support requests isn't very useful. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Package Repository
On Sun, 2003-02-09 at 11:12, Matt Schalit wrote: > Charles Steinkuehler wrote: > > > Also, I see room for multiple versions of similar packages, and even > > different versions of the same package. > > > Hi, I split this off into a new thread just to quickly talk > about something that's been on my mind for a bit. > > *Global Package Repository* > > I'll be really sad if we go down the road of multiple versions > of the same package without a complete overhaul of our system > for dribbling packages around the website. Matt, This is being worked on. I need to finish my initial import of the glibc-2.0 tree. I can then add the package tree export to our daily.sh cron. Indexing will be part of this script. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/bin/packages/ daily.sh and index-pkg-html.sh http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/mhnoyes/sf-admin/ -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
On Sun, 2003-02-09 at 11:16, Vladimir I. wrote: > Mike Noyes wrote about "Re: [leaf-devel] ML volume": > > If we decide to create release/branch specific lists, I will create one > > for each of our releases/branches. It's the only fair thing to do. > > Mike, depends on how you view it. If we treat mailing lists as > some kind of benefits to the branch authors, then yes, we need to > be fair and everybody should have the same benefits. I wouldn't > treat them like that. I'd rather treat mailing lists as a tool > for communication and their splitting as a way to reduce load on > the readers. Vladimir, Right now I view them as a common communication medium. As soon as we attach release/branch names to MLs, I feel I have to treat them as a release/branch resource. > As for web-based forums - personally I don't like them because > they're inconvinient. Especially considering that I have 500+ ms > ping to Sourceforge. I agree. I'm especially concerned with diagnostic information (line wrapping, etc.). -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
On Sunday 09 February 2003 01:23 pm, Mike Noyes wrote: > On Sun, 2003-02-09 at 10:16, Lynn Avants wrote: > > On Sunday 09 February 2003 11:45 am, Mike Noyes wrote: > > > b) NNTP support (news.gmane.org and/or nntp.sourceforge.net) > > > > I like NNTP, but it doesn't necessarily address the volume problem at > > all. > > Lynn, > Correct. It just provides another way to look at the posts. The downside is that > > > d) New LEAF release/branch specific MLs. > > > leaf-bering > > > leaf-dachstein > > > leaf-lince > > > leaf-oxygen > > > leaf-packetfilter > > > leaf-wisp-dist > > > > This would address the issue for most of the discouraged users, but > > would be a real PITA for NNTP front-ends. Seperating the mailing-lists > > this way might be the better route and make life easier for subscribers > > of multiple lists IMHO. > > The question is how many people that provide support, like you, will > join each list. A list that never receives replies to support requests > isn't very useful. I guess that is what the developers/support personal need to state. Personally, I have grown to despise http-list and the associated front-ends having used them for several years. NNTP is fine with me, but very insecure for those running the servers via header forging. The last few nntp lists I was following have now gone to mail due to problems of this nature. Splitting the mailing-list allows the supporters/users to filter to a larger degree. However, if it is a single high-volume list, the problems remains the same. I don't see where a newleaf-user will make a large difference other than more cross-posting. -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
Mike Noyes wrote: > > On Sun, 2003-02-09 at 10:16, Lynn Avants wrote: > > On Sunday 09 February 2003 11:45 am, Mike Noyes wrote: > > > > > b) NNTP support (news.gmane.org and/or nntp.sourceforge.net) > > > > I like NNTP, but it doesn't necessarily address the volume problem at all. > > Lynn, > Correct. It just provides another way to look at the posts. > > > > d) New LEAF release/branch specific MLs. > > > leaf-bering > > > leaf-dachstein > > > leaf-lince > > > leaf-oxygen > > > leaf-packetfilter > > > leaf-wisp-dist > > > > This would address the issue for most of the discouraged users, but > > would be a real PITA for NNTP front-ends. Seperating the mailing-lists > > this way might be the better route and make life easier for subscribers > > of multiple lists IMHO. > > The question is how many people that provide support, like you, will > join each list. A list that never receives replies to support requests > isn't very useful. This is part of my point. And, previously: > It has come to my attention that our leaf-user list volume is > discouraging some/many users from using it. We have a variety of > options to address this issue. To be honest, I fail to see the magnitude of the problem. If somebody is going to install this stuff, then yank it because support involves a high volume list service, do we really care much about such people? How hard is it to subscribe to the list, ask questions, get the problem resolved and un-subscribe? Also, without a generic list, leaf-dachstein questions, for example, will lose out on bering, et al. subscribers' opinions. Frankly, I've saved all 24400+ posts from the last (3) years and do not consider this volume to be without value . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Light a candle, curse the glare (was: Re: [leaf-devel] ML volume)
Mike Noyes wrote about "Re: Light a candle, curse the glare (was: Re: [leaf-devel] ML volume)": > Ray, > One of our project members sent me a message off-list expressing a > concern over leaf-user list volume. I have no idea how many of our users No need to keep it secret - that developer was me. I receive about 50% of my support requests via e-mail. That's not much and the total traffic would be much lower than leaf-user's. However, I don't want to force those people to subscribe to the mailing list and at the same time I don't like to answer the same questions again. > > All of that is a Baid-Aid, though. The real question that needs to be asked > > is how the people who *answer* requests for help want to do it. That's > > mainly the branch lead developers; a few branch-agnostic developers like And the reason might be because knowledgeable users unsubscribe from the mailing lists due to lack of time to wade through high traffic. If the traffic would have been lower they would stay on the list and provide answers on a "day-in-day-out" basis. At least that's the case with me - in case of high traffic lists I usually just subscribe, send my question, wait for answers, and then leave. However, in case of low traffic lists, I usually don't mind staying and answering questions myself as time permits. > > Personally, my interest here is in helping people who want to develop their > > own skills and knowledge, people who will some day cross to the other side > > of the line and become the next generation of developers, troubleshooters, > > and the like. People like many of you here on leaf-devel. In contrast, > > people who want only to consume Open Source software do not interest me as > > much, and they can turn to paid sources of support, buy closed source > > products like Linksys routers, or endure the inconvenience of having to > > read (or delete) "too many" messages. This interest leads me to favor a > > general list like leaf-user, which has the virtue of exposing its > > subscribers to a wide range of LEAF and routing problems, not just offering > > a source of free, personal tech support. My reasons for publishing WISP-Dist were different, though. First is to share benefits that I get from Open Source software, and secondly, to help people roll out broadband access to Internet where it is not currently available. I agreed to join LEAF project because I hoped that it would help present WISP-Dist to a wider audience. I don't have a problem giving support to people who don't have a lot of free time or knowledge - if their questions are reasonable, of course. -- Best Regards, Vladimir Systems Engineer (RHCE) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Package Repository
On Sunday 09 February 2003 01:29 pm, Mike Noyes wrote: > Matt, > This is being worked on. I need to finish my initial import of the > glibc-2.0 tree. I can then add the package tree export to our daily.sh > cron. Indexing will be part of this script. In any respect, a link to the package-list/links on the php menu would prove most useful for many people. I often have a hard time finding the location of the list myself. -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
At 11:03 AM 2/9/03 -0800, Mike Noyes wrote: On Sun, 2003-02-09 at 10:39, Ray Olszewski wrote: > It would be easier to develop an (informed) opinion on this if we (or at > least I) knew a bit more about what causes you to bring it up as a concern. > There is a big difference between "some" users and "many" users, since > "some" people will be dissatisfied with any approach. Ray, One of our project members sent me a message off-list expressing a concern over leaf-user list volume. I have no idea how many of our users are affected by the volume on leaf-user. Any enlightenment on this is appreciated. Glad I asked, since my initial reaction was based on an incorrect guess about the source of the concern. Asuming the individual involved is the lead person on a branch, I'd very much recommand providing *that* branch with a separate leaf-something_or_other list and modifying (a) the SR FAQ and (b) that branch's main page within LEAF to refer questions there. More generally, I'd make this decision on a branch-by-branch basis, being guided by the lead developer's preference. Really, it need not be all or nothing here; "fairness" does not enter into it. A branch-specific list is a benefit to the developer only if he sees it that way; for some, it could be a nuisance. For example, some months ago, questions about a new, small-linux distro started turning up on the linux-newbie list. We regulars there were puzzled at first, until we found out that the distro's creator listed linux-newbie as the place for his users to post their questions. It actually worked pretty well, once we know what was going on. Clearly, *he* didn't want a distro-specific list, and some of our lead developers may feel the same way. But some might want one, so why not accommodate both preferences? [...] > One way to cut down list traffic would be to separate the two more cleanly, > so that Sourceforge Support messages did not also appear on leaf-user. > Personally, I'd favor that, if only because the format of these messages > makes them hard to respond to, even to read, on leaf-user. I can make this change easily. We made the original change because SF SRs were not being taken care of in a timely manner. Does sending them to leaf-user help? At least in my case, their format is so hard for me to read that I don't even look at them on the list, except occasionally on slow days. Do others respond to them by way of leaf-user? Is an alternative to disable the SF SR system? (It is even possible? Is it a good idea?) Or at least discourage its use on the LEAF Home Page (I can think offhand of one other project I follow that requests all bug reports go to its mailing list, for example, seemingly because this method is what the developer finds most convenient for him ... the best possible reason for doing it that way, especially as the developer is conscientious about responding to list traffic)? Other messages in this thread have suggested Web-based forums and the like. Personally, I am not enthusiastic. The virtue of e-mail-based mailing lists (for me) is that the traffic comes here for me to look at whenever I have a moment and the inclination. My replies go out promptly and easily (at least from my perspective ... the communicating MTAs handle any delays in ways invisible to me). A Web site is something I have to connect to separately ... at my convenience, yes, but the extra effort to do something outside my normal routine would make me less likely to remember. (There are some writers with Web sites I like, but I only remember to connect to them once a month or less.) It forces me to confront the performance limits of Sourceforge much more directly than I do with e-mail traffic. With any approach, its value to ordinary users -- the people who ask questions -- is that they get prompt, accurate, and helpful answers. The convenience of the mechanism to *them* is secondary to its being convenient for the people who give the answers. I suspect we would find a Web forum disappointing, for much the same reasons that the SF SR mechanism failed to deliver timely responses. -- ---"Never tell me the odds!" Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
> How hard is it to subscribe to the list, ask questions, get the problem > resolved and un-subscribe? I'd like to see consistant feedback from existing users, not only when they experience a problem. Because of this, I don't want them to unsubscribe. In order for that to happen, content of the mailing list should be of general interest to WISP-Dist users. -- Best Regards, Vladimir Systems Engineer (RHCE) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Light a candle, curse the glare (was: Re: [leaf-devel] ML volume)
"Vladimir I." wrote: > > Mike Noyes wrote about "Re: Light a candle, curse the glare (was: Re: [leaf-devel] >ML volume)": > > > Ray, > > One of our project members sent me a message off-list expressing a > > concern over leaf-user list volume. I have no idea how many of our users > > No need to keep it secret - that developer was me. I receive > about 50% of my support requests via e-mail. That's not much and > the total traffic would be much lower than leaf-user's. However, > I don't want to force those people to subscribe to the mailing > list and at the same time I don't like to answer the same > questions again. In such a case, you could start your own list -- yahoo groups come to mind -- and leaf-user requests can be deflected your way, similar to rcf, &c. -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
Ray Olszewski wrote: > > At 11:03 AM 2/9/03 -0800, Mike Noyes wrote: > >On Sun, 2003-02-09 at 10:39, Ray Olszewski wrote: > > > It would be easier to develop an (informed) opinion on this if we (or at > > > least I) knew a bit more about what causes you to bring it up as a > > concern. > > > There is a big difference between "some" users and "many" users, since > > > "some" people will be dissatisfied with any approach. > > > >Ray, > >One of our project members sent me a message off-list expressing a > >concern over leaf-user list volume. I have no idea how many of our users > >are affected by the volume on leaf-user. Any enlightenment on this is > >appreciated. > > Glad I asked, since my initial reaction was based on an incorrect guess > about the source of the concern. Me, too . . . > Asuming the individual involved is the lead person on a branch, I'd very > much recommand providing *that* branch with a separate > leaf-something_or_other list and modifying (a) the SR FAQ and (b) that > branch's main page within LEAF to refer questions there. More generally, > I'd make this decision on a branch-by-branch basis, being guided by the > lead developer's preference. > > Really, it need not be all or nothing here; "fairness" does not enter into > it. I second this motion . . . -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
Hello Mike Michael just expressed my thoughts :) > Also, without a generic list, leaf-dachstein questions, for example, > will lose out on bering, et al. subscribers' opinions. I also don't see so much of a problem in the number of mails, If I have time I read most of them, if I have only less time, I read those that interest me finltering on subjects. It would be a good idea if posts have the special flavor in their subjects as is done often. > Frankly, I've saved all 24400+ posts from the last (3) years and do not > consider this volume to be without value . . . I agree but did erase a lot of them, for the sake of the mta ;) Regarding your question about offlists posts, those are not very frequent for me. Mosts posts are in german so I keep them off the list and answer them offlist. Regards Eric Wolzak --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
On Sun, 2003-02-09 at 11:55, Ray Olszewski wrote: > At 11:03 AM 2/9/03 -0800, Mike Noyes wrote: > >One of our project members sent me a message off-list expressing a > >concern over leaf-user list volume. I have no idea how many of our users > >are affected by the volume on leaf-user. Any enlightenment on this is > >appreciated. > > Glad I asked, since my initial reaction was based on an incorrect guess > about the source of the concern. > > Asuming the individual involved is the lead person on a branch, I'd very > much recommand providing *that* branch with a separate > leaf-something_or_other list and modifying (a) the SR FAQ and (b) that > branch's main page within LEAF to refer questions there. More generally, > I'd make this decision on a branch-by-branch basis, being guided by the > lead developer's preference. > > Really, it need not be all or nothing here; "fairness" does not enter into > it. A branch-specific list is a benefit to the developer only if he sees it > that way; for some, it could be a nuisance. For example, some months ago, > questions about a new, small-linux distro started turning up on the > linux-newbie list. We regulars there were puzzled at first, until we found > out that the distro's creator listed linux-newbie as the place for his > users to post their questions. It actually worked pretty well, once we know > what was going on. Clearly, *he* didn't want a distro-specific list, and > some of our lead developers may feel the same way. But some might want one, > so why not accommodate both preferences? Everyone, Is this solution acceptable? If so, I'll create release/branch specific lists upon LEAF release/branch lead developer request. > >I can make this change easily. We made the original change because SF > >SRs were not being taken care of in a timely manner. > > Does sending them to leaf-user help? At least in my case, their format is > so hard for me to read that I don't even look at them on the list, except > occasionally on slow days. Do others respond to them by way of leaf-user? > > Is an alternative to disable the SF SR system? (It is even possible? Is it > a good idea?) Or at least discourage its use on the LEAF Home Page (I can > think offhand of one other project I follow that requests all bug reports > go to its mailing list, for example, seemingly because this method is what > the developer finds most convenient for him ... the best possible reason > for doing it that way, especially as the developer is conscientious about > responding to list traffic)? Ray, There are some people that are unable to configure their email client to post text/plain messages. Our current ML settings make it impossible for them to receive support. The only avenue available to them is the SF SR tracker. ref. partial admin response to non text/plain posts. Details: Only messages with a content-type of "text/plain" or "multipart/signed" are automatically posted to the list. All other content-types, and base64 encoded posts are held for administrative action. Alternate Support: If your employer attaches a footer to all outgoing mail that isn't text/plain, you may submit a support request using the LEAF Tracker [2]. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Light a candle, curse the glare (was: Re: [leaf-devel] ML volume)
On Sunday 09 February 2003 01:49 pm, Vladimir I. wrote: > My reasons for publishing WISP-Dist were different, though. > First is to share benefits that I get from Open Source software, > and secondly, to help people roll out broadband access to > Internet where it is not currently available. I agreed to join > LEAF project because I hoped that it would help present WISP-Dist > to a wider audience. I don't have a problem giving support to > people who don't have a lot of free time or knowledge - if their > questions are reasonable, of course. Personally, if I felt this way, I would set a filter or two to accept with a content of "wisp" or similar for the list(s). There aren't too many clients that won't do this if you don't feel like running procmail or a similar filtering program. I know that there will be considerable additional admin time spent with any option other than what is presently being used I would this depends on how many people find the traffic a problem. A change I would be happy to see is cutting the 'commits' messages off the /devel/user lists. If someone cares that can subscribe to the commits-list. -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: Light a candle, curse the glare (was: Re: [leaf-devel] MLvolume)
On Sun, 2003-02-09 at 11:59, Michael D. Schleif wrote: > "Vladimir I." wrote: > > No need to keep it secret - that developer was me. I receive > > about 50% of my support requests via e-mail. That's not much and > > the total traffic would be much lower than leaf-user's. However, > > I don't want to force those people to subscribe to the mailing > > list and at the same time I don't like to answer the same > > questions again. > > > > In such a case, you could start your own list -- yahoo groups come to > mind -- and leaf-user requests can be deflected your way, similar to > rcf, &c. Michael, I'd like to avoid any splintering. We worked to hard at getting everyone together in a central location. We all benefit from each other. I'm sure we can find a solution to this problem that is acceptable to Vladimir and consensus of our project members. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
On Sunday 09 February 2003 02:12 pm, Mike Noyes wrote: > On Sun, 2003-02-09 at 11:55, Ray Olszewski wrote: > > Really, it need not be all or nothing here; "fairness" does not enter > > into it. A branch-specific list is a benefit to the developer only if he > > sees it that way; for some, it could be a nuisance. For example, some > > months ago, questions about a new, small-linux distro started turning up > > on the linux-newbie list. We regulars there were puzzled at first, until > > we found out that the distro's creator listed linux-newbie as the place > > for his users to post their questions. It actually worked pretty well, > > once we know what was going on. Clearly, *he* didn't want a > > distro-specific list, and some of our lead developers may feel the same > > way. But some might want one, so why not accommodate both preferences? > > Everyone, > Is this solution acceptable? If so, I'll create release/branch specific > lists upon LEAF release/branch lead developer request. This would be acceptable with me. -- ~Lynn Avants Linux Embedded Firewall Project developer http://leaf.sourceforge.net --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
On Sun, 2003-02-09 at 12:12, Mike Noyes wrote: > On Sun, 2003-02-09 at 11:55, Ray Olszewski wrote: > > Asuming the individual involved is the lead person on a branch, I'd very > > much recommand providing *that* branch with a separate > > leaf-something_or_other list and modifying (a) the SR FAQ and (b) that > > branch's main page within LEAF to refer questions there. More generally, > > I'd make this decision on a branch-by-branch basis, being guided by the > > lead developer's preference. > > > > Really, it need not be all or nothing here; "fairness" does not enter into > > it. A branch-specific list is a benefit to the developer only if he sees it > > that way; for some, it could be a nuisance. For example, some months ago, > > what was going on. Clearly, *he* didn't want a distro-specific list, and > > some of our lead developers may feel the same way. But some might want one, > > so why not accommodate both preferences? > > Everyone, > Is this solution acceptable? If so, I'll create release/branch specific > lists upon LEAF release/branch lead developer request. +1 to Ray's solution. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Package Repository
On Sun, 2003-02-09 at 11:59, Lynn Avants wrote: > In any respect, a link to the package-list/links on the php menu would > prove most useful for many people. I often have a hard time finding the > location of the list myself. Lynn, Added to my to-do list. I thought I already placed a link to it on our Packages page. Apparently not. :-( Packages http://leaf-project.org/mod.php?mod=userpage&menu=10&page_id=3 -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
Mike Noyes wrote about "Re: [leaf-devel] ML volume": > > Everyone, > > Is this solution acceptable? If so, I'll create release/branch specific > > lists upon LEAF release/branch lead developer request. > > +1 to Ray's solution. You didn't count me in yet? :) -- Best Regards, Vladimir Systems Engineer (RHCE) --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
At 10:42 PM 2/9/03 +0200, Vladimir I. wrote: Mike Noyes wrote about "Re: [leaf-devel] ML volume": > > Everyone, > > Is this solution acceptable? If so, I'll create release/branch specific > > lists upon LEAF release/branch lead developer request. > > +1 to Ray's solution. You didn't count me in yet? :) Please count me as well as voting for what you generously call "Ray's solution". (Actually, I think I just articulated in short form what several people have been saying this morning a bit less directly.) -- ---"Never tell me the odds!" Ray Olszewski -- Han Solo Palo Alto, California, USA [EMAIL PROTECTED] --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
Mike Noyes wrote: Everyone, It has come to my attention that our leaf-user list volume is discouraging some/many users from using it. We have a variety of options to address this issue. a) Keep things as they are. b) NNTP support (news.gmane.org and/or nntp.sourceforge.net) c) Web support (SF forums for each LEAF release/branch) (note: we already use SF support trackers) d) New LEAF release/branch specific MLs. leaf-bering leaf-dachstein leaf-lince leaf-oxygen leaf-packetfilter leaf-wisp-dist Any suggestions, comments, or opinions are welcome. I personally find web forums and newsgroups much more difficult to manage than a simple e-mail list. If we switched to such a format, I for one would probably be heard from a lot less...not because of any change in desire to help, but just because it would be much more inconvinent to stay on top of current traffic without it piling up in my inbox as a reminder to go through it. :) While I think per-distribution lists might be a solution, I think all current LEAF flavors benifit from having a single list. I know I've answered questions from folks running Oxygen and Bering, and have seen users of other disto's answer questions relating to Dachstein. I would suggest an alternative option: Keep things as they are, but indicate the list is fairly high-traffic (so folks are not unplesently suprised). I also suggest pointing out the option of not subscribing to the list, but rather monitor one of the list archives for answers to their posts. Combined with the using "respond to all" when replying to list messages, this should be pretty workable. NOTE: Since the various list archives have tended to have less than amazing reliability and usefulness when searching, should we maybe try to setup our own searchable list archive? -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
On Sun, 2003-02-09 at 12:48, Ray Olszewski wrote: > At 10:42 PM 2/9/03 +0200, Vladimir I. wrote: > >Mike Noyes wrote about "Re: [leaf-devel] ML volume": > > > > Is this solution acceptable? If so, I'll create release/branch specific > > > > lists upon LEAF release/branch lead developer request. > > > > > > +1 to Ray's solution. > > > >You didn't count me in yet? :) > > Please count me as well as voting for what you generously call "Ray's > solution". (Actually, I think I just articulated in short form what several > people have been saying this morning a bit less directly.) Ray, Done. You deserve the credit, as I found your fairness example persuasive. Ray's solution: +5, -0 -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
On Sun, 2003-02-09 at 12:55, Charles Steinkuehler wrote: > I personally find web forums and newsgroups much more difficult to > manage than a simple e-mail list. If we switched to such a format, I > for one would probably be heard from a lot less...not because of any > change in desire to help, but just because it would be much more > inconvinent to stay on top of current traffic without it piling up in my > inbox as a reminder to go through it. :) Charles, Agreed. In any case forums if implemented wouldn't replace our MLs. They would be in addition to. > While I think per-distribution lists might be a solution, I think all > current LEAF flavors benifit from having a single list. I know I've > answered questions from folks running Oxygen and Bering, and have seen > users of other disto's answer questions relating to Dachstein. I now agree with Ray's position on this. This decision should be up to the release/branch lead developer. Personally, I like having all the user questions on one list. > I would suggest an alternative option: > Keep things as they are, but indicate the list is fairly high-traffic > (so folks are not unplesently suprised). I also suggest pointing out > the option of not subscribing to the list, but rather monitor one of the > list archives for answers to their posts. Combined with the using > "respond to all" when replying to list messages, this should be pretty > workable. > > NOTE: Since the various list archives have tended to have less than > amazing reliability and usefulness when searching, should we maybe try > to setup our own searchable list archive? Have you tried the search engine at MARC. Our lists are archived there now. I'm also looking at GMANE, but there are some MIME questions I have to answer first. http://marc.theaimsgroup.com/?l=leaf-cvs-commits&r=1&w=2 http://marc.theaimsgroup.com/?l=leaf-devel&r=1&w=2 http://marc.theaimsgroup.com/?l=leaf-hardware&r=1&w=2 http://marc.theaimsgroup.com/?l=leaf-user&r=1&w=2 If we get a valid post to leaf-announce this year, I'm sure it'll show up too. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] ML volume
On Sun, 2003-02-09 at 11:55, Ray Olszewski wrote: > At 11:03 AM 2/9/03 -0800, Mike Noyes wrote: > > > One way to cut down list traffic would be to separate the two more > > > cleanly, > > > so that Sourceforge Support messages did not also appear on leaf-user. > > > Personally, I'd favor that, if only because the format of these messages > > > makes them hard to respond to, even to read, on leaf-user. > > > >I can make this change easily. We made the original change because SF > >SRs were not being taken care of in a timely manner. > > Does sending them to leaf-user help? At least in my case, their format is > so hard for me to read that I don't even look at them on the list, except > occasionally on slow days. Do others respond to them by way of leaf-user? Ray, As I noted earlier, responding to our SF SRs is only possible via the SF.net LEAF project page. Support Requests https://sourceforge.net/tracker/?group_id=13751&atid=213751 > Is an alternative to disable the SF SR system? Everyone, I just disabled SR posting to our leaf-user list. I changed it to follow the same procedure our other trackers do. A single post to our leaf-devel list on new submissions. I hope I don't end up as the only person trying to answer these questions. -- Mike Noyes http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] [ leaf-Patches-683754 ] PXE.lrp-modifies standard distribution for PXE boot
Patches item #683754, was opened at 2003-02-09 23:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=313751&aid=683754&group_id=13751 Category: packages Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Cardwell (bignowhere) Assigned to: Nobody/Anonymous (nobody) Summary: PXE.lrp-modifies standard distribution for PXE boot Initial Comment: PXE.lrp transforms a LEAF Bering floppy disk into a collection of files that can be copied to a PXE boot server and be used to boot the router remotely, provided that the Bering router's internal network interface and BIOS support the PXE standard. The package provides modified versions of several scripts and of the 'busybox' binary, adding support for TFTP to enable boot image backups from the Bering router back to the boot server. The transformation is carried out by an interactive script, 'makepxe.' When booting via PXE, the Bering router is not required to include disk drives of any kind. Temporary package backups are done to a ramdisk and permanent backups are done by transferring an updated boot image from the Bering router back to the boot server via TFTP. The file PXE.TGZ includes glibc-pxe.lrp and uclibc-pxe.lrp to support both library versions of Bering. Also, a very brief readme.pxe is included, with a more substantial document to follow later. This is the very first release of this package. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=313751&aid=683754&group_id=13751 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
