Re: httpd-2.0/apr/apr-util Code Freeze
greg et al, just to let you know. i just had to set up, here, a second partial tag, this time quite a significant rewrite of my database modules and the way they're being used in the project i'm doing. i tagged just the db.py, monitord.py and sql2000xmldb.py files. i then found whoops, a bug in the monitord.py file that needed correcting in both cvs main _and_ the tagged version. so i corrected it in both - making sure that it _was_ exactly the same correction in both. the file monitord.py _does_ also contain other modifications. after performing a merge into cvs main with cvs update -j dualdbdesign, guess what? no conflicts. the only conflicts i get are in db.py where i forgot that i had renamed a function in one file and added extra arguments to the original _not_ renamed function. ... which is exactly the sort of thing you really _do_ need to catch as a conflict! and during this time, guess what? cvs main remained useable at all times. if i had been asked to perform a demonstration or to perform a release at any time, i would have been confident enough to say no problem, immediately. hope this helps. 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: httpd-2.0/apr/apr-util Code Freeze
surely that's not too much process to cause more pain than the benefits are worth, neh? There is a lot of resistance to using tags and branches the way you suggest Luke. okay: i have to admit - i made a mistake in oversimplifying what i suggested [full branching of an entire sub-tree of code]. I believe it has already received a -1 on this list at some point, but I would have to look. There are a lot of people who would agree with you that branching is a good thing, we just need to figure out how to address the concerns that other people have. _full_ branching, especially for prolonged periods of time, is something that... well... let's just say that i have a _personal_ interest in letting other projects know what i think about the disadvantages of branching projects, and leave it at that. which is why i am advocating this usage of cvs tags that i have definitely not seen in day-to-day usage in any projects, anywhere. heck, i even heard of a company that purchased a commercial source control program because they didn't know that cvs could tag / branch individual files like this, and it had never occurred to them to do partial tagging. so, sorry for misleading people with the earlier post: i am most _definitely_ NOT, repeat, NOT, advocating the use of _full_ [i.e. recursive-into-directories] cvs tag / branching. full tag/branching gets you nowhere as you end up on _exactly_ the same slippery slope, but just under a different name, _and_ you have a full merging headache afterwards. the whole point of partial tagging is that the developer does twin-checkouts and day-to-day compilation tests. one of the cvs main and one of the combined-cvs-main-and-their-partial-tagged-files-that-they-are-working-on. i will be very surprised if anyone has proposed this before, and if they have, i would be interested to hear the reasons why it was not considered. 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: httpd-2.0/apr/apr-util Code Freeze
sorry: this suggestion - a full tagging of an entire project - was a mistake. i repeat, i am NOT advocating that the use of branching like this is a good idea. in fact, it is an extremely dangerous one. imo. luke On Sat, 10 Mar 2001, Luke Kenneth Casson Leighton wrote: On Fri, 9 Mar 2001, Greg Stein wrote: I don't think it has anything to do with mechanics, nor will throwing more process at the problem fix it. (more process will simply bog down what we can accomplish) ...? if nothing else: cd apr cvs tag -b apr_dev [needs recursive option] cd .. mkdir apr_dev; cd !$ cvs co -r apr_dev apr cd .. mkdir httpd_combined; cd !$ cvs co httpd rm -fr apr mv ../apr_dev apr this assumes that the apr library is in httpd/apr, which it probably isn't, it's probably in httpd/src. the same process applies to if you want to use the version of apr that's already in httpd, except you do: rm -fr httpd/apr cvs co -r apr_dev httpd/apr No... the problem is about perception. The rate of change recently has just been quite high. It just isn't very conceivable to make a release in that environment. ... ah, that's different. _however_ :) once you _get_ to the point where cvs main is always-releasable, then using this multi-tag process could help make cvs main _remain_ always-releasable. for, as you described - some significant modifications to mod_include could be done in a dev_mod_include_rewrite tag, and only when completed are they cvs merged into cvs main. surely that's not too much process to cause more pain than the benefits are worth, neh? *shrug* :) 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... - 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: httpd-2.0/apr/apr-util Code Freeze
I don't think it has anything to do with mechanics, nor will throwing more process at the problem fix it. (more process will simply bog down what we can accomplish) No... the problem is about perception. The rate of change recently has just been quite high. It just isn't very conceivable to make a release in that environment. The other side of the coin is what the result of the tag/roll is. We had some slight problems in the Windows .mak files. OtherBill went and patched those up, and created a new zip file. Do we know the quality? No, but we know it (at least) builds. So we ought to just toss it out there as alpha. Believing it to be more than alpha is also a bit alarming. We *just* fixed some serious problems in the C-L filter, and had some pretty big work in mod_include. Cheers, -g On Fri, Mar 09, 2001 at 02:28:51AM +1100, Luke Kenneth Casson Leighton wrote: 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... -- Greg Stein, http://www.lyra.org/
Re: httpd-2.0/apr/apr-util Code Freeze
On Sat, 10 Mar 2001, Luke Kenneth Casson Leighton wrote: On Fri, 9 Mar 2001, Greg Stein wrote: I don't think it has anything to do with mechanics, nor will throwing more process at the problem fix it. (more process will simply bog down what we can accomplish) ...? if nothing else: cd apr cvs tag -b apr_dev [needs recursive option] cd .. mkdir apr_dev; cd !$ cvs co -r apr_dev apr cd .. mkdir httpd_combined; cd !$ cvs co httpd rm -fr apr mv ../apr_dev apr this assumes that the apr library is in httpd/apr, which it probably isn't, it's probably in httpd/src. the same process applies to if you want to use the version of apr that's already in httpd, except you do: rm -fr httpd/apr cvs co -r apr_dev httpd/apr No... the problem is about perception. The rate of change recently has just been quite high. It just isn't very conceivable to make a release in that environment. ... ah, that's different. _however_ :) once you _get_ to the point where cvs main is always-releasable, then using this multi-tag process could help make cvs main _remain_ always-releasable. for, as you described - some significant modifications to mod_include could be done in a dev_mod_include_rewrite tag, and only when completed are they cvs merged into cvs main. surely that's not too much process to cause more pain than the benefits are worth, neh? There is a lot of resistance to using tags and branches the way you suggest Luke. I believe it has already received a -1 on this list at some point, but I would have to look. There are a lot of people who would agree with you that branching is a good thing, we just need to figure out how to address the concerns that other people have. Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: httpd-2.0/apr/apr-util Code Freeze
On Fri, Mar 09, 2001 at 06:54:29AM -0800, [EMAIL PROTECTED] wrote: On Sat, 10 Mar 2001, Luke Kenneth Casson Leighton wrote: On Fri, 9 Mar 2001, Greg Stein wrote: I don't think it has anything to do with mechanics, nor will throwing more process at the problem fix it. (more process will simply bog down what we can accomplish) ...? if nothing else: [ scheme described at Advogato ] ... No... the problem is about perception. The rate of change recently has just been quite high. It just isn't very conceivable to make a release in that environment. ... ah, that's different. _however_ :) Saw that coming :-) once you _get_ to the point where cvs main is always-releasable, then using this multi-tag process could help make cvs main _remain_ always-releasable. We only need it releasable when we want to release :-) Seriously, the general policy is do your best to keep it compiling and working, but we understand that sometimes things simply break. We have about a half dozen active committers, and things tend to work out fine (no stepping on toes). We haven't really need any long term branching, but I do know a couple cases where it would have been nice. for, as you described - some significant modifications to mod_include could be done in a dev_mod_include_rewrite tag, and only when completed are they cvs merged into cvs main. surely that's not too much process to cause more pain than the benefits are worth, neh? It actually has some pretty big pain because of the merge problem. CVS has horrible merging issues :-). Let's say that you had to grab some stuff from HEAD and pull it into dev_mod_include_rewrite. Say, because some of the code *around* you has changed, so you need the compensating changes from HEAD into your branch. Later on, you go to merge a reasonable stable form of the branch back into HEAD, but all those bits you pulled over get reapplied back to HEAD, generating a bunch of conflicts. You bitch, fix them, then check in the new HEAD. You continue some more work on the branch. You're finally done, so you go to merge it back onto HEAD. Now you're really screwed. Pretty much the entire set of changes causes conflicts because CVS doesn't record that you already merged a good portion of the branch onto the HEAD. It is a pain in the ass. There is a lot of resistance to using tags and branches the way you suggest Luke. I believe it has already received a -1 on this list at some point, but I would have to look. There are a lot of people who would agree with you that branching is a good thing, we just need to figure out how to address the concerns that other people have. I don't know if a -1 occurred, but I'd certainly consider a negative vote quite strongly (veto? dunno). The merge problem is just a pain in the ass. Personally, I'd just state that we don't worry about the problem. Subversion has *very* easy branching. And it records information about merges, so you won't see the problems above. I'm presuming we'll want to switch to SVN for any number of excellent reasons, and that would bring along a much better branch/merge capability. Cheers, -g -- Greg Stein, http://www.lyra.org/
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: 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: httpd-2.0/apr/apr-util Code Freeze
There are a couple of bugs in the STATUS file that I started hunting today. Can we shoot for a tarball roll of sometime on Thursday or Friday? I agree, the no-freeze model just doesn't work in this environment. Ryan On Wed, 7 Mar 2001, William A. Rowe, Jr. wrote: Folks, I'm going to propose something radical. Although Jeff's recent commit points out a potentially serious problem (discrepancy between the file size and file offset types) in the Win32 APR, which I will look at today, this server appears rather stable, and buildable, and rbb will have 'the patch' today for our OS2 woes (see - cross platform development actually carries benefits!) Can we begin a code freeze, excepting _minor_ build and code fixes, until we have a stable tarball ready to share? I have win32 folks trying to make apache2.0a9 build, this just doesn't make any sense. Once Ryan's patch is in, let's roll, and then go back to town. It's been too long, time for a good tarball! I increasingly believe that a pure implementation of Roy's model can't work. Either 1) code freezes, 2) dev/release branches, or 3) parallel trees [I hate #3] seem required to allow development to progress while folks shoot down bugs. Bill ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: httpd-2.0/apr/apr-util Code Freeze
william, the apache project is, i assume, suffering from the effects of many developers using cvs at the same time? if so, can i recommend reading the description of how to ease the pain of #3 below, described in http://advogato.org/article/247.html it outlines how to use cvs to do one or more simultaneous cvs branches on sub-sections of a codebase. i.e. how to use a cvs tag for a small sub-section of the codebase and to use _another_ cvs tag for the rest. simple example: one developer wishes to try out a new memory manager replacement for apr_pool.c, where this may have a massive impact if carried out in cvs main, plus if they tag the entire cvs repository to do it, _they_ get out-of-date. so they tag _only_ the files that are modified by their experiment, and pull in all the rest from cvs main. the same procedure can be applied simultaneously by many developers, each doing their Own Thing. and the idea is that you can _always_ do a tarball / release at any time, because the developers are expected to do a cvs update -j 'mydevelopmenttag' / code-merge once they have proved that their work is stable, and not before - without a really good reason. am also giving serious consideration to writing a script to be run on cvs commits that uses keynote - requiring that cvs commits be digitally signed off by at least two developers / reviewers. but that's another story :) luke On Wed, 7 Mar 2001, William A. Rowe, Jr. wrote: It's been too long, time for a good tarball! I increasingly believe that a pure implementation of Roy's model can't work. Either 1) code freezes, 2) dev/release branches, or 3) parallel trees [I hate #3] seem required to allow development to progress while folks shoot down bugs. Bill - 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: httpd-2.0/apr/apr-util Code Freeze
William A. Rowe, Jr. [EMAIL PROTECTED] writes: Can we begin a code freeze, excepting _minor_ build and code fixes, until we have a stable tarball ready to share? I have win32 folks trying to make apache2.0a9 build, this just doesn't make any sense. Once Ryan's patch is in, let's roll, and then go back to town. I think that whoever plans to tag/roll should suggest a target time (e.g., Friday noon PST) as well as a timeframe for soft freeze (only build fixes and minor code fixes welcome for 16 hours prior to target??). A hard freeze right around the tag is expected. Part of this was implied in your earlier note (you anticipated that Ryan would commit a fix sometime today and we'd tag/roll later today). Now that Ryan suggests Thursday or Friday I wonder when you want a freeze. I don't want a freeze now if we don't tag/roll until Friday afternoon. Thanks... -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
