You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2001/03/07 17:36:29 UTC
httpd-2.0/apr/apr-util Code Freeze
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
Re: httpd-2.0/apr/apr-util Code Freeze
Posted by Jeff Trawick <tr...@bellsouth.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> 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 | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: httpd-2.0/apr/apr-util Code Freeze
Posted by Jeff Trawick <tr...@bellsouth.net>.
"William A. Rowe, Jr." <wr...@rowe-clan.net> 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 | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: httpd-2.0/apr/apr-util Code Freeze
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
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 <lk...@samba-tng.org> -----
"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
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
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 <lk...@samba-tng.org> -----
"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
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> ... i've worked in long-term branches.
>
> i do not recommend it.
afterthought. just to clarify, the above sentence is a serious
understatement.
luke
----- Luke Kenneth Casson Leighton <lk...@samba-tng.org> -----
"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
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> ... i've worked in long-term branches.
>
> i do not recommend it.
afterthought. just to clarify, the above sentence is a serious
understatement.
luke
----- Luke Kenneth Casson Leighton <lk...@samba-tng.org> -----
"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
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > > _however_ :)
>
> Saw that coming :-)
oh, darn :)
> > > 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.
... i've worked in long-term branches.
i do not recommend it.
> > > 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.
yep. and that is why i do not advocate the use of full branching. when
this is extended to a whole bunch of files over a prolonged period of
time, the risks of these kinds of conflicts goes beyond acceptable limits.
the "partial tagging" is therefore a recommended method to help avoid
exactly this nightmare scenario.
the scenario you describe would tend to imply the following things:
1) a different developer is responsible for the file mentioned, under both
versions (HEAD and the hypothetical/example dev_mod_include_rewrite),
where the two developers are not coordinating on modifications to the same
file.
2) the file contains such different functionality that different
developers, over long periods of time, tend to modify it for different
purposes. this implies that the file should really be broken into two
separate files, and one of those files will be partially tagged, and the
other will not. i describe this in the article, already.
the point of the partial tag is that is targetted at a specific
development area, allowing all other area to remain "current" instead of
"static" [i.e. from the time of the "full" branch, which we already know
is a bad idea].
the need to do cross-merging, if it can be avoided, means that at the end
of the partial-tag's lifetime, you can do this, in cvs main:
cvs update -j "partial_tag_name".
and _that's it_.
i suspect that this may even work even if you have performed modifications
in the same files, and you make _Absolutely_ sure that the overlapping
areas are identical (including whitespace).
then, cvs will detect that you already have those changes and will reject
them "cleanly".
which will leave you only with the conflict areas to resolve which you
will actually _genuinely_ need to resolve, not spurious ones.
e.g. whilst writing a new version of apr_pool.c, someone also decided to
fix a bug in hte cvs main apr_pool.c, or added an extra argument to one of
the apr_pool.c functions and so did you, but they were different
arguments.
now, the intersting thing about this particular example is that this
simply would not occur [okay, it might: see below].
why?
because when someone added an extra argument to a function in the
apr_pool.c code in cvs main's apr_pool.c, they would start to modify all
usages of this function, right?
now, assuming that the apr_pool_tagger_developer has not partial-tagged
all of the same files [which he probably would, if adding an extra
but different argument, as well, to the same function] then once the cvs
main commit had occurred, then he would pick up all of these cvs main
files on his next cvs update, and his partial-tag build would break.
_that's_ the whole point of doing partial tagging: to catch things in this
way. so that the tag-developer can stay current with everything-else. and
if that means a little bit of pain for just a few files, then so be it,
that's far better than a _lot_ of pain at the end of a merge!
and you most certainly would _not_ catch this with full tagging, which is
why i am so against full tagging, myself.
> Personally, I'd just state that we don't worry about the problem. Subversion
> has *very* easy branching.
ah, yes. i almost forgot. sbv is using apr :)
hi people, hope you're taking this stuff on-board: i really hope that you
can help avoid the nasties of full branching :)
all best,
luke
----- Luke Kenneth Casson Leighton <lk...@samba-tng.org> -----
"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
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > > _however_ :)
>
> Saw that coming :-)
oh, darn :)
> > > 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.
... i've worked in long-term branches.
i do not recommend it.
> > > 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.
yep. and that is why i do not advocate the use of full branching. when
this is extended to a whole bunch of files over a prolonged period of
time, the risks of these kinds of conflicts goes beyond acceptable limits.
the "partial tagging" is therefore a recommended method to help avoid
exactly this nightmare scenario.
the scenario you describe would tend to imply the following things:
1) a different developer is responsible for the file mentioned, under both
versions (HEAD and the hypothetical/example dev_mod_include_rewrite),
where the two developers are not coordinating on modifications to the same
file.
2) the file contains such different functionality that different
developers, over long periods of time, tend to modify it for different
purposes. this implies that the file should really be broken into two
separate files, and one of those files will be partially tagged, and the
other will not. i describe this in the article, already.
the point of the partial tag is that is targetted at a specific
development area, allowing all other area to remain "current" instead of
"static" [i.e. from the time of the "full" branch, which we already know
is a bad idea].
the need to do cross-merging, if it can be avoided, means that at the end
of the partial-tag's lifetime, you can do this, in cvs main:
cvs update -j "partial_tag_name".
and _that's it_.
i suspect that this may even work even if you have performed modifications
in the same files, and you make _Absolutely_ sure that the overlapping
areas are identical (including whitespace).
then, cvs will detect that you already have those changes and will reject
them "cleanly".
which will leave you only with the conflict areas to resolve which you
will actually _genuinely_ need to resolve, not spurious ones.
e.g. whilst writing a new version of apr_pool.c, someone also decided to
fix a bug in hte cvs main apr_pool.c, or added an extra argument to one of
the apr_pool.c functions and so did you, but they were different
arguments.
now, the intersting thing about this particular example is that this
simply would not occur [okay, it might: see below].
why?
because when someone added an extra argument to a function in the
apr_pool.c code in cvs main's apr_pool.c, they would start to modify all
usages of this function, right?
now, assuming that the apr_pool_tagger_developer has not partial-tagged
all of the same files [which he probably would, if adding an extra
but different argument, as well, to the same function] then once the cvs
main commit had occurred, then he would pick up all of these cvs main
files on his next cvs update, and his partial-tag build would break.
_that's_ the whole point of doing partial tagging: to catch things in this
way. so that the tag-developer can stay current with everything-else. and
if that means a little bit of pain for just a few files, then so be it,
that's far better than a _lot_ of pain at the end of a merge!
and you most certainly would _not_ catch this with full tagging, which is
why i am so against full tagging, myself.
> Personally, I'd just state that we don't worry about the problem. Subversion
> has *very* easy branching.
ah, yes. i almost forgot. sbv is using apr :)
hi people, hope you're taking this stuff on-board: i really hope that you
can help avoid the nasties of full branching :)
all best,
luke
----- Luke Kenneth Casson Leighton <lk...@samba-tng.org> -----
"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
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Mar 09, 2001 at 06:54:29AM -0800, rbb@covalent.net 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
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Mar 09, 2001 at 06:54:29AM -0800, rbb@covalent.net 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
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
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 <lk...@samba-tng.org> -----
>
> "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 <lk...@samba-tng.org> -----
"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
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
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 <lk...@samba-tng.org> -----
>
> "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 <lk...@samba-tng.org> -----
"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
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > 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 <lk...@samba-tng.org> -----
"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
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> > 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 <lk...@samba-tng.org> -----
"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
Posted by rb...@covalent.net.
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 rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: httpd-2.0/apr/apr-util Code Freeze
Posted by rb...@covalent.net.
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 rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: httpd-2.0/apr/apr-util Code Freeze
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
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 <lk...@samba-tng.org> -----
"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
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
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 <lk...@samba-tng.org> -----
"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
Posted by Greg Stein <gs...@lyra.org>.
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 <lk...@samba-tng.org> -----
>
> "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
Posted by Greg Stein <gs...@lyra.org>.
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 <lk...@samba-tng.org> -----
>
> "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
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> 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 <lk...@samba-tng.org> -----
"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
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
> 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 <lk...@samba-tng.org> -----
"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
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> 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
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> 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
Posted by Luke Kenneth Casson Leighton <lk...@samba-tng.org>.
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 <lk...@samba-tng.org> -----
"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
Posted by rb...@covalent.net.
I'm tagging and rolling right now. The tree currently builds on Windows
and Linux, and I believe based on Jeff's recent commits, I have to believe
that it compiles everyplace else. It also works on OS/2 and BeOS AFAIK.
Tag and roll coming in the next hour or so.
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 rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: httpd-2.0/apr/apr-util Code Freeze
Posted by rb...@covalent.net.
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 rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: httpd-2.0/apr/apr-util Code Freeze
Posted by rb...@covalent.net.
I'm tagging and rolling right now. The tree currently builds on Windows
and Linux, and I believe based on Jeff's recent commits, I have to believe
that it compiles everyplace else. It also works on OS/2 and BeOS AFAIK.
Tag and roll coming in the next hour or so.
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 rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: httpd-2.0/apr/apr-util Code Freeze
Posted by rb...@covalent.net.
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 rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------