Re: httpd-2.0/apr/apr-util Code Freeze
I agree, the no-freeze model just doesn't work in this environment. The no-freeze model hasn't even been tested in this environment. It is necessary for the code to be in a stable state in order to do a release at any time, regardless of a freeze. At no time in the past six months has the code been in a stable state, regardless of how many times you have called for and implemented a freeze. The code isn't going to get any better if you prevent people from fixing the problems. What has happened over the past month is is that some of the things that need doing which require more than a few hours effort to get right are actually being done, because we don't have to worry about someone else's arbitrary notion of a release date. I have no intention of stopping that now just because some people get their panties in a bind. If you want to create a release based on an ongoing frantic development tree, all you have to do is selectively tag the repository to include only those revisions that you consider to be stable. There is no rule that requires the entire HEAD to be tagged at once, and there is nothing wrong with moving tags from one revision to another within CVS *provided* that such moves are made before a tarball based on that tag is released. Roy
Re: cvs commit: apr-util aprutil.mak libaprutil.mak
wrowe 01/03/07 21:37:35 Modified:.aprutil.mak libaprutil.mak Log: Forgot to use the fixwin32mak.pl magic Revision ChangesPath 1.7 +8 -8 apr-util/aprutil.mak @@ -810,12 +810,12 @@ !IF $(CFG) == aprutil - Win32 Release apr - Win32 Release : - cd \clean\httpd-2.0\srclib\apr + cd ..\..\srclib\apr $(MAKE) /$(MAKEFLAGS) /F .\apr.mak CFG=apr - Win32 Release cd ..\apr-util apr - Win32 ReleaseCLEAN : - cd \clean\httpd-2.0\srclib\apr + cd ..\..\srclib\apr $(MAKE) /$(MAKEFLAGS) CLEAN /F .\apr.mak CFG=apr - Win32 Release\ RECURSE=1 cd ..\apr-util This bit won't be going away. I'm wondering, if someone wants to hack the magic httpd-2.0\build\fixwin32mak.pl, I'd imagine there has to be a simple one line way to make the inner ..\srclib\ simply disappear, since both are in the srclib\ tree. Of course, it's easier just to run that from apr-util\build (it isn't duplicated over there right now, but could/should be) I'm just thinking that an apr-util/apr user isn't necessarily building from httpd-2.0/srclib. Bill
Re: cvs commit: apr/user/unix userinfo.c
On 8 Mar 2001, Jeff Trawick wrote: [EMAIL PROTECTED] writes: Allow a way to get the password from the system password database. Non unix platforms will likely need a similar function. Submitted by: John Barbee [EMAIL PROTECTED] How useful is this? It certainly isn't portable. Even some UNIX platforms cannot have such a function. Even with Linux, what happens with shadow passwords? You'll get x back for the password, though certainly that is not the encrypted password. If the goal is to validate a password, it is more portable to define a function which does that. Pass it a userid and password and let it tell the caller whether or not it worked. I think the strategy behind this needs to be reworked, and a new function with different semantics provided instead of a function to try to grab the password. Of course, you are correct this isn't very portable. However, with a bit of time and effort, and can be made portable. John has discovered exactly what you say in this message, and he will be working on making this much more portable in the next few days. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: httpd-2.0/apr/apr-util Code Freeze
create a release based on an ongoing frantic development tree, all you have to do is selectively tag the repository to include only those revisions that you consider to be stable. There is no rule that requires the entire HEAD to be tagged at once, and there is nothing wrong with moving tags from one revision to another within CVS *provided* that such moves are made before a tarball based on that tag is released. roy, sounds like you already appreciate the need for partial / selective tagging. the difference between what you propose and what i propose is that the _developers_ must use - on a daily basis - selective / partial tagging - _not_ the release manager. then and _only_ then can this rule be applied and be more confident to work: no developer shall commit code to cvs main if it don't work / ain't stable. of course, you can't fix all the bugs, and you can't forsee what might happen if two developers do two cvs merges simultaneously from two of their partial-cvs-tags, but we have that already on a smaller-scale on a per-file basis: you can't forsee what might happen if two developers fix the same problem in the same file in different ways! that's the trade-off you get with concurrent versioning. luke - Luke Kenneth Casson Leighton [EMAIL PROTECTED] - i want a world of dreams, run by near-sighted visionaries good. that's them sorted out. now, on _this_ world...
Re: cvs commit: apr/user/unix userinfo.c
[EMAIL PROTECTED] writes: Of course, you are correct this isn't very portable. However, with a bit of time and effort, and can be made portable. John has discovered exactly what you say in this message, and he will be working on making this much more portable in the next few days. It would be helpful to see his plans before it is committed, as I need to add special code to validate a password on OS/390. (John? Care to briefly describe your plans here?) For now I will put in a hack to keep that file compiling on OS/390 (no pw_passwd field). -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
Linux
Does someone have a linux box (with a linux that has sendfile) that I can borrow an account on to check some code before I commit it? Ta. david
