You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Colm MacCarthaigh <co...@stdlib.net> on 2006/04/19 18:59:48 UTC
[VOTE] 2.0.57 candidate
Candidate tarballs for 2.0.57 are now available for testing/voting at;
http://httpd.apache.org/dev/dist/
This doesn't include a changed notice-of-license text though, which is a
potential open issue.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [VOTE] 2.0.57 candidate
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Colm MacCarthaigh wrote:
>
> My preference is similar, I'd prefer to ship 2.0.57 as it is now rather
> than either confuse the whole process by introducing another candidate.
> So, unless people revert their votes for release, we can release the
> present candidate very shortly after 2.2.2.
Something occured to me Friday, but the very late date of Jim's proposed
1.3.35 tarball makes this possibly unrealistic... wouldn't it make more
sense only to broadcast a single Announcement message (perhaps, next friday)
to make it completely clear to the outside communities when 2.2.2 is released,
that there are updates to 2.0.57 and 1.3.35 for users of this legacy software?
Roy's framed the question (paraphrasing) why the heck continue to release 2.0
versions? Long answer, as long as it gets votes/attention from the community,
but my personal answer is whenever 2.2.x is what we say it is, "the best
version available". The moment the bugtraq system and user reports clearly
document that 2.2.x is 'as stable' as 2.0.x, I'm all for mostly dumping it.
I'd also like to see us dump 1.3 in the not-so-distant future, but again, it's
all about how long those stable releases have communities.
Bill
Re: [VOTE] 2.0.57 candidate
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Fri, Apr 21, 2006 at 10:31:25PM -0500, William A. Rowe, Jr. wrote:
> Appears to be Colm's choice of 1. nothing extra, 2. revert date
> changes/reroll, or 3. revert date changes (w/ any other changes he
> wishes), bump and reroll. That's my preference, in descending order,
> but support whichever he chooses.
My preference is similar, I'd prefer to ship 2.0.57 as it is now rather
than either confuse the whole process by introducing another candidate.
So, unless people revert their votes for release, we can release the
present candidate very shortly after 2.2.2.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [VOTE] 2.0.57 candidate
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Roy T. Fielding wrote:
> On Apr 21, 2006, at 10:39 AM, William A. Rowe, Jr. wrote:
>
>> For the sanity of all the rest of us project members, let us
>> please work from documented policy though, can we? And feh - let's just
>> have done with this tarball release and revisit once policy is *set*.
>
> FTR, we are not going to vote on legal policy. The board will vote,
> if anyone. Legal policies are not a PMC thing. I implement them as
> needed or directed by the board.
Ack, +1. (voting to not be voting :)
> I don't really care about the nit (it is present in the existing
> header text). It is just something I noticed while implementing
> the changes for Jackrabbit.
+1 and thank you for the observation.
>> I don't concur with Colm, the tarball is the release and changing the legal
>> text is more significant, perhaps, than even the code itself. So it's yet
>> another bump that strikes me as silly.
>
> *shrug* version numbers are cheap. I thought we only required them
> to change if the compiled bits would change or if the release was
> already announced.
Thanks for clarifying your position, as you were the only one I was thinking of
(still around these parts) who argued tag x.y.z -> tarball x.y.z is involitile.
So if this is your position, then I guess there is no reason not to retain the
number, if this is what Colm wants to do.
Appears to be Colm's choice of 1. nothing extra, 2. revert date changes/reroll,
or 3. revert date changes (w/ any other changes he wishes), bump and reroll.
That's my preference, in descending order, but support whichever he chooses.
Thanks again for all the detailed comments Roy. With a Board policy in place,
we stand ready to resolve this. In the interim, we can <eot> the subject.
Cool.
Bill
Re: [VOTE] 2.0.57 candidate
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Apr 21, 2006, at 10:39 AM, William A. Rowe, Jr. wrote:
> -1 to adopting Jackrabbits' license until Roy's (very reasonable)
> nit on the
> language is addressed. -1 to removing copyright until we have an
> absolute,
> documented policy from ASF legal. I'm glad you and Roy feel
> entirely assured
> that you speak for legal/privy to its workings and, of course, its
> final
> conclusions. For the sanity of all the rest of us project members,
> let us
> please work from documented policy though, can we? And feh - let's
> just
> have done with this tarball release and revisit once policy is *set*.
FTR, we are not going to vote on legal policy. The board will vote,
if anyone. Legal policies are not a PMC thing. I implement them as
needed or directed by the board.
I don't really care about the nit (it is present in the existing
header text). It is just something I noticed while implementing
the changes for Jackrabbit.
> I don't concur with Colm, the tarball is the release and changing
> the legal
> text is more significant, perhaps, than even the code itself. So
> it's yet
> another bump that strikes me as silly.
*shrug* version numbers are cheap. I thought we only required them
to change if the compiled bits would change or if the release was
already announced.
....Roy
License text in source files [Re: [VOTE] 2.0.57 candidate]
Posted by Sander Temme <sc...@apache.org>.
On Apr 21, 2006, at 10:51 AM, Justin Erenkrantz wrote:
> We can not make statements in the code that we know to be inaccurate.
> Once you decided to open this can of worms, we must resolve it before
> publishing a release. -- justin
So, basically, we're dead in the water until we develop and apply the
appropriate license text?
That means no releases can be made on any branch until this issue is
resolved?
Or would we be OK with:
a) reverting the mass change (r395235 on 2.0.x, r395231 on 2.2.x,
r395229, r395228 on trunk, looks like Jim already took care of 1.3,
what am I missing?)
b) Dredge svn for files updated during the current year and change
the notice accordingly
c) Re-roll
?
That would get us moving forward again. We can then wait for guidance
from the board/legal.
S.
Re: [VOTE] 2.0.57 candidate
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/21/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> How is this a showstopper? As has been pointed out, your comments are late
> to the table, and this certainly isn't a change in existing practice, and
> most certainly doesn't invalidate the (initial and appropriate) copyrights.
Bah. I posted my complaint against changing the years within 12 hours
of your initial post.
We can not make statements in the code that we know to be inaccurate.
Once you decided to open this can of worms, we must resolve it before
publishing a release. -- justin
Re: [VOTE] 2.0.57 candidate
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Fri, Apr 21, 2006 at 12:39:12PM -0500, William A. Rowe, Jr. wrote:
> I don't concur with Colm, the tarball is the release and changing the legal
> text is more significant, perhaps, than even the code itself. So it's yet
> another bump that strikes me as silly.
Just to be clear, I didn't mean it that way. I was going to start an
explicit vote on the mailing list for changing the notice-of-license
text, accross all branches and future releases, for the sake of
efficiency and clarity.
But in the last few minutes even more options have emerged that make me
question if it's that's sensible, as there's no consensus on what
options to vote on.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [VOTE] 2.0.57 candidate
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Justin Erenkrantz wrote:
> On 4/19/06, Colm MacCarthaigh <co...@stdlib.net> wrote:
>
>>Candidate tarballs for 2.0.57 are now available for testing/voting at;
>>
>> http://httpd.apache.org/dev/dist/
>>
>>This doesn't include a changed notice-of-license text though, which is a
>>potential open issue.
>
> I'm -1 due to the copyright notice changes. A bunch of files
> magically added years to copyright notices (i.e. from -2004 to -2006)
> when those files didn't actually substantively change during that
> period. That's a no-no.
How is this a showstopper? As has been pointed out, your comments are late
to the table, and this certainly isn't a change in existing practice, and
most certainly doesn't invalidate the (initial and appropriate) copyrights.
-1 to adopting Jackrabbits' license until Roy's (very reasonable) nit on the
language is addressed. -1 to removing copyright until we have an absolute,
documented policy from ASF legal. I'm glad you and Roy feel entirely assured
that you speak for legal/privy to its workings and, of course, its final
conclusions. For the sanity of all the rest of us project members, let us
please work from documented policy though, can we? And feh - let's just
have done with this tarball release and revisit once policy is *set*.
I don't concur with Colm, the tarball is the release and changing the legal
text is more significant, perhaps, than even the code itself. So it's yet
another bump that strikes me as silly.
Bill
Re: [VOTE] 2.0.57 candidate
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/21/06, Colm MacCarthaigh <co...@stdlib.net> wrote:
> We know that now, but those commits went through before it became so
> clear that our previous practise was so wrong.
The entire email exchange happened while the US West Coasters were
asleep. I sent an email saying, "Don't do that" as soon as I saw the
thread the next morning. But, the commits had already been made by
then based on false conceptions about what our practice was.
> > Let's just add Jackrabbit's disclaimer and be done with the whole year
> > thing forever. The best thing of course would be to not have done
> > anything at all (<g>); but that train left the station when all of
> > those commits got made prematurely...
>
> o.k., I think we can change the notice without a version bump too and
> without erasing the existing votes, since it's a non-code change, but
> we should probably have a clear vote on changing the notice, I'll start
> one now :)
We should probably do a version bump, but at a minimum, the votes do go away.
*shrug* -- justin
Re: [VOTE] 2.0.57 candidate
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Fri, Apr 21, 2006 at 10:21:18AM -0700, Justin Erenkrantz wrote:
> I'm -1 due to the copyright notice changes. A bunch of files
> magically added years to copyright notices (i.e. from -2004 to -2006)
> when those files didn't actually substantively change during that
> period. That's a no-no.
We know that now, but those commits went through before it became so
clear that our previous practise was so wrong.
> Let's just add Jackrabbit's disclaimer and be done with the whole year
> thing forever. The best thing of course would be to not have done
> anything at all (<g>); but that train left the station when all of
> those commits got made prematurely...
o.k., I think we can change the notice without a version bump too and
without erasing the existing votes, since it's a non-code change, but
we should probably have a clear vote on changing the notice, I'll start
one now :)
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: [VOTE] 2.0.57 candidate
Posted by Sander Temme <sc...@apache.org>.
On Apr 21, 2006, at 10:21 AM, Justin Erenkrantz wrote:
> Let's just add Jackrabbit's disclaimer and be done with the whole year
> thing forever. The best thing of course would be to not have done
> anything at all (<g>); but that train left the station when all of
> those commits got made prematurely... -- justin
Can't we just revert that commit?
S.
Re: [VOTE] 2.0.57 candidate
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 4/19/06, Colm MacCarthaigh <co...@stdlib.net> wrote:
>
> Candidate tarballs for 2.0.57 are now available for testing/voting at;
>
> http://httpd.apache.org/dev/dist/
>
> This doesn't include a changed notice-of-license text though, which is a
> potential open issue.
I'm -1 due to the copyright notice changes. A bunch of files
magically added years to copyright notices (i.e. from -2004 to -2006)
when those files didn't actually substantively change during that
period. That's a no-no.
Let's just add Jackrabbit's disclaimer and be done with the whole year
thing forever. The best thing of course would be to not have done
anything at all (<g>); but that train left the station when all of
those commits got made prematurely... -- justin
Re: [VOTE] 2.0.57 candidate
Posted by Jim Jagielski <ji...@jaguNET.com>.
Passes perl test framework and others on:
Sol8/Sparc, OS X 10.4.6, Suse 9.2, Suse 10.0
+1
On Apr 19, 2006, at 12:59 PM, Colm MacCarthaigh wrote:
>
> Candidate tarballs for 2.0.57 are now available for testing/voting at;
>
> http://httpd.apache.org/dev/dist/
>
> This doesn't include a changed notice-of-license text though, which
> is a
> potential open issue.
>
> --
> Colm MacCárthaigh Public Key: colm
> +pgp@stdlib.net
>
Re: [VOTE] 2.0.57 candidate
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/19/2006 at 10:59:48 am, in message
<20...@dochas.stdlib.net>, Colm MacCarthaigh
<co...@stdlib.net>
wrote:
> Candidate tarballs for 2.0.57 are now available for testing/voting
at;
>
> http://httpd.apache.org/dev/dist/
>
> This doesn't include a changed notice-of-license text though, which
is a
> potential open issue.
+1 NetWare
Brad
Reverting my vote [was: Re: [VOTE] 2.0.57 candidate]
Posted by Sander Temme <sc...@apache.org>.
On Apr 20, 2006, at 3:34 PM, Sander Temme wrote:
> +1 for release on Ubuntu/x86, FreeBSD 6-STABLE/x86, Darwin/PPC.
Sorry, I think we should re-roll with the reverted copyright
statements. Since the code is the same and no one reported any
technical problems, the new vote should be pretty swift.
-1 for release.
S.
--
sctemme@apache.org http://www.temme.net/sander/
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: [VOTE] 2.0.57 candidate
Posted by Sander Temme <sc...@apache.org>.
On Apr 19, 2006, at 9:59 AM, Colm MacCarthaigh wrote:
> Candidate tarballs for 2.0.57 are now available for testing/voting at;
>
> http://httpd.apache.org/dev/dist/
>
> This doesn't include a changed notice-of-license text though, which
> is a
> potential open issue.
Linux sarlacc 2.6.12-10-686 #1 Sat Mar 11 16:22:51 UTC 2006 i686 GNU/
Linux (Ubuntu Breezy)
worker:
All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 10 tests and
12 subtests skipped.
Files=75, Tests=2804, 131 wallclock secs (61.51 cusr + 7.70 csys =
69.21 CPU)
prefork:
All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 10 tests and
12 subtests skipped.
Files=75, Tests=2806, 131 wallclock secs (61.15 cusr + 7.98 csys =
69.13 CPU)
FreeBSD bagheera.sandla.org. 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE
#2: Wed Mar 22 10:13:16 PST 2006 sctemme@bagheera.sandla.org.:/
usr/obj/usr/src/sys/GENERIC i386
prefork:
Hangs on test 2 of t/protocol/nntp-like. It does this for both the
drop and trunk.
Darwin Graymalkin.local 8.6.0 Darwin Kernel Version 8.6.0: Tue Mar 7
16:58:48 PST 2006; root:xnu-792.6.70.obj~1/RELEASE_PPC Power
Macintosh powerpc
PGP signatures and MD5 checksums validate for both gz and bz2 drops.
prefork:
All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 10 tests and
12 subtests skipped.
Files=75, Tests=2802, 273 wallclock secs (80.68 cusr + 30.37 csys =
111.05 CPU
worker:
All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 10 tests and
12 subtests skipped.
Files=75, Tests=2800, 313 wallclock secs (82.10 cusr + 31.01 csys =
113.11 CPU)
Given that the hang on FreeBSD 6 "STABLE" occurs for both this drop
and trunk, and the unexpected success may be a stale "todo" test in
the t/modules/include suite:
+1 for release on Ubuntu/x86, FreeBSD 6-STABLE/x86, Darwin/PPC.
S.