Quoting "Jeffrey C. Ollie" <jeff@xxxxxxxxxxxxxxxxx>: > On Thu, 2004-02-19 at 14:37, Timothy A. Chagnon wrote: > > > > My LUG (TriLUG) has a forge that we could use. The guys said it's still > > a bit beta, but we can try it out. http://forge.trilug.org It would > > allow us to have our own mailing list, CVS, etc. The trilug admins are > > _very_ knowledgeable and anything we had trouble with, we could probably > > get help pretty quickly. Also, I can post a message to the TriLUG list > > to recruit some people if necessary. I registered a project for us, so > > we can start playing with it. I'll post here again when the project is > > accepted. > > Hmm... Am I the lone voice for using Subversion for source code control? > If everyone else is committed to using CVS, I'll go along, but I was > really hoping to use Subversion. > > Also, as far as mailing lists go, I was hoping to keep discussion on the > fedora-config-list. I think that'll keep visibility higher, and > potentially attract more developers. > Third time I've tried to post. Every time Evolution crashes in the middle of writing a letter, I feel less and less like I have anything to say. :) Now I just compose in a simple text editor and cut and paste. I agree that keeping the discussion on this list is the best idea. Brent told me the same thing back when I started getting involved. This list has very low volume, and a relatively small group of readers, so it should be fine. It also makes for a very easy way for others not working on the project to keep track of our progress and offer suggestions/help. I have a couple of servers at ServerBeach running FC1, and I already have subversion server running on one of them. We *could* use it if we wanted to, I was just checking to see if anyone had a better idea. My server is hosted in a "bomb shelter", so it has 100% uptime, high bandwidth, a stable connection, and redundant everything. Sure beats DSL. Our best bet is the public Fedora CVS server, once they get around to setting it up, but mine works well too. I had a look at your parsing code and I'm quite impressed at how thorough it is. Granted, I can't get it to run on my machine for some dumb reason, but I'll try and work that out. Here's some of my thoughts about coding: Our interface should be "compliant" and all that: check http://fedora.redhat.com/participate/developers-guide/ for some basics. Particularly important is the Gnome HIG. [ http://developer.gnome.org/projects/gup/hig/1.0/ ]. Of course, you all know that :) I haven't seen any official fedora-python coding conventions listed, so if any of you have seen anything, let me know. For now, though, we ought to be good just following the same style as s-c-network and up2date. Make it clean, document your functions, and use existing libraries for things like command- line parameter parsing. As far as rule parsing is concerned, here's a few things to keep in mind: * We should be liberal in what we accept as far as rule symantics are concerned. We can never be totally certain that what we don't know how to parse is an invalid rule. If someone comes up with a new firewall module, the iptables firewall rule is very likely where that module's configuration will go. When we can't parse a rule, we ought to let the user know, but I'm not sure we should do anything drastic like mangle it or throw it out. On the other hand, if we try to re-insert an invalid rule back into the kernel, it will barf reject the whole ruleset--something to avoid. So... Maybe we should validate the rules and display a warning if we don't understand them before sending them off to the kernel. * Rules technically only have to be parsed if they're going to be modified or examined. A rule *can* be read in and written back without any examination at all, for whatever that's worth. Granted, it might be best to parse once on read, but then again, it might also be best to parse on-demand. I'm not sure what all the implications of either method may be. * Remember that the "native* format for any parameters is text--we read it in as text, and we write it out as text. Once again, I'm not sure what the best method to use here is, but when we take a parameter (such as an IP address) and convert it into its numeric representation for internal storage rather than its textual representation, we're introducing an extra step and increasing the complexity of our application. Now, if we're going to do any numeric comparisions using the address, we have to have it in numeric form, so that step is necessary. I guess what I'm saying here is that we have to decide which parameters should be "transparent" (e.g. numeric form) , and which ones should be "opaque" (e.g. textual form). Making parameters transparent allows for greater flexibility, but introduces more opportunity for error. Leaving them opaque reduces the chance of error and bugs, but it less useful. My original concept application used one-time parsing of parameters (i.e. classifying the "chunks" of a rule), but relied on on-demand interpretation of parameters (i.e. converting textual addresses to numeric ones). I don't know if that's the best way to do things, but I figured it would be best to bring up the issue and let people think about it. Cheers -tylerl