From: <se...@ci...> - 2001-01-30 21:16:07
|
+------ TJ Saunders wrote (Tue, 3-Oct-30, 1:26 +0000): | | jss>I have contacted Johnie Ingram regarding the two above. He was, | jss>ummm .., not-commitant. :( That means I'll probably be pulling | jss>mod_sqlpw and friends. | | Hmmm...is there any way to _not_ pull those modules? I know of at least | one proftpd-developer willing to help maintain those in some capacity, and | we can pitch in, too. I think quite a few proftpd users use those SQL | databases for non-system authentication information, and probably logging. | I'd hate to deprive them of some nifty functionality. I have to agree with TJ here. My impression from list traffic is that mod_sqlpw and friends are deployed at a lot of sites, and it would disappoint many to have them pulled altogether. Better to leave them in and label them "unsupported, use at your own risk" and include a list of known bugs and/or BugIDs. Afterall, they are not included in the default build. The virtual-user feature is mandatory for some sites. Maybe they can be fixed sometime between rc3 and -final. *If* I had either mysql or postgres installed and the consequent experience, I might consider jumping on it myself. But, ... <cynical>A threat to pull them included with the known bugs list might help smoke out someone who depends on mod_sqlpw to fix it.</cynical> Best, Chuck -- Charles Seeger <se...@ci...> |
From: Jesse S S. <js...@in...> - 2001-02-27 18:39:27
|
On Tue, Feb 27, 2001 at 11:35:09AM -0500, Charles Seeger wrote: > Policy question: should a question like this be on the core list > or the proftpd-devel list? I am cc:'ing this to -devel. I'm not going to get into what seems to essentially be a private conversation between you and TJ, let me just state that I feel it is important to avoid making assumptions about where final code should go or will lie, when a "roadmap" for 1.3 has not really been established at all (although with pre-1.3 cvs, I have started that task). Basically, what I am saying is "let's not get the cart before the horse." One of the first things I would like to see is some casual documentation w.r.t. the API, the distribution layout (filesystem-wise) and some pseudo-code. I'm currently working on this sort of thing, and you'll see my work show up in pre-1.3. I would like to invite *everyone* to look at the pre-1.3 cvs, specifically at libpr, which is a general-purpose library that I intend to use in 1.3. I would welcome any comments and/or tweaks (the core team should all have commit to this repository, if you don't please let me know). The library is essentially complete, with the notable exception of logging channels, which I intend to add very soon. Anonymous CVS information: export CVSROOT=:pserver:ano...@cv...:/var/cvs/proftpd cvs login p: proftpd cvs checkout pre-1.3 -- "In the event of a failure, the system can be configured to automatically restart itself. This feature of Windows NT Server provides maximum system up-time." -- Reliability and Fault Tolerance in Windows NT Server, MSC |
From: <se...@ci...> - 2001-04-02 22:36:15
|
+------ TJ Saunders wrote (Mon, 2-Apr-01, 21:39 +0000): | | seeger>For merely displaying the versions of modules to humans, a scheme | seeger>based on rcsid variables should be sufficient. It would even be nice | seeger>insofaras ident and what would be able to display useful information. | | I dunno...I tend to check in and out _many_ versions of my modules, | as I develop, test, and debug them, before I release them under a given | version number...I'd feel a little uncomfortable having mod_wrap display | version 1.19 (RCS version) instead of 1.2 (my released version number). | YMMV. YMMV, too. Just use the release tag, i.e. $Name$: static const char rcsid[] = "@(#)$Id$"; static const char rcsname[] = "@(#)$Name$"; One could massage then rcsname, based on whatever convention is in use, before printing it. Strictly speaking, one might want to have the rcs* variables incremented by four to skip over the sccs magic string "@(#)", for which the what program searches. Or, just skip over it when printing. Best, Chuck -- Charles Seeger <se...@ci...> |
From: TJ S. <tj...@di...> - 2001-04-02 23:02:43
|
seeger>YMMV, too. Just use the release tag, i.e. $Name$: seeger> seeger> static const char rcsid[] = seeger> "@(#)$Id$"; seeger> static const char rcsname[] = seeger> "@(#)$Name$"; seeger> seeger>One could massage then rcsname, based on whatever convention seeger>is in use, before printing it. *sheepish grin* Umm...I didn't think of that. Good idea. =) TJ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Everywhere one seeks to produce meaning, to make the world signify, to render it visible. We are not, however, in danger of lacking meaning; quite the contrary, we are gorged with meaning and it is killing us. -Jean Baudrillard ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
From: Jesse S S. <js...@in...> - 2001-01-30 21:25:48
|
On Tue, Jan 30, 2001 at 04:16:00PM -0500, Charles Seeger wrote: > +------ TJ Saunders wrote (Tue, 3-Oct-30, 1:26 +0000): > | > | jss>I have contacted Johnie Ingram regarding the two above. He was, > | jss>ummm .., not-commitant. :( That means I'll probably be pulling > | jss>mod_sqlpw and friends. > | > | Hmmm...is there any way to _not_ pull those modules? I know of at least > | one proftpd-developer willing to help maintain those in some capacity, and > | we can pitch in, too. I think quite a few proftpd users use those SQL > | databases for non-system authentication information, and probably logging. > | I'd hate to deprive them of some nifty functionality. > > I have to agree with TJ here. My impression from list traffic is that > mod_sqlpw and friends are deployed at a lot of sites, and it would > disappoint many to have them pulled altogether. Better to leave them > in and label them "unsupported, use at your own risk" and include a > list of known bugs and/or BugIDs. Afterall, they are not included in > the default build. The virtual-user feature is mandatory for some sites. > Maybe they can be fixed sometime between rc3 and -final. *If* I had > either mysql or postgres installed and the consequent experience, > I might consider jumping on it myself. But, ... > > <cynical>A threat to pull them included with the known bugs list might > help smoke out someone who depends on mod_sqlpw to fix it.</cynical> Actually, that was my secret hope. ;) Pull 'em from rc3 and that will cause enough anguish to flush out those hiding developers! -- "In the event of a failure, the system can be configured to automatically restart itself. This feature of Windows NT Server provides maximum system up-time." -- Reliability and Fault Tolerance in Windows NT Server, MSC |
From: The F. H. <ha...@vo...> - 2001-01-31 10:08:00
|
On Tue, Jan 30, 2001 at 04:25:42PM -0500, Jesse S Sipprell wrote: > On Tue, Jan 30, 2001 at 04:16:00PM -0500, Charles Seeger wrote: > > +------ TJ Saunders wrote (Tue, 3-Oct-30, 1:26 +0000): [... the pulling of sql support ...] > > <cynical>A threat to pull them included with the known bugs list might > > help smoke out someone who depends on mod_sqlpw to fix it.</cynical> > > Actually, that was my secret hope. ;) Pull 'em from rc3 and that will cause > enough anguish to flush out those hiding developers! If we're pulling them from rc3 then we need to make sure the modules are still available from other sources and that the dropping of them (and reason) is clearly announced Mark .. I can see the list traffic now :/ -- The Flying Hamster <ha...@su...> http://hamster.wibble.org/ If you can't join them, beat them - Lockley, Season 5, B5 |