[VOTE] Release Regexp 1.5

Hi All,

With 5 recent bug fixes [1], one *major* speed improvement for {m,n} closures
[2], with other various optimizations to compiler and runtime, and with previous
release published sometime back in 2005 [3], now is the best, or at the very
least, really good time to to cut next, 1.5 release of the venerable Jakarta
Regexp package.

Please try out current svn (r517970) version [4] and test for any regressions,
and vote for a release. Regexp test suite can be run by issuing 'ant test' in
the checkout directory, and does not take even 3 seconds to complete.
Interactive testing can be done by using applet version [5].

The only known incompatibility with Regexp 1.4 is that pre-compiled RE programs
created with 'recompile' utility [6] for patterns containing reluctant closures
are not compatible with trunk. But, that should not be a problem since they did
not work correctly before anyway [7].

My vote for the release is +1.

Thanks,
Vadim

[1] http://jakarta.apache.org/regexp/changes.html
[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=9153
[3] http://marc.info/?l=jakarta-regexp-dev&m=112429683615736
[4] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/
[5] http://jakarta.apache.org/regexp/applet.html
[6]
http://svn.apache.org/repos/asf/jakarta/regexp/trunk/src/jav a/org/apache/regexp/recompile.java
[7] http://issues.apache.org/bugzilla/show_bug.cgi?id=27763

Re: [VOTE] Release Regexp 1.5

Hm,

I hate to spoil you here but according to a recent board discussion,
some discussion on private@velocity and a completely botched release
attempt in Velocity land:

You actually have to roll and sign a tarball/zip ball on which the vote
happens. "Release-then-Vote" seems to be the only accepted way by the
board these days; personally I do prefer "Vote-then-Release" myself but
that seems to be the way it is.

On the release itself I'm +1, on the procedure I prefer to abstain. :-)

Best regards
Henning



On Tue, 2007-03-13 at 22:12 -0400, Vadim Gritsenko wrote:
> Hi All,
>
> With 5 recent bug fixes [1], one *major* speed improvement for {m,n} closures
> [2], with other various optimizations to compiler and runtime, and with previous
> release published sometime back in 2005 [3], now is the best, or at the very
> least, really good time to to cut next, 1.5 release of the venerable Jakarta
> Regexp package.
>
> Please try out current svn (r517970) version [4] and test for any regressions,
> and vote for a release. Regexp test suite can be run by issuing 'ant test' in
> the checkout directory, and does not take even 3 seconds to complete.
> Interactive testing can be done by using applet version [5].
>
> The only known incompatibility with Regexp 1.4 is that pre-compiled RE programs
> created with 'recompile' utility [6] for patterns containing reluctant closures
> are not compatible with trunk. But, that should not be a problem since they did
> not work correctly before anyway [7].
>
> My vote for the release is +1.
>
> Thanks,
> Vadim
>
> [1] http://jakarta.apache.org/regexp/changes.html
> [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=9153
> [3] http://marc.info/?l=jakarta-regexp-dev&m=112429683615736
> [4] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/
> [5] http://jakarta.apache.org/regexp/applet.html
> [6]
> http://svn.apache.org/repos/asf/jakarta/regexp/trunk/src/jav a/org/apache/regexp/recompile.java
> [7] http://issues.apache.org/bugzilla/show_bug.cgi?id=27763
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux, |gls
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau
Open Source Consulting, Development, Design | Velocity - Turbine guy |rwc
|m k
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n

Re: [VOTE] Release Regexp 1.5

Henning Schmiedehausen wrote:
> Hm,
>
> I hate to spoil you here but according to a recent board discussion,
> some discussion on private@velocity and a completely botched release
> attempt in Velocity

My condolences to you...


> land:
>
> You actually have to roll and sign a tarball/zip ball on which the vote
> happens. "Release-then-Vote" seems to be the only accepted way by the
> board these days;

Thankfully, neither events in velocity-private nor board feelings apply here.
Either Jakarta PMC votes for it or receives an resolution, before that happens,
existing procedures [1] stay.


> personally I do prefer "Vote-then-Release" myself but
> that seems to be the way it is.

Agree. Doing otherwise is putting carriage before the horse. The closest I can
do to satisfy old ladies drinking tea is this "rc" trunk build [2]. Of course
those are not the files to be distributed: to get those, I actually would have
to do release first. And that would put me in catch 22 situation. Hence these RC
builds have to suffice.


> On the release itself I'm +1, on the procedure I prefer to abstain. :-)

Thanks! Now need one more before starting tagging. Also I think I need to update
headers as per [3], is that correct?

Vadim

[1] http://jakarta.apache.org/commons/releases/release.html
[2] http://people.apache.org/~vgritsenko/regexp/
[3] http://www.apache.org/legal/src-headers.html


> Best regards
> Henning
>
>
>
> On Tue, 2007-03-13 at 22:12 -0400, Vadim Gritsenko wrote:
>> Hi All,
>>
>> With 5 recent bug fixes [1], one *major* speed improvement for {m,n} closures
>> [2], with other various optimizations to compiler and runtime, and with previous
>> release published sometime back in 2005 [3], now is the best, or at the very
>> least, really good time to to cut next, 1.5 release of the venerable Jakarta
>> Regexp package.
>>
>> Please try out current svn (r517970) version [4] and test for any regressions,
>> and vote for a release. Regexp test suite can be run by issuing 'ant test' in
>> the checkout directory, and does not take even 3 seconds to complete.
>> Interactive testing can be done by using applet version [5].
>>
>> The only known incompatibility with Regexp 1.4 is that pre-compiled RE programs
>> created with 'recompile' utility [6] for patterns containing reluctant closures
>> are not compatible with trunk. But, that should not be a problem since they did
>> not work correctly before anyway [7].
>>
>> My vote for the release is +1.
>>
>> Thanks,
>> Vadim
>>
>> [1] http://jakarta.apache.org/regexp/changes.html
>> [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=9153
>> [3] http://marc.info/?l=jakarta-regexp-dev&m=112429683615736
>> [4] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/
>> [5] http://jakarta.apache.org/regexp/applet.html
>> [6]
>> http://svn.apache.org/repos/asf/jakarta/regexp/trunk/src/jav a/org/apache/regexp/recompile.java
>> [7] http://issues.apache.org/bugzilla/show_bug.cgi?id=27763

Re: [VOTE] Release Regexp 1.5

On 14/03/07, Vadim Gritsenko wrote:
> Henning Schmiedehausen wrote:
> > Hm,
> >
> > I hate to spoil you here but according to a recent board discussion,
> > some discussion on private@velocity and a completely botched release
> > attempt in Velocity
>
> My condolences to you...
>
>
> > land:
> >
> > You actually have to roll and sign a tarball/zip ball on which the vote
> > happens. "Release-then-Vote" seems to be the only accepted way by the
> > board these days;
>
> Thankfully, neither events in velocity-private nor board feelings apply here.
> Either Jakarta PMC votes for it or receives an resolution, before that happens,
> existing procedures [1] stay.
>
>
> > personally I do prefer "Vote-then-Release" myself but
> > that seems to be the way it is.
>
> Agree. Doing otherwise is putting carriage before the horse. The closest I can
> do to satisfy old ladies drinking tea is this "rc" trunk build [2]. Of course
> those are not the files to be distributed: to get those, I actually would have
> to do release first. And that would put me in catch 22 situation. Hence these RC
> builds have to suffice.
>
>
> > On the release itself I'm +1, on the procedure I prefer to abstain. :-)
>
> Thanks! Now need one more before starting tagging. Also I think I need to update
> headers as per [3], is that correct?

You also need a NOTICE file [3]

The LICENSE and NOTICE files ought to go into the jar as well, as the
jar may well be used on its own.

License should be LICENSE [3]

> Vadim
>
> [1] http://jakarta.apache.org/commons/releases/release.html
> [2] http://people.apache.org/~vgritsenko/regexp/

It would be nice if the MD5 files used the more standard format:

9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip

so that MD5 tools can process the file automatically.


> [3] http://www.apache.org/legal/src-headers.html
>
>
> > Best regards
> > Henning
> >
> >
> >
> > On Tue, 2007-03-13 at 22:12 -0400, Vadim Gritsenko wrote:
> >> Hi All,
> >>
> >> With 5 recent bug fixes [1], one *major* speed improvement for {m,n} closures
> >> [2], with other various optimizations to compiler and runtime, and with previous
> >> release published sometime back in 2005 [3], now is the best, or at the very
> >> least, really good time to to cut next, 1.5 release of the venerable Jakarta
> >> Regexp package.
> >>
> >> Please try out current svn (r517970) version [4] and test for any regressions,
> >> and vote for a release. Regexp test suite can be run by issuing 'ant test' in
> >> the checkout directory, and does not take even 3 seconds to complete.
> >> Interactive testing can be done by using applet version [5].
> >>
> >> The only known incompatibility with Regexp 1.4 is that pre-compiled RE programs
> >> created with 'recompile' utility [6] for patterns containing reluctant closures
> >> are not compatible with trunk. But, that should not be a problem since they did
> >> not work correctly before anyway [7].
> >>
> >> My vote for the release is +1.
> >>
> >> Thanks,
> >> Vadim
> >>
> >> [1] http://jakarta.apache.org/regexp/changes.html
> >> [2] http://issues.apache.org/bugzilla/show_bug.cgi?id=9153
> >> [3] http://marc.info/?l=jakarta-regexp-dev&m=112429683615736
> >> [4] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/
> >> [5] http://jakarta.apache.org/regexp/applet.html
> >> [6]
> >> http://svn.apache.org/repos/asf/jakarta/regexp/trunk/src/jav a/org/apache/regexp/recompile.java
> >> [7] http://issues.apache.org/bugzilla/show_bug.cgi?id=27763
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

Re: [VOTE] Release Regexp 1.5

sebb wrote:
>> Also I think I need to update
>> headers as per [3], is that correct?
>
> You also need a NOTICE file [3]

Updated license headers, added NOTICE to zip/tar.gz.


> The LICENSE and NOTICE files ought to go into the jar as well, as the
> jar may well be used on its own.

Added both files to the META-INF directory of the jar file.


> License should be LICENSE [3]

Yep, it is there [1]. Exact copy.


>> [2] http://people.apache.org/~vgritsenko/regexp/
>
> It would be nice if the MD5 files used the more standard format:
>
> 9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip
>
> so that MD5 tools can process the file automatically.

Which tools you have in mind? All tools known and available to me (locally and
on p.a.o) produce the output

MD5 (file.name) = a7845d1201075c5041a798ae1cd7b8c8

The only exception is 'md5 -r', but it does not put '*' before file name.


Thanks for all the feedback. Files, now using r518169, are re-built and
re-uploaded [2].

Vadim

[1] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/LICENSE
[2] http://people.apache.org/~vgritsenko/regexp/

Re: [VOTE] Release Regexp 1.5

On 14/03/07, Vadim Gritsenko wrote:
> sebb wrote:
> >> Also I think I need to update
> >> headers as per [3], is that correct?
> >
> > You also need a NOTICE file [3]
>
> Updated license headers, added NOTICE to zip/tar.gz.
>
>
> > The LICENSE and NOTICE files ought to go into the jar as well, as the
> > jar may well be used on its own.
>
> Added both files to the META-INF directory of the jar file.
>
>
> > License should be LICENSE [3]
>
> Yep, it is there [1]. Exact copy.
>

The LICENSE and NOTICE files are now in the zip and jar, but they show
up for me as License and Notice. Ideally they should be in capitals.

>
> >> [2] http://people.apache.org/~vgritsenko/regexp/
> >
> > It would be nice if the MD5 files used the more standard format:
> >
> > 9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip
> >
> > so that MD5 tools can process the file automatically.
>
> Which tools you have in mind? All tools known and available to me (locally and
> on p.a.o) produce the output
>
> MD5 (file.name) = a7845d1201075c5041a798ae1cd7b8c8
>
> The only exception is 'md5 -r', but it does not put '*' before file name.

The '*' is supposed to be used for binary files; otherwise use ' ' (space).

The ones I have seen are:

http://en.wikipedia.org/wiki/Md5sum
http://mirror.href.com/thestarman/DOS/MD5progs.html#format
http://www.fourmilab.ch/md5/

Also the Tomcat MD5s (for example).



>
> Thanks for all the feedback. Files, now using r518169, are re-built and
> re-uploaded [2].
>
> Vadim
>
> [1] http://svn.apache.org/repos/asf/jakarta/regexp/trunk/LICENSE
> [2] http://people.apache.org/~vgritsenko/regexp/
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

Re: [VOTE] Release Regexp 1.5

+1

Re: [VOTE] Release Regexp 1.5

sebb wrote:
> The LICENSE and NOTICE files are now in the zip and jar, but they show
> up for me as License and Notice. Ideally they should be in capitals.

They are:

vgritsenko@minotaur ~/public_html/regexp $ tar -tzf
jakarta-regexp-1.5-dev.tar.gz | grep "dev/[^dsx]"
jakarta-regexp-1.5-dev/LICENSE
jakarta-regexp-1.5-dev/NOTICE
jakarta-regexp-1.5-dev/README

vgritsenko@minotaur ~/public_html/regexp $ unzip -l jakarta-regexp-1.5-dev.zip |
grep "dev/[^dsx]"
11357 03-14-07 10:05 jakarta-regexp-1.5-dev/LICENSE
302 03-14-07 10:05 jakarta-regexp-1.5-dev/NOTICE
901 03-14-07 10:05 jakarta-regexp-1.5-dev/README

vgritsenko@minotaur ~/public_html/regexp $ unzip jakarta-regexp-1.5-dev.zip
jakarta-regexp-1.5-dev/jakarta-regexp-1.5-dev.jar

vgritsenko@minotaur ~/public_html/regexp $ unzip -l
jakarta-regexp-1.5-dev/jakarta-regexp-1.5-dev.jar | grep -v org
Archive: jakarta-regexp-1.5-dev/jakarta-regexp-1.5-dev.jar
Length Date Time Name
-------- ---- ---- ----
0 03-14-07 10:04 META-INF/
106 03-14-07 10:04 META-INF/MANIFEST.MF
11357 03-14-07 09:52 META-INF/LICENSE
302 10-31-06 22:36 META-INF/NOTICE
-------- -------
62348 24 files



>> >> [2] http://people.apache.org/~vgritsenko/regexp/
>> >
>> > It would be nice if the MD5 files used the more standard format:
>> >
>> > 9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip
>> >
>> > so that MD5 tools can process the file automatically.
>>
>> Which tools you have in mind? All tools known and available to me
>> (locally and on p.a.o) produce the output
>>
>> MD5 (file.name) = a7845d1201075c5041a798ae1cd7b8c8
>>
>> The only exception is 'md5 -r', but it does not put '*' before file name.
>
> The '*' is supposed to be used for binary files; otherwise use ' ' (space).
>
> The ones I have seen are:
>
> http://en.wikipedia.org/wiki/Md5sum

It's not found on apache boxes.

> http://mirror.href.com/thestarman/DOS/MD5progs.html#format
> http://www.fourmilab.ch/md5/

That's exactly what I used. As mentioned above, can use 'md5 -r' if you prefer
it more. I guess that's exactly what you had in mind.

Vadim

Re: [VOTE] Release Regexp 1.5

On 14/03/07, Vadim Gritsenko wrote:
> sebb wrote:
> > The LICENSE and NOTICE files are now in the zip and jar, but they show
> > up for me as License and Notice. Ideally they should be in capitals.
>
> They are:
>
> vgritsenko@minotaur ~/public_html/regexp $ tar -tzf
> jakarta-regexp-1.5-dev.tar.gz | grep "dev/[^dsx]"
> jakarta-regexp-1.5-dev/LICENSE
> jakarta-regexp-1.5-dev/NOTICE
> jakarta-regexp-1.5-dev/README

Sorry, just discovered that Winzip was being "helpful" and converting
the file name...

> >> >> [2] http://people.apache.org/~vgritsenko/regexp/
> >> >
> >> > It would be nice if the MD5 files used the more standard format:
> >> >
> >> > 9336ab3a8871e055ca573ef6167ca90d *jakarta-regexp-1.5-dev.zip
> >> >
> >> > so that MD5 tools can process the file automatically.
> >>
> >> Which tools you have in mind? All tools known and available to me
> >> (locally and on p.a.o) produce the output
> >>
> >> MD5 (file.name) = a7845d1201075c5041a798ae1cd7b8c8
> >>
> >> The only exception is 'md5 -r', but it does not put '*' before file name.
> >
> > The '*' is supposed to be used for binary files; otherwise use ' ' (space).
> >
> > The ones I have seen are:
> >
> > http://en.wikipedia.org/wiki/Md5sum
>
> It's not found on apache boxes.

Some / most users are not on apache boxes...

> > http://mirror.href.com/thestarman/DOS/MD5progs.html#format
> > http://www.fourmilab.ch/md5/
>
> That's exactly what I used. As mentioned above, can use 'md5 -r' if you prefer
> it more. I guess that's exactly what you had in mind.
>

Well, either format will do for humans.

The format I am suggesting is supported as input to some programs that
can be used to check the MD5s - is the other format usable as input?
If so, which program(s)?

But anyway:

+1 to the release

S///

Re: [VOTE] Release Regexp 1.5

On 3/14/07, Vadim Gritsenko wrote:
> Henning Schmiedehausen wrote:

> > You actually have to roll and sign a tarball/zip ball on which the vote
> > happens. "Release-then-Vote" seems to be the only accepted way by the
> > board these days;
>
> Thankfully, neither events in velocity-private nor board feelings apply here.
> Either Jakarta PMC votes for it or receives an resolution, before that happens,
> existing procedures [1] stay.

There are (to my knowledge) three types of vote/release styles that
have been happening at the ASF.

1) A vote to do a release, with no sign of release files. This is how
this thread started and it's against ASF policy.

2) A vote on release-candidate files (or -dev in your case), and then
a release that is trusted to be a repeat of the process used. This is
currently a grey area policy-wise, and is where this release moved to
with the ~/vgritsenko/*-dev files.

3) Creating the actual files that are going to be released and voting
on them. There's pressure to go this way, but it's not the policy yet.

> > personally I do prefer "Vote-then-Release" myself but
> > that seems to be the way it is.

Release-then-Vote has some nice parts, the actual release is really
easy. That's nice if the release process has been painful as it means
I don't have to remember how to do the damn thing. Vote-then-Release
is nice in that you don't end up doing as many vote builds.

Other parts of the ASF seem to do a release where they make a build
and if it passes a vote it goes out, if it doesn't then they up the
bugfix number and do it again (I don't think anyone actually has a
build number, ie: 1.3.5.7). They also have an alpha/beta/GA thing that
the version number doesn't show. Very confusing as a user I think.

Mostly at this stage the mandate is that we have to be voting on
release files, not on "Hey, how about a release".

Hen

[RESULT][VOTE] Release Regexp 1.5

The vote to release passes with +1s from:

Vadim Gritsenko
Henning Schmiedehausen
Daniel F. Savarese
sebb


Henri Yandell wrote:
> There are (to my knowledge) three types of vote/release styles that
> have been happening at the ASF.
>
> 1) A vote to do a release, with no sign of release files. This is how
> this thread started and it's against ASF policy.

Can you put a finger on this policy? I'm not sure I'm aware of such policy.

> 2) A vote on release-candidate files (or -dev in your case), and then
> a release that is trusted to be a repeat of the process used. This is
> currently a grey area policy-wise, and is where this release moved to
> with the ~/vgritsenko/*-dev files.

Indeed.

> 3) Creating the actual files that are going to be released and voting
> on them. There's pressure to go this way, but it's not the policy yet.
>
>> > personally I do prefer "Vote-then-Release" myself but
>> > that seems to be the way it is.
>
> Release-then-Vote has some nice parts, the actual release is really
> easy. That's nice if the release process has been painful as it means
> I don't have to remember how to do the damn thing. Vote-then-Release
> is nice in that you don't end up doing as many vote builds.
>
> Other parts of the ASF seem to do a release where they make a build
> and if it passes a vote it goes out, if it doesn't then they up the
> bugfix number and do it again (I don't think anyone actually has a
> build number, ie: 1.3.5.7). They also have an alpha/beta/GA thing that
> the version number doesn't show. Very confusing as a user I think.

Agree.

> Mostly at this stage the mandate is that we have to be voting on
> release files, not on "Hey, how about a release".

This is the single most valuable vote. Either community has a consensus on
status of code in question - is it ready to be a GA release? - or not. There is
some limited sense on voting on final files - just to make sure RM did not
messed up in the process - but it has no much value over "Hey, how about a
release" vote, and adds to the confusion, as you correctly noted above.

Vadim

Re: [VOTE] Release Regexp 1.5

Henri Yandell wrote:



PS I noticed that you forgot to vote this year :-)
http://marc.info/?l=jakarta-general&m=112388881425543

Vadim

Re: [VOTE] Release Regexp 1.5

Henri Yandell wrote:
> 3) Creating the actual files that are going to be released and voting
> on them. There's pressure to go this way, but it's not the policy yet.

Vote has passed, so now actual files are made, and are available at the same
location [1].

Vadim

[1] http://people.apache.org/~vgritsenko/regexp/

Re: [VOTE] Release Regexp 1.5

Vadim,

that is not the point. The procedure in itself is flawed. There might be
files now, but the procedure still has to be aligned to ASF wide guide
lines.

Before you wonder/think about conspiracy theories: Yes, I brought the
board (i.e. Henri) attention to this. It is necessary to change the
commons release procedures and if you think that experiences of other
PMCs (Velocity) don't count, let's try with a board opinion.

Best regards
Henning



Vadim Gritsenko schrieb:
> Henri Yandell wrote:
>> 3) Creating the actual files that are going to be released and voting
>> on them. There's pressure to go this way, but it's not the policy yet.
>
> Vote has passed, so now actual files are made, and are available at the
> same location [1].
>
> Vadim
>
> [1] http://people.apache.org/~vgritsenko/regexp/
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>

--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine

"Save the cheerleader. Save the world."

Re: [VOTE] Release Regexp 1.5

Henning Schmiedehausen wrote:
> Vadim,
>
> that is not the point. The procedure in itself is flawed.

You missed it too :) Existing procedure might be flawed in somebody's opinion,
and I'm not arguing that it is ideal, but proposed procedure is even worse. It
makes any release impossible: release packages can be made available only after
the release itself is made. This makes me think that such procedure comes from
the camp not taking SCM seriously.

Since the objective of the change to the process is to verify steps done by RM,
the only viable procedure, in my view, is - (1) vote on SVN rev number (with
packages made available), (2) tagging and building a release, (3) quick vote on
resulting files. It's quick sine no actual software testing need to be
performed, just verify that zip unzips and tar untars.

Vadim

> There might be
> files now, but the procedure still has to be aligned to ASF wide guide
> lines.
>
> Before you wonder/think about conspiracy theories: Yes, I brought the
> board (i.e. Henri) attention to this. It is necessary to change the
> commons release procedures and if you think that experiences of other
> PMCs (Velocity) don't count, let's try with a board opinion.
>
> Best regards
> Henning
>
>
>
> Vadim Gritsenko schrieb:
>> Henri Yandell wrote:
>>> 3) Creating the actual files that are going to be released and voting
>>> on them. There's pressure to go this way, but it's not the policy yet.
>>
>> Vote has passed, so now actual files are made, and are available at
>> the same location [1].
>>
>> Vadim
>>
>> [1] http://people.apache.org/~vgritsenko/regexp/

Re: [VOTE] Release Regexp 1.5

Or even better, let everyone follow their own procedures while loosely
fitting into a less restrictive set of obvious guidelines wrt
licensing / distribution locations /etc - so the rest of us don't have
to be punished because one or two projects are having issues getting
releases out....

On 3/19/07, Vadim Gritsenko wrote:
> Henning Schmiedehausen wrote:
> > Vadim,
> >
> > that is not the point. The procedure in itself is flawed.
>
> You missed it too :) Existing procedure might be flawed in somebody's opinion,
> and I'm not arguing that it is ideal, but proposed procedure is even worse. It
> makes any release impossible: release packages can be made available only after
> the release itself is made. This makes me think that such procedure comes from
> the camp not taking SCM seriously.
>
> Since the objective of the change to the process is to verify steps done by RM,
> the only viable procedure, in my view, is - (1) vote on SVN rev number (with
> packages made available), (2) tagging and building a release, (3) quick vote on
> resulting files. It's quick sine no actual software testing need to be
> performed, just verify that zip unzips and tar untars.
>
> Vadim
>
> > There might be
> > files now, but the procedure still has to be aligned to ASF wide guide
> > lines.
> >
> > Before you wonder/think about conspiracy theories: Yes, I brought the
> > board (i.e. Henri) attention to this. It is necessary to change the
> > commons release procedures and if you think that experiences of other
> > PMCs (Velocity) don't count, let's try with a board opinion.
> >
> > Best regards
> > Henning
> >
> >
> >
> > Vadim Gritsenko schrieb:
> >> Henri Yandell wrote:
> >>> 3) Creating the actual files that are going to be released and voting
> >>> on them. There's pressure to go this way, but it's not the policy yet.
> >>
> >> Vote has passed, so now actual files are made, and are available at
> >> the same location [1].
> >>
> >> Vadim
> >>
> >> [1] http://people.apache.org/~vgritsenko/regexp/
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>


--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

Re: [VOTE] Release Regexp 1.5

On 19/03/07, Vadim Gritsenko wrote:
> Henning Schmiedehausen wrote:
> > Vadim,
> >
> > that is not the point. The procedure in itself is flawed.
>
> You missed it too :) Existing procedure might be flawed in somebody's opinion,
> and I'm not arguing that it is ideal, but proposed procedure is even worse. It
> makes any release impossible: release packages can be made available only after
> the release itself is made. This makes me think that such procedure comes from
> the camp not taking SCM seriously.
>
> Since the objective of the change to the process is to verify steps done by RM,
> the only viable procedure, in my view, is - (1) vote on SVN rev number (with
> packages made available), (2) tagging and building a release, (3) quick vote on
> resulting files. It's quick sine no actual software testing need to be
> performed, just verify that zip unzips and tar untars.

I think one also needs to check that:
* that the various signature files are present and correct
* the zips and tars contain the same files as each other
* the zips and tars and contained jars contain the required NOTICE and
LICENSE files
* the source archive includes all the required sources from SVN
* the bin archive includes all the required files (apart from any
documented dependencies)

I don't think these can be determined directly from the contents of an
SVN rev number, so need to be checked after a potential release has
been built.

==

As to release voting:

Surely the most important thing is to ensure that a build is not
released to the general public - i.e. not put in the dist tree -
before the vote has passed.

So long as the build files are in a private area - e.g. the RM's
public_html directory - (and maybe are named as pre-release) the vote
can be done on the actual files.

S///

Re: [VOTE] Release Regexp 1.5

sebb wrote:
> On 19/03/07, Vadim Gritsenko wrote:
>> resulting files. It's quick sine no actual software testing need to be
>> performed, just verify that zip unzips and tar untars.
>
> I think one also needs to check that:
> * that the various signature files are present and correct
> * the zips and tars contain the same files as each other
> * the zips and tars and contained jars contain the required NOTICE and
> LICENSE files
> * the source archive includes all the required sources from SVN
> * the bin archive includes all the required files (apart from any
> documented dependencies)

(This is done by ant, btw, and so is 99% reproducible)

> I don't think these can be determined directly from the contents of an
> SVN rev number, so need to be checked after a potential release has
> been built.

Hence I mentioned 'quick check of release files'. Would satisfy even procedure
extremists.

> ==
>
> As to release voting:
>
> Surely the most important thing is to ensure that a build is not
> released to the general public - i.e. not put in the dist tree -
> before the vote has passed.
>
> So long as the build files are in a private area - e.g. the RM's
> public_html directory - (and maybe are named as pre-release) the vote
> can be done on the actual files.

Actual files, as you might have noticed, are impossible to produce before
release is tagged. To tag a release, a vote must pass. Best you could do is to
produce 'rc' build off of trunk.

Vadim

Re: [VOTE] Release Regexp 1.5

On 19/03/07, Vadim Gritsenko wrote:
> sebb wrote:
> > On 19/03/07, Vadim Gritsenko wrote:
> >> resulting files. It's quick sine no actual software testing need to be
> >> performed, just verify that zip unzips and tar untars.
> >
> > I think one also needs to check that:
> > * that the various signature files are present and correct
> > * the zips and tars contain the same files as each other
> > * the zips and tars and contained jars contain the required NOTICE and
> > LICENSE files
> > * the source archive includes all the required sources from SVN
> > * the bin archive includes all the required files (apart from any
> > documented dependencies)
>
> (This is done by ant, btw, and so is 99% reproducible)

It's the other 1% that is the problem ...

>
> > I don't think these can be determined directly from the contents of an
> > SVN rev number, so need to be checked after a potential release has
> > been built.
>
> Hence I mentioned 'quick check of release files'. Would satisfy even procedure
> extremists.
>
> > ==
> >
> > As to release voting:
> >
> > Surely the most important thing is to ensure that a build is not
> > released to the general public - i.e. not put in the dist tree -
> > before the vote has passed.
> >
> > So long as the build files are in a private area - e.g. the RM's
> > public_html directory - (and maybe are named as pre-release) the vote
> > can be done on the actual files.
>
> Actual files, as you might have noticed, are impossible to produce before
> release is tagged. To tag a release, a vote must pass. Best you could do is to
> produce 'rc' build off of trunk.

Surely voting on creating a tag (if this is necessary) is completely
different from voting on a release?

S

Re: [VOTE] Release Regexp 1.5

sebb wrote:
> Surely voting on creating a tag (if this is necessary)

Absolutely. Any release tag must be a community decision == vote is required.


> is completely different from voting on a release?

Not to me.

Voting on a release (on a tag) signifies that software is in a state where it
can be released to general public.

Voting on a files (produced from release tag) is a mechanical vote on
correctness of files produced by ant.

Vadim

Re: [VOTE] Release Regexp 1.5

On 19/03/07, Vadim Gritsenko wrote:
> sebb wrote:
> > Surely voting on creating a tag (if this is necessary)
>
> Absolutely. Any release tag must be a community decision == vote is required.
>
>
> > is completely different from voting on a release?
>
> Not to me.
>
> Voting on a release (on a tag) signifies that software is in a state where it
> can be released to general public.
>
> Voting on a files (produced from release tag) is a mechanical vote on
> correctness of files produced by ant.
>

AFAIK, the ASF rules are that files must not be released to the
general public without a formal vote by the PMC on the release, which
I take to mean voting on the files which are proposed to be released.

Requiring consensus on tagging seems sensible, but I'm not sure it is required.

The problem here seems to be that it is not possible to use one vote
to do both; therefore it seems to me that the sensible thing to do is
to have two votes.

The first vote (on tagging) seems to me to be something that relates
mainly to committers working on the project.

The second vote has to involve PMC members; others can vote, but their
votes generally do not count (though I guess a -1 would need to be
investigated).

Seems to me that there needs to be formal documentation of the
required and recommended release processes.

S///

Re: [VOTE] Release Regexp 1.5

You have to be kidding me..

The only problem I see is that people are all caught up in policies /
processes but I've yet to hear what the actual root "problem" is. I'm
sure it's intended to somehow prevent something nasty that has
happened in the past but these policies don't have any logic that I'm
able to follow. Why does the ASF need to dictate how we vote on
releases?

Maybe I'm just having a bad morning, but for some reason this really
rubs me the wrong way and feels extremely inefficient.

On 3/19/07, sebb wrote:

> The problem here seems to be that it is not possible to use one vote
> to do both; therefore it seems to me that the sensible thing to do is
> to have two votes.



--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

RE: [VOTE] Release Regexp 1.5

sebb wrote on Monday, March 19, 2007 3:09 PM:

> On 19/03/07, Vadim Gritsenko wrote:
>> sebb wrote:
>>> Surely voting on creating a tag (if this is necessary)
>>=20
>> Absolutely. Any release tag must be a community decision == vote =
is
>> required.=20
>>=20
>>=20
>>> is completely different from voting on a release?
>>=20
>> Not to me.
>>=20
>> Voting on a release (on a tag) signifies that software is in a state
>> where it can be released to general public.
>>=20
>> Voting on a files (produced from release tag) is a mechanical vote on
>> correctness of files produced by ant.
>>=20
>=20
> AFAIK, the ASF rules are that files must not be released to the
> general public without a formal vote by the PMC on the release, which
> I take to mean voting on the files which are proposed to be released.
>=20
> Requiring consensus on tagging seems sensible, but I'm not
> sure it is required.
>=20
> The problem here seems to be that it is not possible to use one vote
> to do both; therefore it seems to me that the sensible thing to do is
> to have two votes.=20
>=20
> The first vote (on tagging) seems to me to be something that relates
> mainly to committers working on the project.
>=20
> The second vote has to involve PMC members; others can vote, but their
> votes generally do not count (though I guess a -1 would need to be
> investigated).=20

And since no-one wants to vote twice, the vote is done on the released =
artifacts in the RM's private area (or a more official staging area). =
This includes also that the version is already tagged. If for whatever =
reason the vote does not pass we can drop the version from the SCM again =
.... since it did not represent a valid release anymore.

> Seems to me that there needs to be formal documentation of the
> required and recommended release processes.

- Jörg

BTW: I did not vote, exactly because I should have to check out from svn =
- and nobody can guarantee me that I have a proper environment to check =
the release I build myself.

Re: [VOTE] Release Regexp 1.5

On 19/03/07, Jesse Kuhnert wrote:
> You have to be kidding me..
>
> The only problem I see is that people are all caught up in policies /
> processes but I've yet to hear what the actual root "problem" is. I'm
> sure it's intended to somehow prevent something nasty that has
> happened in the past but these policies don't have any logic that I'm
> able to follow. Why does the ASF need to dictate how we vote on
> releases?

I don't have the references to hand, but I believe it is something to
do with providing some form of legal protection. There may be other
reasons as well.

> Maybe I'm just having a bad morning, but for some reason this really
> rubs me the wrong way and feels extremely inefficient.

As far as I know, only one formal vote is actually required by the
ASF; this must be by the PMC on the release itself.

> On 3/19/07, sebb wrote:
>
> > The problem here seems to be that it is not possible to use one vote
> > to do both; therefore it seems to me that the sensible thing to do is
> > to have two votes.
>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

Re: [VOTE] Release Regexp 1.5

I have a thought that may not be an immediate solution.

Isn't the correctness of a release from a build point of view a
testable condition? Shouldn't this be built in to the build system.

The apache servers would not allow an "invalid" package. They define
the pattern. Isn't this GUMP? Not knowing details but seeing emails.

Otherwise you are cloaking a software challenge within adminstratium
(http://en.wikipedia.org/wiki/Administratium)

(Sorry, if I'm a little incoherent, I'm finishing an ironman front to
back website release for work with last minute untested boss changes
and bug fixes in the fortran - model went from 1 to 5 modes .... )

Regards,
Dave Fisher

On Mar 19, 2007, at 9:55 AM, sebb wrote:

> On 19/03/07, Jesse Kuhnert wrote:
>> You have to be kidding me..
>>
>> The only problem I see is that people are all caught up in policies /
>> processes but I've yet to hear what the actual root "problem" is. I'm
>> sure it's intended to somehow prevent something nasty that has
>> happened in the past but these policies don't have any logic that I'm
>> able to follow. Why does the ASF need to dictate how we vote on
>> releases?
>
> I don't have the references to hand, but I believe it is something to
> do with providing some form of legal protection. There may be other
> reasons as well.
>
>> Maybe I'm just having a bad morning, but for some reason this really
>> rubs me the wrong way and feels extremely inefficient.
>
> As far as I know, only one formal vote is actually required by the
> ASF; this must be by the PMC on the release itself.
>
>> On 3/19/07, sebb wrote:
>>
>> > The problem here seems to be that it is not possible to use one
>> vote
>> > to do both; therefore it seems to me that the sensible thing to
>> do is
>> > to have two votes.
>>
>>
>>
>> --
>> Jesse Kuhnert
>> Tapestry/Dojo team member/developer
>>
>> Open source based consulting work centered around
>> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>>
>> ------------------------------------------------------------ ---------
>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

Re: [VOTE] Release Regexp 1.5

"Jesse Kuhnert" writes:

> You have to be kidding me..
>
> The only problem I see is that people are all caught up in policies /
> processes but I've yet to hear what the actual root "problem" is. I'm
> sure it's intended to somehow prevent something nasty that has
> happened in the past but these policies don't have any logic that I'm
> able to follow. Why does the ASF need to dictate how we vote on
> releases?
>
> Maybe I'm just having a bad morning, but for some reason this really
> rubs me the wrong way and feels extremely inefficient.

The problem is that Vote-Then-Release leaves opportunities for the
small details to get missed and you end up with a sloppy release.
Examples include non-signed distributables, incomplete legal notices,
missing or incorrect hashes. The worst is someone slipping in some
malicious code in between the time the vote is cast and the release is
made.

When a PMC votes on a release they should be approving the exact bits
that hit the mirrors. That vote binds the ASF to be _legally_
responsible. The only way to have sufficient and appropriate
oversight is to give the PMC a chance to check that these final steps
of a release have been properly handled. Otherwise the PMC risks
releasing a half baked product.

It is completely appropriate for the ASF to set guidelines on release
procedures.

--
jaaron (who is not on the Jakarta PMC)

Re: [VOTE] Release Regexp 1.5

Sure, of course it's ok for the ASF to dictate policies - I just hope
it's ok for me to question them / point out their flaws.

So the real problem as far as I can tell is making sure a release is
legitimately licensed. There are other things like software quality,
but I guess it's assumed (by me at least) that we're all trying to
release as high a caliber of software as we are able given our
resources / time.

Somehow this still doesn't feel like a legitimate problem, or at least
it is not consistent with the rest of our daily practices. ..Like
committing a change to subversion. As far as I can tell there is no
legal difference between subversion repositories and released software
- is there? Isn't the end goal to prevent any naughty code coming out
of apache period? Non conforming code sitting in subversion would
appear to be just as guilty as anything else...So given your current
logic shouldn't we all be required to have a PMC vote for each commit
made into the repo?

It just feels like we're being treated a little bit like incompetents
in some way. Like maybe someone accidentally made a bad release once
or twice and so we must all suffer the same solution that they have.

Ehh...Obviously I'm alone in my opinion so I'll shut up now, just
wanted to make sure I got my two cents in.

On 3/19/07, J Aaron Farr wrote:
> "Jesse Kuhnert" writes:
>
> > You have to be kidding me..
> >
> > The only problem I see is that people are all caught up in policies /
> > processes but I've yet to hear what the actual root "problem" is. I'm
> > sure it's intended to somehow prevent something nasty that has
> > happened in the past but these policies don't have any logic that I'm
> > able to follow. Why does the ASF need to dictate how we vote on
> > releases?
> >
> > Maybe I'm just having a bad morning, but for some reason this really
> > rubs me the wrong way and feels extremely inefficient.
>
> The problem is that Vote-Then-Release leaves opportunities for the
> small details to get missed and you end up with a sloppy release.
> Examples include non-signed distributables, incomplete legal notices,
> missing or incorrect hashes. The worst is someone slipping in some
> malicious code in between the time the vote is cast and the release is
> made.
>
> When a PMC votes on a release they should be approving the exact bits
> that hit the mirrors. That vote binds the ASF to be _legally_
> responsible. The only way to have sufficient and appropriate
> oversight is to give the PMC a chance to check that these final steps
> of a release have been properly handled. Otherwise the PMC risks
> releasing a half baked product.
>
> It is completely appropriate for the ASF to set guidelines on release
> procedures.
>
> --
> jaaron (who is not on the Jakarta PMC)
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>


--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

Re: [VOTE] Release Regexp 1.5

------=_Part_46104_13732378.1174325935166
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I think we have to remember that the ASF provides an important legal
umbrella here. By setting policies which we follow (which of course can be
debated), it prevents us from being sued if an SCO-type situation develops.
This would be a low-probability, but extremely catastrophic event,
especially since developers could be sued directly if they were operating
independently. The PMC plays an important role in shielding individual
developers from liability by approving releases according to defined
policies.

WILL





On 3/19/07, Jesse Kuhnert wrote:
>
> Sure, of course it's ok for the ASF to dictate policies - I just hope
> it's ok for me to question them / point out their flaws.
>
> So the real problem as far as I can tell is making sure a release is
> legitimately licensed. There are other things like software quality,
> but I guess it's assumed (by me at least) that we're all trying to
> release as high a caliber of software as we are able given our
> resources / time.
>
> Somehow this still doesn't feel like a legitimate problem, or at least
> it is not consistent with the rest of our daily practices. ..Like
> committing a change to subversion. As far as I can tell there is no
> legal difference between subversion repositories and released software
> - is there? Isn't the end goal to prevent any naughty code coming out
> of apache period? Non conforming code sitting in subversion would
> appear to be just as guilty as anything else...So given your current
> logic shouldn't we all be required to have a PMC vote for each commit
> made into the repo?
>
> It just feels like we're being treated a little bit like incompetents
> in some way. Like maybe someone accidentally made a bad release once
> or twice and so we must all suffer the same solution that they have.
>
> Ehh...Obviously I'm alone in my opinion so I'll shut up now, just
> wanted to make sure I got my two cents in.
>
> On 3/19/07, J Aaron Farr wrote:
> > "Jesse Kuhnert" writes:
> >
> > > You have to be kidding me..
> > >
> > > The only problem I see is that people are all caught up in policies /
> > > processes but I've yet to hear what the actual root "problem" is. I'm
> > > sure it's intended to somehow prevent something nasty that has
> > > happened in the past but these policies don't have any logic that I'm
> > > able to follow. Why does the ASF need to dictate how we vote on
> > > releases?
> > >
> > > Maybe I'm just having a bad morning, but for some reason this really
> > > rubs me the wrong way and feels extremely inefficient.
> >
> > The problem is that Vote-Then-Release leaves opportunities for the
> > small details to get missed and you end up with a sloppy release.
> > Examples include non-signed distributables, incomplete legal notices,
> > missing or incorrect hashes. The worst is someone slipping in some
> > malicious code in between the time the vote is cast and the release is
> > made.
> >
> > When a PMC votes on a release they should be approving the exact bits
> > that hit the mirrors. That vote binds the ASF to be _legally_
> > responsible. The only way to have sufficient and appropriate
> > oversight is to give the PMC a chance to check that these final steps
> > of a release have been properly handled. Otherwise the PMC risks
> > releasing a half baked product.
> >
> > It is completely appropriate for the ASF to set guidelines on release
> > procedures.
> >
> > --
> > jaaron (who is not on the Jakarta PMC)
> >
> > ------------------------------------------------------------ ---------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>


--
Forio Business Simulations

Will Glass-Husain
415 440-7500x89
wglass@forio.com
www.forio.com

------=_Part_46104_13732378.1174325935166--

Re: [VOTE] Release Regexp 1.5

>> You have to be kidding me..
>>
>> The only problem I see is that people are all caught up in policies /
>> processes but I've yet to hear what the actual root "problem" is. I'm
>> sure it's intended to somehow prevent something nasty that has
>> happened in the past but these policies don't have any logic that I'm
>> able to follow. Why does the ASF need to dictate how we vote on
>> releases?
>>
>> Maybe I'm just having a bad morning, but for some reason this really
>> rubs me the wrong way and feels extremely inefficient.
>
> The problem is that Vote-Then-Release leaves opportunities for the
> small details to get missed and you end up with a sloppy release.
> Examples include non-signed distributables, incomplete legal notices,
> missing or incorrect hashes. The worst is someone slipping in some
> malicious code in between the time the vote is cast and the release is
> made.

I may be wrong, but the ASF already has agreements with all
committers and PMCs.

So, anyone slipping in malicious code into a release has already
agreed not to do it. Anyone doing so is tagged.

This means that any of these mistakes are "bugs". And while we want
everything to be perfect, not everything is that way.

>
> When a PMC votes on a release they should be approving the exact bits
> that hit the mirrors. That vote binds the ASF to be _legally_
> responsible. The only way to have sufficient and appropriate
> oversight is to give the PMC a chance to check that these final steps
> of a release have been properly handled. Otherwise the PMC risks
> releasing a half baked product.

So each project requires 3 release managers? The vote to release
should appoint a release manager, and the manager should make the
release. Their word is their bond. Who wants the reputation as a
screw up? If the PMCs delegate it to another person then karma is
reflected.

>
> It is completely appropriate for the ASF to set guidelines on release
> procedures.

Appropriate as long as they don't treat contributers like children.
The ASF should have policies that enable open source, and not
discourage it.

If someone screws up too many releases then the community can take
away their karma.

The ASF should automate all those bit manipulations. Didn't someone
in this thread say that ant does 99% of it?

Regards,
Dave Fisher


>
> --
> jaaron (who is not on the Jakarta PMC)
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

Re: [VOTE] Release Regexp 1.5

Jesse Kuhnert wrote:
> Ehh...Obviously I'm alone in my opinion so I'll shut up now, just
> wanted to make sure I got my two cents in.

Make that two of us. ASF today indeed contains much more Administratium (thanks
Dave, great link!) than it used to.

Vadim

Re: [VOTE] Release Regexp 1.5

On Mon, 2007-03-19 at 13:30 -0400, Jesse Kuhnert wrote:
> Sure, of course it's ok for the ASF to dictate policies - I just hope
> it's ok for me to question them / point out their flaws.
>
> So the real problem as far as I can tell is making sure a release is
> legitimately licensed. There are other things like software quality,
> but I guess it's assumed (by me at least) that we're all trying to
> release as high a caliber of software as we are able given our
> resources / time.
>
> Somehow this still doesn't feel like a legitimate problem, or at least
> it is not consistent with the rest of our daily practices. ..Like
> committing a change to subversion. As far as I can tell there is no
> legal difference between subversion repositories and released software
> - is there? Isn't the end goal to prevent any naughty code coming out
> of apache period? Non conforming code sitting in subversion would
> appear to be just as guilty as anything else...So given your current
> logic shouldn't we all be required to have a PMC vote for each commit
> made into the repo?
>
> It just feels like we're being treated a little bit like incompetents
> in some way. Like maybe someone accidentally made a bad release once
> or twice and so we must all suffer the same solution that they have.
>
> Ehh...Obviously I'm alone in my opinion so I'll shut up now, just
> wanted to make sure I got my two cents in.
>

Jesse,

You are certainly not alone. I have always been of an option that the
content of the SVN repository is what truly represents the source code
of ASF software, with packaged releases merely being versioned snapshots
officially endorsed by the project committers and the respective PMC and
recommended for use by the end users. I am not a legal expect by any
stretch of imagination but I think ASF may be equally liable for any
given revision in its official SVN repository as for its packaged
releases.

In Commons HttpClient / HttpComponents land we historically voted on SVN
revisions and published release packages based on a lazy consensus if no
one raised complaints about the content of the release packages.

Oleg

> On 3/19/07, J Aaron Farr wrote:
> > "Jesse Kuhnert" writes:
> >
> > > You have to be kidding me..
> > >
> > > The only problem I see is that people are all caught up in policies /
> > > processes but I've yet to hear what the actual root "problem" is. I'm
> > > sure it's intended to somehow prevent something nasty that has
> > > happened in the past but these policies don't have any logic that I'm
> > > able to follow. Why does the ASF need to dictate how we vote on
> > > releases?
> > >
> > > Maybe I'm just having a bad morning, but for some reason this really
> > > rubs me the wrong way and feels extremely inefficient.
> >
> > The problem is that Vote-Then-Release leaves opportunities for the
> > small details to get missed and you end up with a sloppy release.
> > Examples include non-signed distributables, incomplete legal notices,
> > missing or incorrect hashes. The worst is someone slipping in some
> > malicious code in between the time the vote is cast and the release is
> > made.
> >
> > When a PMC votes on a release they should be approving the exact bits
> > that hit the mirrors. That vote binds the ASF to be _legally_
> > responsible. The only way to have sufficient and appropriate
> > oversight is to give the PMC a chance to check that these final steps
> > of a release have been properly handled. Otherwise the PMC risks
> > releasing a half baked product.
> >
> > It is completely appropriate for the ASF to set guidelines on release
> > procedures.
> >
> > --
> > jaaron (who is not on the Jakarta PMC)
> >
> > ------------------------------------------------------------ ---------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
>
>

Re: [VOTE] Release Regexp 1.5

On 3/19/07, Oleg Kalnichevski wrote:
> On Mon, 2007-03-19 at 13:30 -0400, Jesse Kuhnert wrote:
> > Sure, of course it's ok for the ASF to dictate policies - I just hope
> > it's ok for me to question them / point out their flaws.
> >
> > So the real problem as far as I can tell is making sure a release is
> > legitimately licensed. There are other things like software quality,
> > but I guess it's assumed (by me at least) that we're all trying to
> > release as high a caliber of software as we are able given our
> > resources / time.
> >
> > Somehow this still doesn't feel like a legitimate problem, or at least
> > it is not consistent with the rest of our daily practices. ..Like
> > committing a change to subversion. As far as I can tell there is no
> > legal difference between subversion repositories and released software
> > - is there? Isn't the end goal to prevent any naughty code coming out
> > of apache period? Non conforming code sitting in subversion would
> > appear to be just as guilty as anything else...So given your current
> > logic shouldn't we all be required to have a PMC vote for each commit
> > made into the repo?
> >
> > It just feels like we're being treated a little bit like incompetents
> > in some way. Like maybe someone accidentally made a bad release once
> > or twice and so we must all suffer the same solution that they have.
> >
> > Ehh...Obviously I'm alone in my opinion so I'll shut up now, just
> > wanted to make sure I got my two cents in.
> >
>
> Jesse,
>
> You are certainly not alone. I have always been of an option that the
> content of the SVN repository is what truly represents the source code
> of ASF software, with packaged releases merely being versioned snapshots
> officially endorsed by the project committers and the respective PMC and
> recommended for use by the end users. I am not a legal expect by any
> stretch of imagination but I think ASF may be equally liable for any
> given revision in its official SVN repository as for its packaged
> releases.

sure. and the SVN repo has protections that releases do not: commits
are sent to a mailing list for oversight and archival. they are kept
in a central place that is easy to control and not distributed
widely. the consequences for problems are small and easily remedied.

the actual bits that are distributed as an officially endorsed release
do not have the luxury of diffs sent to the development lists, nor are
they easily controlled from a central location. the releases are
extensively mirrored by servers all over the place. releases are nigh
impossible to recall. thus, with the broader audience, the
consequences for problems are greatly magnified and are not easily
remedied.

i can understand complaints about the process, but let's not pretend
that releases do not need an extra measure of protection that the
repositories do not.

that said, i would love to see some more automation of
signature/hash/LICENSE/NOTICE/zip-tar-consistency checking. i believe
Henk Penning does have some automated signature checking set up, but
that's all i know of, and it only happens after the release is out.

anyone frustrated with the process is quite welcome to step up and
hack up something to ease the frustration. :)

> In Commons HttpClient / HttpComponents land we historically voted on SVN
> revisions and published release packages based on a lazy consensus if no
> one raised complaints about the content of the release packages.
>
> Oleg
>
> > On 3/19/07, J Aaron Farr wrote:
> > > "Jesse Kuhnert" writes:
> > >
> > > > You have to be kidding me..
> > > >
> > > > The only problem I see is that people are all caught up in policies /
> > > > processes but I've yet to hear what the actual root "problem" is. I'm
> > > > sure it's intended to somehow prevent something nasty that has
> > > > happened in the past but these policies don't have any logic that I'm
> > > > able to follow. Why does the ASF need to dictate how we vote on
> > > > releases?
> > > >
> > > > Maybe I'm just having a bad morning, but for some reason this really
> > > > rubs me the wrong way and feels extremely inefficient.
> > >
> > > The problem is that Vote-Then-Release leaves opportunities for the
> > > small details to get missed and you end up with a sloppy release.
> > > Examples include non-signed distributables, incomplete legal notices,
> > > missing or incorrect hashes. The worst is someone slipping in some
> > > malicious code in between the time the vote is cast and the release is
> > > made.
> > >
> > > When a PMC votes on a release they should be approving the exact bits
> > > that hit the mirrors. That vote binds the ASF to be _legally_
> > > responsible. The only way to have sufficient and appropriate
> > > oversight is to give the PMC a chance to check that these final steps
> > > of a release have been properly handled. Otherwise the PMC risks
> > > releasing a half baked product.
> > >
> > > It is completely appropriate for the ASF to set guidelines on release
> > > procedures.
> > >
> > > --
> > > jaaron (who is not on the Jakarta PMC)
> > >
> > > ------------------------------------------------------------ ---------
> > > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: general-help@jakarta.apache.org
> > >
> > >
> >
> >
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

Re: [VOTE] Release Regexp 1.5

"Nathan Bubna" writes:

> that said, i would love to see some more automation of
> signature/hash/LICENSE/NOTICE/zip-tar-consistency checking. i believe
> Henk Penning does have some automated signature checking set up, but
> that's all i know of, and it only happens after the release is out.
>
> anyone frustrated with the process is quite welcome to step up and
> hack up something to ease the frustration. :)

ARAT helps:

http://code.google.com/p/arat/

And again you can code up a lot of this in Ant or use some of Maven's plugins.

--
jaaron

Re: [VOTE] Release Regexp 1.5

Ok so I'm a liar...I did want to point out that from my experience
even the most formal voting process won't get the desired results -
that everyone on the project certifies and checks that the binaries
going out are good. More than likely 90% of the time everyone just
votes yes or no and trusts that the person managing the release knows
what they are doing. .....but these are small points. Still, they do
point to the voting process being meaningless other than all of the
PMC's putting their names on it if it should go poorly. (though in a
true team sort of mindset you'd think that this would always be the
case with / without votes / other processes...)

Automation is good. Esp. if it lets us opt to always trust committer X
managing a release once and let a diligent little script do everything
else for else without any intervention. That would be great and would
bring me back to where I already was. ;)

On 3/19/07, Nathan Bubna wrote:

> the actual bits that are distributed as an officially endorsed release
> do not have the luxury of diffs sent to the development lists, nor are
> they easily controlled from a central location. the releases are
> extensively mirrored by servers all over the place. releases are nigh
> impossible to recall. thus, with the broader audience, the
> consequences for problems are greatly magnified and are not easily
> remedied.



--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

Re: [VOTE] Release Regexp 1.5

On 3/19/07, Jesse Kuhnert wrote:
> Ok so I'm a liar...I did want to point out that from my experience
> even the most formal voting process won't get the desired results -
> that everyone on the project certifies and checks that the binaries
> going out are good. More than likely 90% of the time everyone just
> votes yes or no and trusts that the person managing the release knows
> what they are doing. .....but these are small points.

ah, you say the glass is 90% empty, others might say it is 10% full.
:) at least, release-then-vote provides the opportunity for oversight
of the actual binaries to be released.

> Still, they do
> point to the voting process being meaningless other than all of the
> PMC's putting their names on it if it should go poorly. (though in a
> true team sort of mindset you'd think that this would always be the
> case with / without votes / other processes...)

meaning can be quite relative. as this process is in large part due
to legal, "CYA" necessities, "meaningless" things such as the mere
opportunity for oversight of those bits and any actual (and perhaps
even perceived) PMC oversight are important to the foundation. our
best bet here is to automate the oversight as much as possible to ease
the burden of the process. i will definitely be giving this ARAT tool
a look.

> Automation is good. Esp. if it lets us opt to always trust committer X
> managing a release once and let a diligent little script do everything
> else for else without any intervention. That would be great and would
> bring me back to where I already was. ;)
>
> On 3/19/07, Nathan Bubna wrote:
>
> > the actual bits that are distributed as an officially endorsed release
> > do not have the luxury of diffs sent to the development lists, nor are
> > they easily controlled from a central location. the releases are
> > extensively mirrored by servers all over the place. releases are nigh
> > impossible to recall. thus, with the broader audience, the
> > consequences for problems are greatly magnified and are not easily
> > remedied.
>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

Re: [VOTE] Release Regexp 1.5

On 3/19/07, Jesse Kuhnert wrote:
> Sure, of course it's ok for the ASF to dictate policies - I just hope
> it's ok for me to question them / point out their flaws.
>
> So the real problem as far as I can tell is making sure a release is
> legitimately licensed. There are other things like software quality,
> but I guess it's assumed (by me at least) that we're all trying to
> release as high a caliber of software as we are able given our
> resources / time.
>
> Somehow this still doesn't feel like a legitimate problem, or at least
> it is not consistent with the rest of our daily practices. ..Like
> committing a change to subversion. As far as I can tell there is no
> legal difference between subversion repositories and released software
> - is there? Isn't the end goal to prevent any naughty code coming out
> of apache period? Non conforming code sitting in subversion would
> appear to be just as guilty as anything else...So given your current
> logic shouldn't we all be required to have a PMC vote for each commit
> made into the repo?
>
> It just feels like we're being treated a little bit like incompetents
> in some way. Like maybe someone accidentally made a bad release once
> or twice and so we must all suffer the same solution that they have.

There are all sorts of things that can go wrong when cutting a release
- an example the other day - Tomcat 5.5.23 had/has a problem because
the RM didn't have a jar in his local environment - its not a
guarantee I know (Tomcat produce artifacts to vote on before release!)
- but the more pairs of eyes checking out the distro before it goes
out has got to be a good thing. Its not about incompetance, just
catching mistakes before rather than after. I also don't get your
"suffering" point - most projects can produce a RC quickly - Tag &
Build - doesn't take long - so where is the suffering in doing that
before calling a vote?

Niall

> Ehh...Obviously I'm alone in my opinion so I'll shut up now, just
> wanted to make sure I got my two cents in.
>
> On 3/19/07, J Aaron Farr wrote:
> > "Jesse Kuhnert" writes:
> >
> > > You have to be kidding me..
> > >
> > > The only problem I see is that people are all caught up in policies /
> > > processes but I've yet to hear what the actual root "problem" is. I'm
> > > sure it's intended to somehow prevent something nasty that has
> > > happened in the past but these policies don't have any logic that I'm
> > > able to follow. Why does the ASF need to dictate how we vote on
> > > releases?
> > >
> > > Maybe I'm just having a bad morning, but for some reason this really
> > > rubs me the wrong way and feels extremely inefficient.
> >
> > The problem is that Vote-Then-Release leaves opportunities for the
> > small details to get missed and you end up with a sloppy release.
> > Examples include non-signed distributables, incomplete legal notices,
> > missing or incorrect hashes. The worst is someone slipping in some
> > malicious code in between the time the vote is cast and the release is
> > made.
> >
> > When a PMC votes on a release they should be approving the exact bits
> > that hit the mirrors. That vote binds the ASF to be _legally_
> > responsible. The only way to have sufficient and appropriate
> > oversight is to give the PMC a chance to check that these final steps
> > of a release have been properly handled. Otherwise the PMC risks
> > releasing a half baked product.
> >
> > It is completely appropriate for the ASF to set guidelines on release
> > procedures.
> >
> > --
> > jaaron (who is not on the Jakarta PMC)

Re: [VOTE] Release Regexp 1.5

Something being a good idea and being "required ASF policy" are really
very different things.

The suffering is in the implication that I'm not already being
careful. That we're not all supposed to be slightly better than
average developers with the apache branding and all. The fact that
it's ok to send me emails telling me I'm part of a "problem project"
because I haven't followed some new guidelines put in place because of
other peoples mistakes - mistakes I haven't even made ....is really
just insulting and annoying.

I wonder how often these kinds of emails come out on the google code
or sourceforge lists? :/

On 3/19/07, Niall Pemberton wrote:

> There are all sorts of things that can go wrong when cutting a release
> - an example the other day - Tomcat 5.5.23 had/has a problem because
> the RM didn't have a jar in his local environment - its not a
> guarantee I know (Tomcat produce artifacts to vote on before release!)
> - but the more pairs of eyes checking out the distro before it goes
> out has got to be a good thing. Its not about incompetance, just
> catching mistakes before rather than after. I also don't get your
> "suffering" point - most projects can produce a RC quickly - Tag &
> Build - doesn't take long - so where is the suffering in doing that
> before calling a vote?
>
> Niall



--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

Re: [VOTE] Release Regexp 1.5

------=_Part_135296_31663500.1174336851729
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 3/19/07, Jesse Kuhnert wrote:
>
> Something being a good idea and being "required ASF policy" are really
> very different things.
>
> The suffering is in the implication that I'm not already being
> careful.


So you've never made a mistake in your life? And you're willing to bet a law
suit on continuing to never make a mistake?

That we're not all supposed to be slightly better than
> average developers with the apache branding and all. The fact that
> it's ok to send me emails telling me I'm part of a "problem project"
> because I haven't followed some new guidelines put in place because of
> other peoples mistakes - mistakes I haven't even made ....is really
> just insulting and annoying.
>
> I wonder how often these kinds of emails come out on the google code
> or sourceforge lists? :/


Those sites provide infrastructure, but absolutely no legal protection.

--
Martin Cooper


On 3/19/07, Niall Pemberton wrote:
>
> > There are all sorts of things that can go wrong when cutting a release
> > - an example the other day - Tomcat 5.5.23 had/has a problem because
> > the RM didn't have a jar in his local environment - its not a
> > guarantee I know (Tomcat produce artifacts to vote on before release!)
> > - but the more pairs of eyes checking out the distro before it goes
> > out has got to be a good thing. Its not about incompetance, just
> > catching mistakes before rather than after. I also don't get your
> > "suffering" point - most projects can produce a RC quickly - Tag &
> > Build - doesn't take long - so where is the suffering in doing that
> > before calling a vote?
> >
> > Niall
>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

------=_Part_135296_31663500.1174336851729--

Re: [VOTE] Release Regexp 1.5

Martin Cooper wrote:
> Those sites provide infrastructure, but absolutely no legal protection.

Who says there is no way to combine legal protection and non-absurd procedures?
For example: community votes for a release, RM tags a release (and prepares
files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC composition
change process), done.

And the big one. The main goal ASF exists for is fostering software development
communities. With second goal being software released in the process. And the
legal part here is an *evil necessity*, it is *not* a goal.

Vadim

Re: [VOTE] Release Regexp 1.5

------=_Part_135937_21201102.1174339207016
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 3/19/07, Vadim Gritsenko wrote:
>
> Martin Cooper wrote:
> > Those sites provide infrastructure, but absolutely no legal protection.
>
> Who says there is no way to combine legal protection and non-absurd
> procedures?


Not me. We don't have absurd procedures, so we're already there.

For example: community votes for a release, RM tags a release (and prepares
> files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC
> composition
> change process), done.


PMCs are not about rubber-stamping anything. They are about project
oversight and responsibility.

And the big one. The main goal ASF exists for is fostering software
> development
> communities. With second goal being software released in the process. And
> the
> legal part here is an *evil necessity*, it is *not* a goal.


Interesting perspective. But my reading of the first couple of sentences of
this page suggests otherwise:

http://www.apache.org/foundation/

--
Martin Cooper


Vadim
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

------=_Part_135937_21201102.1174339207016--

Re: [VOTE] Release Regexp 1.5

On Mon, 2007-03-19 at 19:01 +0100, Oleg Kalnichevski wrote:

[... on vote-then-release ...]

Trust me, I have done my share of releases this way, too. The thing is,
that while it was/is common practice, there are ASF-wide guidelines that
are not there to hinder people / add administrative barriers / whatever
but to provide two things:

* Oversight
* Legal shielding

That is the difference between your private pet peeve that releases as
it wishes and a legal entity as the ASF, its acting officers (board /
PMC chairs) and its committers.

>From a technical PoV, I'm fully with you. However, this is not a
technical issue as you have probably found out by now.

Best regards
Henning

> In Commons HttpClient / HttpComponents land we historically voted on SVN
> revisions and published release packages based on a lazy consensus if no
> one raised complaints about the content of the release packages.
>
> Oleg
>
> > On 3/19/07, J Aaron Farr wrote:
> > > "Jesse Kuhnert" writes:
> > >
> > > > You have to be kidding me..
> > > >
> > > > The only problem I see is that people are all caught up in policies /
> > > > processes but I've yet to hear what the actual root "problem" is. I'm
> > > > sure it's intended to somehow prevent something nasty that has
> > > > happened in the past but these policies don't have any logic that I'm
> > > > able to follow. Why does the ASF need to dictate how we vote on
> > > > releases?
> > > >
> > > > Maybe I'm just having a bad morning, but for some reason this really
> > > > rubs me the wrong way and feels extremely inefficient.
> > >
> > > The problem is that Vote-Then-Release leaves opportunities for the
> > > small details to get missed and you end up with a sloppy release.
> > > Examples include non-signed distributables, incomplete legal notices,
> > > missing or incorrect hashes. The worst is someone slipping in some
> > > malicious code in between the time the vote is cast and the release is
> > > made.
> > >
> > > When a PMC votes on a release they should be approving the exact bits
> > > that hit the mirrors. That vote binds the ASF to be _legally_
> > > responsible. The only way to have sufficient and appropriate
> > > oversight is to give the PMC a chance to check that these final steps
> > > of a release have been properly handled. Otherwise the PMC risks
> > > releasing a half baked product.
> > >
> > > It is completely appropriate for the ASF to set guidelines on release
> > > procedures.
> > >
> > > --
> > > jaaron (who is not on the Jakarta PMC)
> > >
> > > ------------------------------------------------------------ ---------
> > > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: general-help@jakarta.apache.org
> > >
> > >
> >
> >
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org

Re: [VOTE] Release Regexp 1.5

Martin Cooper wrote:
> On 3/19/07, Vadim Gritsenko wrote:
>> Martin Cooper wrote:
>> > Those sites provide infrastructure, but absolutely no legal protection.
>>
>> Who says there is no way to combine legal protection and non-absurd
>> procedures?
>
> Not me. We don't have absurd procedures, so we're already there.

I consider tag before vote as absurd.


>> For example: community votes for a release, RM tags a release (and prepares
>> files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC
>> composition change process), done.
>
> PMCs are not about rubber-stamping anything. They are about project
> oversight and responsibility.

Oversight and responsibility is happening before you tag. They are part of day
to day work. Mechanical checks for NOTICE and LICENSE files preceding approval
for distribution stamp happen after.


>> And the big one. The main goal ASF exists for is fostering software
>> development
>> communities. With second goal being software released in the process. And
>> the legal part here is an *evil necessity*, it is *not* a goal.
>
> Interesting perspective.

Thanks.

Vadim

Re: [VOTE] Release Regexp 1.5

On 3/19/07, Vadim Gritsenko wrote:
> Martin Cooper wrote:
> > Those sites provide infrastructure, but absolutely no legal protection.
>
> Who says there is no way to combine legal protection and non-absurd procedures?
> For example: community votes for a release, RM tags a release (and prepares
> files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC composition
> change process), done.
>
> And the big one. The main goal ASF exists for is fostering software development
> communities. With second goal being software released in the process. And the
> legal part here is an *evil necessity*, it is *not* a goal.

lack of legal protection can be pretty detrimental to a software
development community. i'd say it's an essential, non-secondary part
of the ASF's fostering of dev communities.

> Vadim
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

Re: [VOTE] Release Regexp 1.5

------=_Part_136389_18903192.1174340720963
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 3/19/07, Vadim Gritsenko wrote:
>
> Martin Cooper wrote:
> > On 3/19/07, Vadim Gritsenko wrote:
> >> Martin Cooper wrote:
> >> > Those sites provide infrastructure, but absolutely no legal
> protection.
> >>
> >> Who says there is no way to combine legal protection and non-absurd
> >> procedures?
> >
> > Not me. We don't have absurd procedures, so we're already there.
>
> I consider tag before vote as absurd.


Yeah, well I consider voting on something that doesn't exist yet to be
absurd. So there we are.

By the way, if you really want to change any of this, burying the discussion
in a vote thread on this list isn't the best way to go about it.

--
Martin Cooper


>> For example: community votes for a release, RM tags a release (and
> prepares
> >> files), pmc rubber-stamps it with 'ACK' within 72 hours (a-la PMC
> >> composition change process), done.
> >
> > PMCs are not about rubber-stamping anything. They are about project
> > oversight and responsibility.
>
> Oversight and responsibility is happening before you tag. They are part of
> day
> to day work. Mechanical checks for NOTICE and LICENSE files preceding
> approval
> for distribution stamp happen after.
>
>
> >> And the big one. The main goal ASF exists for is fostering software
> >> development
> >> communities. With second goal being software released in the process.
> And
> >> the legal part here is an *evil necessity*, it is *not* a goal.
> >
> > Interesting perspective.
>
> Thanks.
>
> Vadim
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

------=_Part_136389_18903192.1174340720963--

Re: [VOTE] Release Regexp 1.5

>
>
> Yeah, well I consider voting on something that doesn't exist yet to be
> absurd. So there we are.
>
This whole thread is absurd. There is no technical issue here.

cvs tag FOOBAR_1_0_RC1
ant
scp...
....crickets...
cvs TAG FOOBAR_1_0
ssh...
mv FOOBAR_1.0-RC1... FOOBAR_1.0-final...

-andy

--
From Windows/Exchange to Linux/Meldware
Buni Meldware Communication Suite
Email, Calendaring, ease of configuration/administration
http://buni.org

Re: [VOTE] Release Regexp 1.5

Martin Cooper wrote:
> On 3/19/07, Vadim Gritsenko wrote:
>>
>> Martin Cooper wrote:
>> > On 3/19/07, Vadim Gritsenko wrote:
>> >> Martin Cooper wrote:
>> >> > Those sites provide infrastructure, but absolutely no legal
>> >> > protection.
>> >>
>> >> Who says there is no way to combine legal protection and non-absurd
>> >> procedures?
>> >
>> > Not me. We don't have absurd procedures, so we're already there.
>>
>> I consider tag before vote as absurd.
>
> Yeah, well I consider voting on something that doesn't exist yet to be
> absurd. So there we are.

You tagging --> voluntarism; you tagging after a vote --> community supported
decision.

> By the way, if you really want to change any of this, burying the
> discussion
> in a vote thread on this list isn't the best way to go about it.

If there is no consensus, there is no point of pushing it.

Vadim

Re: [VOTE] Release Regexp 1.5

I always prefer to optimize my loops by unrolling them and doing each
step differently.

Funny to talk about pattern matching in a regexp thread :-D

Burnt from my release time to have Yegor chew through some POI bugs ...

Regards,
Dave

On Mar 19, 2007, at 5:41 PM, Andrew C. Oliver wrote:

>
>>
>>
>> Yeah, well I consider voting on something that doesn't exist yet
>> to be
>> absurd. So there we are.
>>
> This whole thread is absurd. There is no technical issue here.
> cvs tag FOOBAR_1_0_RC1
> ant
> scp...
> ...crickets...
> cvs TAG FOOBAR_1_0
> ssh...
> mv FOOBAR_1.0-RC1... FOOBAR_1.0-final...
>
> -andy
>
> --
>> From Windows/Exchange to Linux/Meldware
> Buni Meldware Communication Suite
> Email, Calendaring, ease of configuration/administration
> http://buni.org
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

Re: [VOTE] Release Regexp 1.5

On 3/14/07, Vadim Gritsenko wrote:
> sebb wrote:
> >> Also I think I need to update
> >> headers as per [3], is that correct?
> >
> > You also need a NOTICE file [3]
>
> Updated license headers, added NOTICE to zip/tar.gz.

The NOTICE file is missing the copyright statement - see:

http://www.apache.org/legal/src-headers.html

Niall

Re: [VOTE] Release Regexp 1.5

On 3/18/07, Henri Yandell wrote:
> On 3/14/07, Vadim Gritsenko wrote:
> > Henning Schmiedehausen wrote:
>
> > > You actually have to roll and sign a tarball/zip ball on which the vote
> > > happens. "Release-then-Vote" seems to be the only accepted way by the
> > > board these days;
> >
> > Thankfully, neither events in velocity-private nor board feelings apply here.
> > Either Jakarta PMC votes for it or receives an resolution, before that happens,
> > existing procedures [1] stay.
>
> There are (to my knowledge) three types of vote/release styles that
> have been happening at the ASF.
>
> 1) A vote to do a release, with no sign of release files. This is how
> this thread started and it's against ASF policy.
>
> 2) A vote on release-candidate files (or -dev in your case), and then
> a release that is trusted to be a repeat of the process used. This is
> currently a grey area policy-wise, and is where this release moved to
> with the ~/vgritsenko/*-dev files.
>
> 3) Creating the actual files that are going to be released and voting
> on them. There's pressure to go this way, but it's not the policy yet.
>
> > > personally I do prefer "Vote-then-Release" myself but
> > > that seems to be the way it is.
>
> Release-then-Vote has some nice parts, the actual release is really
> easy. That's nice if the release process has been painful as it means
> I don't have to remember how to do the damn thing. Vote-then-Release
> is nice in that you don't end up doing as many vote builds.
>
> Other parts of the ASF seem to do a release where they make a build
> and if it passes a vote it goes out, if it doesn't then they up the
> bugfix number and do it again (I don't think anyone actually has a
> build number, ie: 1.3.5.7). They also have an alpha/beta/GA thing that
> the version number doesn't show. Very confusing as a user I think.
>
> Mostly at this stage the mandate is that we have to be voting on
> release files, not on "Hey, how about a release".

This has been a pointless thread. Most of the people on the thread are
Members, so if someone could kick it off on members@ then I think
you'll see a much more informed discussion going on.

This 'how we release' conversation has been bouncing around the ASF
for 4 months now, the above is my best grok on the summary. I've not
seen anyone yet speaking in favour of a view that we should have a
vote on the idea of releasing and then someone does it when they can.
Please bring that up on members@ Vadim - good luck.

The reason for members existing (imo) is to provide a backbone to an
otherwise disparate and completely unrelated huge set of communities.
That means showing a bit more empathy and a bit less round and round
arguments.

Course, I'm grumpy and I've got zero patience for reading mailing list
threads over 5 emails nowadays for some reason.

Hen

Re: [VOTE] Release Regexp 1.5

On 3/19/07, Jesse Kuhnert wrote:
> Something being a good idea and being "required ASF policy" are really
> very different things.
>
> The suffering is in the implication that I'm not already being
> careful. That we're not all supposed to be slightly better than
> average developers with the apache branding and all. The fact that
> it's ok to send me emails telling me I'm part of a "problem project"
> because I haven't followed some new guidelines put in place because of
> other peoples mistakes - mistakes I haven't even made ....is really
> just insulting and annoying.
>


Unsure what emails, annoyances etc. you were talking about so I tried
to look at Tapestry list archives (I guess thats what you are refering
to?) -- specifically looked for things like votes, discussions about
releases etc. Now I can't find a vote for v5.0.3 (maybe I missed it,
maybe votes are on the private list -- I don't know), but if what you
are saying above is that there is no need to vote at all, that goes
against what has been described elsewhere in this thread as "community
consensus", and appears completely different from the discussion here
(timing of the vote).

-Rahul


> I wonder how often these kinds of emails come out on the google code
> or sourceforge lists? :/
>
> On 3/19/07, Niall Pemberton wrote:
>
> > There are all sorts of things that can go wrong when cutting a release
> > - an example the other day - Tomcat 5.5.23 had/has a problem because
> > the RM didn't have a jar in his local environment - its not a
> > guarantee I know (Tomcat produce artifacts to vote on before release!)
> > - but the more pairs of eyes checking out the distro before it goes
> > out has got to be a good thing. Its not about incompetance, just
> > catching mistakes before rather than after. I also don't get your
> > "suffering" point - most projects can produce a RC quickly - Tag &
> > Build - doesn't take long - so where is the suffering in doing that
> > before calling a vote?
> >
> > Niall
>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>

Re: [VOTE] Release Regexp 1.5

Niall Pemberton wrote:
> On 3/14/07, Vadim Gritsenko wrote:
>> sebb wrote:
>> >> Also I think I need to update
>> >> headers as per [3], is that correct?
>> >
>> > You also need a NOTICE file [3]
>>
>> Updated license headers, added NOTICE to zip/tar.gz.
>
> The NOTICE file is missing the copyright statement - see:

Thanks, Niall. Corrected.

Vadim

Re: [VOTE] Release Regexp 1.5

Henri Yandell wrote:
> This 'how we release' conversation has been bouncing around the ASF
> for 4 months now, the above is my best grok on the summary. I've not
> seen anyone yet speaking in favour of a view that we should have a
> vote on the idea of releasing and then someone does it when they can.
> Please bring that up on members@ Vadim - good luck.

That is a tough crowd and I don't think I have enough skills to convince them on
anything. OTOH, you can. It's pity though that ASF is loosing its values.

Vadim

Re: [VOTE] Release Regexp 1.5

----- Original Message -----
From: "Rahul Akolkar"
To: "Jakarta General List"
Sent: Tuesday, March 20, 2007 7:39 AM
Subject: Re: [VOTE] Release Regexp 1.5


> On 3/19/07, Jesse Kuhnert wrote:
>> Something being a good idea and being "required ASF policy" are really
>> very different things.
>>
>> The suffering is in the implication that I'm not already being
>> careful. That we're not all supposed to be slightly better than
>> average developers with the apache branding and all. The fact that
>> it's ok to send me emails telling me I'm part of a "problem project"
>> because I haven't followed some new guidelines put in place because of
>> other peoples mistakes - mistakes I haven't even made ....is really
>> just insulting and annoying.
>>
>
>
> Unsure what emails, annoyances etc. you were talking about so I tried
> to look at Tapestry list archives (I guess thats what you are refering
> to?) -- specifically looked for things like votes, discussions about
> releases etc. Now I can't find a vote for v5.0.3 (maybe I missed it,
> maybe votes are on the private list -- I don't know), but if what you
> are saying above is that there is no need to vote at all, that goes
> against what has been described elsewhere in this thread as "community
> consensus", and appears completely different from the discussion here
> (timing of the vote).
>
> -Rahul
>
>
>> I wonder how often these kinds of emails come out on the google code
>> or sourceforge lists? :/
>>
>> On 3/19/07, Niall Pemberton wrote:
>>
>> > There are all sorts of things that can go wrong when cutting a release
>> > - an example the other day - Tomcat 5.5.23 had/has a problem because
>> > the RM didn't have a jar in his local environment - its not a
>> > guarantee I know (Tomcat produce artifacts to vote on before release!)
>> > - but the more pairs of eyes checking out the distro before it goes
>> > out has got to be a good thing. Its not about incompetance, just
>> > catching mistakes before rather than after. I also don't get your
>> > "suffering" point - most projects can produce a RC quickly - Tag &
>> > Build - doesn't take long - so where is the suffering in doing that
>> > before calling a vote?
>> >
>> > Niall
>>
>>
>>
>> --
>> Jesse Kuhnert
>> Tapestry/Dojo team member/developer
>>
>> Open source based consulting work centered around
>> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo. com

Re: [VOTE] Release Regexp 1.5

Henri,

I appreciate what you did to help the POI project stand up and meet
Apache requirements. It is an ongoing process - I think the
subproject is close to doing it correctly and having a successful
release!

Cheers!

Dave Fisher

On Mar 19, 2007, at 10:58 PM, Henri Yandell wrote:

> On 3/18/07, Henri Yandell wrote:
>> On 3/14/07, Vadim Gritsenko wrote:
>> > Henning Schmiedehausen wrote:
>>
>> > > You actually have to roll and sign a tarball/zip ball on which
>> the vote
>> > > happens. "Release-then-Vote" seems to be the only accepted way
>> by the
>> > > board these days;
>> >
>> > Thankfully, neither events in velocity-private nor board
>> feelings apply here.
>> > Either Jakarta PMC votes for it or receives an resolution,
>> before that happens,
>> > existing procedures [1] stay.
>>
>> There are (to my knowledge) three types of vote/release styles that
>> have been happening at the ASF.
>>
>> 1) A vote to do a release, with no sign of release files. This is how
>> this thread started and it's against ASF policy.
>>
>> 2) A vote on release-candidate files (or -dev in your case), and then
>> a release that is trusted to be a repeat of the process used. This is
>> currently a grey area policy-wise, and is where this release moved to
>> with the ~/vgritsenko/*-dev files.
>>
>> 3) Creating the actual files that are going to be released and voting
>> on them. There's pressure to go this way, but it's not the policy
>> yet.
>>
>> > > personally I do prefer "Vote-then-Release" myself but
>> > > that seems to be the way it is.
>>
>> Release-then-Vote has some nice parts, the actual release is really
>> easy. That's nice if the release process has been painful as it means
>> I don't have to remember how to do the damn thing. Vote-then-Release
>> is nice in that you don't end up doing as many vote builds.
>>
>> Other parts of the ASF seem to do a release where they make a build
>> and if it passes a vote it goes out, if it doesn't then they up the
>> bugfix number and do it again (I don't think anyone actually has a
>> build number, ie: 1.3.5.7). They also have an alpha/beta/GA thing
>> that
>> the version number doesn't show. Very confusing as a user I think.
>>
>> Mostly at this stage the mandate is that we have to be voting on
>> release files, not on "Hey, how about a release".
>
> This has been a pointless thread. Most of the people on the thread are
> Members, so if someone could kick it off on members@ then I think
> you'll see a much more informed discussion going on.
>
> This 'how we release' conversation has been bouncing around the ASF
> for 4 months now, the above is my best grok on the summary. I've not
> seen anyone yet speaking in favour of a view that we should have a
> vote on the idea of releasing and then someone does it when they can.
> Please bring that up on members@ Vadim - good luck.
>
> The reason for members existing (imo) is to provide a backbone to an
> otherwise disparate and completely unrelated huge set of communities.
> That means showing a bit more empathy and a bit less round and round
> arguments.
>
> Course, I'm grumpy and I've got zero patience for reading mailing list
> threads over 5 emails nowadays for some reason.
>
> Hen
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

Re: [VOTE] Release Regexp 1.5

On 3/20/07, Vadim Gritsenko wrote:
> Henri Yandell wrote:
> > This 'how we release' conversation has been bouncing around the ASF
> > for 4 months now, the above is my best grok on the summary. I've not
> > seen anyone yet speaking in favour of a view that we should have a
> > vote on the idea of releasing and then someone does it when they can.
> > Please bring that up on members@ Vadim - good luck.
>
> That is a tough crowd and I don't think I have enough skills to convince them on
> anything. OTOH, you can. It's pity though that ASF is loosing its values.

Problem is that that's the crowd who need to be convinced. Otherwise
we're just sitting here spinning around and around.

It's less that it's losing its values and more that it's increasingly
pushing to have one set of values.


Apache begat itself. Then it begat Jakarta somehow. Things were good.
Then Apache looked at Jakarta and it was not pleased for things were
not the same. It argued with itself and declared that things would be
the same. All was good.



The next day Apache looked at itself and was shocked and amazed to
find that declaring all things to be equal had not made things equal.
In the Outer Rim there were projects and committers who had not heard
the declaration and were not doing things in the same way. Indeed they
had the temerity to do things the same way they'd always done things.
Apache was not happy.



Apache gets married, finds a little house in the suburbs and raises
little apachlets. But that's another story.


So not losing values - these are Jakarta values that we relinquished 5
years ago.

On the "OTOH"... I've not got the patience for such convincing atm :)

Hen

Re: [VOTE] Release Regexp 1.5

As long as the analogies are going I thought I'd continue the story
with more of my own....


Things continue for a while. Mike is happy, Apache is happy. All is
well. Mike continues his life long passion of being a master carpenter
and Apache helps raise the family. What could be better?

....Then one day Mike comes into his workshop and finds that someone
has taken it upon themselves to add two more clamps to his existing
two clamps on the piece he is currently working on. That's odd...What
the hell?

Mike confronts Apache. "Oh that, yes we've all decided that from now
on you'll need to use exactly twice the number of clamps you normally
do. You see - Codehauses husband Bob had a little accident the other
day. Nothing fatal but no one wants to take any chances...I'm sure you
understand. " Mike protested, thought that maybe it was bad that Bob
had such a scare but why did that have to affect him? It was of no
use. Apache had made up her mind and that was final..

Mike went back to his shop and tried this for a few days....But
eventually he just couldn't do it anymore. He pleaded with Apache
again but still she refused. Said that a decision had been made for
the good of all and he'd just have to accept it or move out.
Eventually Mike did move out.

You see, Apache had the unfortunate luck to marry someone with
aspbergers. If you don't know what that means a very easy reference
would be the beloved Mr. Spock. Quite funny I know, but if you
actually are Spock there's nothing funny about it. Just like there was
nothing funny about Mike placing extra clamps on his equipment when he
knew there was absolutely no point in doing it other than pleasing his
beloved Apache and her insufferable friends. No ...you might as well
ask a dog to stop sniffing other dogs asses, a computer to stop
computing ..He had no choice. It wasn't something he could live with
no matter how much he loved Apache.

......


On 3/20/07, Henri Yandell wrote:

>
> Apache gets married, finds a little house in the suburbs and raises
> little apachlets. But that's another story.
>
>
> So not losing values - these are Jakarta values that we relinquished 5
> years ago.
>
> On the "OTOH"... I've not got the patience for such convincing atm :)
>
> Hen
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>


--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com