You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@lucy.apache.org by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov> on 2011/05/20 23:18:37 UTC

[lucy-user] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Hi Folks,

I am proud to announce the first candidate for the Apache Lucy  0.1-incubating 
release. The source code is at:

http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/

For more detailed information, see the included CHANGES file for details on
release contents and latest changes. The release was made using the Lucy
release process, documented on the Wiki here:

http://wiki.apache.org/lucy/ReleaseGuide

The release was made from the Lucy 0.1-incubating branch (r1125570) at:

https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating

The release built fine for me and all tests passed:

All tests successful, 2 tests and 10 subtests skipped.
Files=169, Tests=10465, 24 wallclock secs (16.88 cusr +  3.27 csys = 20.15 CPU)
[chipotle:0.1-incubating-release/apache-lucy-0.1-incubating/perl] mattmann% 

Please vote on releasing these packages as Apache Lucy 0.1-incubating. The vote is
open for the next 72 hours.

Only votes from Incubator PMC are binding, but folks are welcome to check the
release candidate and voice their approval or disapproval. The vote passes
if at least three binding +1 votes are cast.

[ ] +1 Release the packages as Apache Lucy 0.1-incubating
[ ] +0 Don't care
[ ] -1 Do not release the packages as Apache Lucy 0.1-incubating because...

Thanks!

Cheers,
Chris

P.S. Here is my +1.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


[lucy-user] Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Joe, hmmm...interesting I grabbed my old Nutch one and threw it into KEYS, but there's a chance that I have a newer Apache key.

Let me check it out...thanks for the +1 regardless I'll update the KEYS file with the right one!

Cheers,
Chris

On May 20, 2011, at 2:26 PM, Joe Schaefer wrote:

> +1, with the caviat that the key in your keys file
> isn't the key you signed this package with.  Please
> add you code-signing key to the KEYS file.
> 
> 
> 
> ----- Original Message ----
>> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
>> To: "lucy-dev@incubator.apache.org" <lu...@incubator.apache.org>
>> Cc: "lucy-user@incubator.apache.org" <lu...@incubator.apache.org>; 
>> "general@incubator.apache.org" <ge...@incubator.apache.org>
>> Sent: Fri, May 20, 2011 5:18:37 PM
>> Subject: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1
>> 
>> Hi Folks,
>> 
>> I am proud to announce the first candidate for the Apache  Lucy  0.1-incubating 
>> 
>> release. The source code is  at:
>> 
>> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/
>> 
>> For  more detailed information, see the included CHANGES file for details  on
>> release contents and latest changes. The release was made using the  Lucy
>> release process, documented on the Wiki  here:
>> 
>> http://wiki.apache.org/lucy/ReleaseGuide
>> 
>> The release was  made from the Lucy 0.1-incubating branch (r1125570) at:
>> 
>> https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating
>> g
>> 
>> The  release built fine for me and all tests passed:
>> 
>> All tests successful, 2  tests and 10 subtests skipped.
>> Files=169, Tests=10465, 24 wallclock secs  (16.88 cusr +  3.27 csys = 20.15  
>> CPU)
>> [chipotle:0.1-incubating-release/apache-lucy-0.1-incubating/perl]  mattmann% 
>> 
>> Please vote on releasing these packages as Apache Lucy  0.1-incubating. The 
>> vote is
>> open for the next 72 hours.
>> 
>> Only votes  from Incubator PMC are binding, but folks are welcome to check the
>> release  candidate and voice their approval or disapproval. The vote passes
>> if at  least three binding +1 votes are cast.
>> 
>> [ ] +1 Release the packages as  Apache Lucy 0.1-incubating
>> [ ] +0 Don't care
>> [ ] -1 Do not release the  packages as Apache Lucy 0.1-incubating  because...
>> 
>> Thanks!
>> 
>> Cheers,
>> Chris
>> 
>> P.S. Here is my  +1.
>> 
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris  Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory  Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattmann@nasa.gov
>> WWW:     http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct  Assistant Professor, Computer Science Department
>> University of Southern  California, Los Angeles, CA 90089  USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 
>> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Joe, hmmm...interesting I grabbed my old Nutch one and threw it into KEYS, but there's a chance that I have a newer Apache key.

Let me check it out...thanks for the +1 regardless I'll update the KEYS file with the right one!

Cheers,
Chris

On May 20, 2011, at 2:26 PM, Joe Schaefer wrote:

> +1, with the caviat that the key in your keys file
> isn't the key you signed this package with.  Please
> add you code-signing key to the KEYS file.
> 
> 
> 
> ----- Original Message ----
>> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
>> To: "lucy-dev@incubator.apache.org" <lu...@incubator.apache.org>
>> Cc: "lucy-user@incubator.apache.org" <lu...@incubator.apache.org>; 
>> "general@incubator.apache.org" <ge...@incubator.apache.org>
>> Sent: Fri, May 20, 2011 5:18:37 PM
>> Subject: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1
>> 
>> Hi Folks,
>> 
>> I am proud to announce the first candidate for the Apache  Lucy  0.1-incubating 
>> 
>> release. The source code is  at:
>> 
>> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/
>> 
>> For  more detailed information, see the included CHANGES file for details  on
>> release contents and latest changes. The release was made using the  Lucy
>> release process, documented on the Wiki  here:
>> 
>> http://wiki.apache.org/lucy/ReleaseGuide
>> 
>> The release was  made from the Lucy 0.1-incubating branch (r1125570) at:
>> 
>> https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating
>> g
>> 
>> The  release built fine for me and all tests passed:
>> 
>> All tests successful, 2  tests and 10 subtests skipped.
>> Files=169, Tests=10465, 24 wallclock secs  (16.88 cusr +  3.27 csys = 20.15  
>> CPU)
>> [chipotle:0.1-incubating-release/apache-lucy-0.1-incubating/perl]  mattmann% 
>> 
>> Please vote on releasing these packages as Apache Lucy  0.1-incubating. The 
>> vote is
>> open for the next 72 hours.
>> 
>> Only votes  from Incubator PMC are binding, but folks are welcome to check the
>> release  candidate and voice their approval or disapproval. The vote passes
>> if at  least three binding +1 votes are cast.
>> 
>> [ ] +1 Release the packages as  Apache Lucy 0.1-incubating
>> [ ] +0 Don't care
>> [ ] -1 Do not release the  packages as Apache Lucy 0.1-incubating  because...
>> 
>> Thanks!
>> 
>> Cheers,
>> Chris
>> 
>> P.S. Here is my  +1.
>> 
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris  Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory  Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattmann@nasa.gov
>> WWW:     http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct  Assistant Professor, Computer Science Department
>> University of Southern  California, Los Angeles, CA 90089  USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 
>> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Joe, hmmm...interesting I grabbed my old Nutch one and threw it into KEYS, but there's a chance that I have a newer Apache key.

Let me check it out...thanks for the +1 regardless I'll update the KEYS file with the right one!

Cheers,
Chris

On May 20, 2011, at 2:26 PM, Joe Schaefer wrote:

> +1, with the caviat that the key in your keys file
> isn't the key you signed this package with.  Please
> add you code-signing key to the KEYS file.
> 
> 
> 
> ----- Original Message ----
>> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
>> To: "lucy-dev@incubator.apache.org" <lu...@incubator.apache.org>
>> Cc: "lucy-user@incubator.apache.org" <lu...@incubator.apache.org>; 
>> "general@incubator.apache.org" <ge...@incubator.apache.org>
>> Sent: Fri, May 20, 2011 5:18:37 PM
>> Subject: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1
>> 
>> Hi Folks,
>> 
>> I am proud to announce the first candidate for the Apache  Lucy  0.1-incubating 
>> 
>> release. The source code is  at:
>> 
>> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/
>> 
>> For  more detailed information, see the included CHANGES file for details  on
>> release contents and latest changes. The release was made using the  Lucy
>> release process, documented on the Wiki  here:
>> 
>> http://wiki.apache.org/lucy/ReleaseGuide
>> 
>> The release was  made from the Lucy 0.1-incubating branch (r1125570) at:
>> 
>> https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating
>> g
>> 
>> The  release built fine for me and all tests passed:
>> 
>> All tests successful, 2  tests and 10 subtests skipped.
>> Files=169, Tests=10465, 24 wallclock secs  (16.88 cusr +  3.27 csys = 20.15  
>> CPU)
>> [chipotle:0.1-incubating-release/apache-lucy-0.1-incubating/perl]  mattmann% 
>> 
>> Please vote on releasing these packages as Apache Lucy  0.1-incubating. The 
>> vote is
>> open for the next 72 hours.
>> 
>> Only votes  from Incubator PMC are binding, but folks are welcome to check the
>> release  candidate and voice their approval or disapproval. The vote passes
>> if at  least three binding +1 votes are cast.
>> 
>> [ ] +1 Release the packages as  Apache Lucy 0.1-incubating
>> [ ] +0 Don't care
>> [ ] -1 Do not release the  packages as Apache Lucy 0.1-incubating  because...
>> 
>> Thanks!
>> 
>> Cheers,
>> Chris
>> 
>> P.S. Here is my  +1.
>> 
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris  Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory  Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattmann@nasa.gov
>> WWW:     http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct  Assistant Professor, Computer Science Department
>> University of Southern  California, Los Angeles, CA 90089  USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 
>> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


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


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by Joe Schaefer <jo...@yahoo.com>.
+1, with the caviat that the key in your keys file
isn't the key you signed this package with.  Please
add you code-signing key to the KEYS file.



----- Original Message ----
> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
> To: "lucy-dev@incubator.apache.org" <lu...@incubator.apache.org>
> Cc: "lucy-user@incubator.apache.org" <lu...@incubator.apache.org>; 
>"general@incubator.apache.org" <ge...@incubator.apache.org>
> Sent: Fri, May 20, 2011 5:18:37 PM
> Subject: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1
> 
> Hi Folks,
> 
> I am proud to announce the first candidate for the Apache  Lucy  0.1-incubating 
>
> release. The source code is  at:
> 
> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/
> 
> For  more detailed information, see the included CHANGES file for details  on
> release contents and latest changes. The release was made using the  Lucy
> release process, documented on the Wiki  here:
> 
> http://wiki.apache.org/lucy/ReleaseGuide
> 
> The release was  made from the Lucy 0.1-incubating branch (r1125570) at:
> 
>https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating
>g
> 
> The  release built fine for me and all tests passed:
> 
> All tests successful, 2  tests and 10 subtests skipped.
> Files=169, Tests=10465, 24 wallclock secs  (16.88 cusr +  3.27 csys = 20.15  
>CPU)
> [chipotle:0.1-incubating-release/apache-lucy-0.1-incubating/perl]  mattmann% 
> 
> Please vote on releasing these packages as Apache Lucy  0.1-incubating. The 
>vote is
> open for the next 72 hours.
> 
> Only votes  from Incubator PMC are binding, but folks are welcome to check the
> release  candidate and voice their approval or disapproval. The vote passes
> if at  least three binding +1 votes are cast.
> 
> [ ] +1 Release the packages as  Apache Lucy 0.1-incubating
> [ ] +0 Don't care
> [ ] -1 Do not release the  packages as Apache Lucy 0.1-incubating  because...
> 
> Thanks!
> 
> Cheers,
> Chris
> 
> P.S. Here is my  +1.
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris  Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory  Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW:     http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct  Assistant Professor, Computer Science Department
> University of Southern  California, Los Angeles, CA 90089  USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 

[lucy-user] Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, May 20, 2011 at 06:30:52PM -0700, Mattmann, Chris A (388J) wrote:
> Hmmm....Sorry but this is the first time I've carefully looked at the
> ReleaseGuide, otherwise if I saw it back when you threw it up on the wiki,
> I'd probably have debated this convention for *artifact names* (note this an
> important distinction -- I'm not debating the programmatic use of version #s
> as is covered below). 

The thing I really care about is the inclusion of all three numbers X.Y.Z in
the artifact names.

For technical reasons documented in that thread, it's essential that the
downstream CPAN artifacts use X.Y.Z consistently.  It strikes me as a bad idea
to have the Apache canonical artifacts sometimes use X.Y and sometimes use
X.Y.Z, sometimes matching downstream and sometimes not.

The version number for this release is either "0.1.0" or "0.1.0-incubating".
It is not "0.1" or "0.1-incubating", because Z is definitely defined as "0".

I should have gone out of my way to fix all usages of "0.1-incubating", such
as in JIRA.  Confusion is understandable, because even though that thread
concludes with a firm decision to use X.Y.Z numbering consistently, we did not
aggressively apply that decision in every nook and cranny or jump up and down
screaming every time somebody subsequently omitted Z.

> Most of the Apache releases I've seen use *artifact names* likes:
> 
> apache-<product>-<version>-<src|bin>.<ext>

The inclusion of "src" wasn't something I considered.  For what it's worth, we
are unlikely to do "bin" releases for Lucy any time soon, because what with
natively compiled code and multiple binding language targets there are so many
possible configurations.  So, I don't know that it's important to include
"src" to differentiate from "bin" releases that may never exist, but it's not
something I have a concrete reason to oppose.
 
The placement of the word "incubating" follows the Incubator documentation.

    http://incubator.apache.org/guides/releasemanagement.html#naming

    The release name should contain the podling name and may contain apache.
    Incubator policy insists that it must also contain 'incubating' (though
    small variations for the sake of readability are usually acceptable). 

    For example, for podling foo, both 'apache-foo-incubating' and
    'foo-incubating' would be acceptable names. 

However, that was not discussed on the Lucy dev list -- it's something I
discovered and revised while distilling down the ReleaseGuide.

I happen to prefer attaching "incubating" to "apache-lucy" rather than the
version number because no code or metadata includes the word "incubating" in
the version number.  However, either way meets the requirements of the
Incubator.  It's more important to me that once we choose one of these
conventions, we use it consistently for as long as we are in the Incubator.

> >    // Actual name
> >    https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating/
> >    // Documented in ReleaseGuide
> >    https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y
> 
> Gotcha. I transposed the branch and tag names.
> 
> Speaking of which though, let me also poke at this. Having 2 conventions for
> tags and branches seems odd to me and it seems like the introduction of
> pointless complexity for little gain. Why not just pick one:
> 
> either:
> 
> apache-lucy-X.Y (e.g., apache-lucy-0.1-incubating)
> 
> or:
> 
> X.Y (e.g., 0.1-incubating)
> 
> Having 2 conventions for branches and tags seems odd to me. 

This branch naming convention was adopted after studying Lucene's branches:

    https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y

> > And there is no tag for the RC as the instructions set out:
> > 
> >    https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-X.Y.Z-rcN
> 
> IMO and experience, tags are created when a release VOTE passes to capture a
> *final* snapshot of the release that's not expected to change. Some other
> projects use tags as the first release VOTE'ing artifact, and then roll a
> branch when the VOTE passes to indicate further development in a series.
> Either way is fine. I'm happy to create the tag, but honestly, this approach
> seems like an RM decision to me and something that we should leave open to
> the guy picking up a shovel and doing the RM'ing.

The end goal of the release tagging procedure is a tag associated with the
final artifacts.  I don't really care how we get there.  The recipe is there
so that future RMs will get to the end goal consistently and not screw up the
tag-to-release-artifacts association.  It was inspired by someone else's
routine -- don't remember whether I got it from Incubator docs, somebody other
TLP's release procedures, or mailing list spelunking.

Marvin Humphrey


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Okey dokey, in the interest of just getting the RC out and moving onto the next set of things to get done, RC 2 coming up...

Cheers,
Chris

On May 20, 2011, at 6:43 PM, Joe Schaefer wrote:

> RM docs are always guides, not decrees, but Marvin is
> certainly within his rights to vote according to the
> current docs.  Keep in mind noone gets to veto a release
> (unless it's on legal grounds, and those should be rare).
> 
> FWIW, I think the full 3-part version string belongs
> in the package name, while the 2-part version string
> belongs in the branch, as that is the point of creating
> the branch in the first place- so you can cut maintainence
> releases from it that are just patch-level changes.  Unfortunately
> CPAN won't be very happy about it, but it's a manageable
> problem.
> 
> The tag issue for rc's I am ambivalent about personally.
> 
> But basically I agree with the existing Lucy docs.  In the interest
> of time, since I know you don't have much more you can spare
> on this effort, I suggest you try to just follow them as-is.
> And lets keep the initial voting confined to dev@lucy as
> Marvin suggests.
> 
> 
> 
> ----- Original Message ----
>> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
>> To: "general@incubator.apache.org" <ge...@incubator.apache.org>
>> Cc: "lucy-dev@incubator.apache.org" <lu...@incubator.apache.org>; 
>> "lucy-user@incubator.apache.org" <lu...@incubator.apache.org>
>> Sent: Fri, May 20, 2011 9:30:52 PM
>> Subject: Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate 
>> #1
>> 
>> Hi Marvin,
>> 
>> On May 20, 2011, at 2:44 PM, Marvin Humphrey  wrote:
>> 
>>> Hi, Chris, thanks for expediting.
>>> 
>>> On Fri,  May 20, 2011 at 02:18:37PM -0700, Mattmann, Chris A (388J) wrote:
>>>> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/
>>> 
>>> The artifacts here do not follow the version naming convention that is  used 
>> by
>>> the source code of X.Y.Z, and that the ReleaseGuide specifies  the artifacts
>>> should use:
>>> 
>>>    apache-lucy-0.1-incubating-src.tar.gz   //  actual name
>>>    apache-lucy-incubating-X.Y.Z.tar.gz     //  documented in  ReleaseGuide.
>> 
>> Hmmm....Sorry but this is the first time I've carefully  looked at the 
>> ReleaseGuide, otherwise if I saw it back when you threw it up on  the wiki, I'd 
>> probably have debated this convention for *artifact names* (note  this an 
>> important distinction -- I'm not debating the programmatic use of  version #s as 
>> is covered below). Most of the Apache releases I've seen use  *artifact names*  
>> likes:
>> 
>> apache-<product>-<version>-<src|bin>.<ext>
>> 
>> In  this case, we're the lucy product, version 0.1-incubating, it's a src 
>> release,  and it's a tar.gz extension.
>> 
>> I think that makes more sense  than:
>> 
>> apache-<product>-incubating-<version>.<ext>
>> 
>>> 
>>> It's essential that our artifacts match the actual version number  strings.
>> 
>> Who are you talking about when you say "our"? I am included in  that set? If 
>> so, I'm not necessarily on board with your proposal for what the  *artfiact 
>> name* should be. Note that the discussion we had on your referenced  thread 
>> below is actually talking about programmatic uses of a string/int/number  
>> version within the context of PL-specific forges like CPAN/Maven  
>> Central/PyPI/etc. It's not talking about artifact names.
>> 
>>> This was  hammered out over a long thread here: <http://s.apache.org/lW>.
>>> 
>>> The branch we will use for bugfixes is also misnamed:
>>> 
>>>   // Actual name
>>> 
>> https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating/
>> 
>>>    // Documented in ReleaseGuide
>>>   https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y
>> 
>> Gotcha.  I transposed the branch and tag names.
>> 
>> Speaking of which though, let me  also poke at this. Having 2 conventions for 
>> tags and branches seems odd to me  and it seems like the introduction of 
>> pointless complexity for little gain. Why  not just pick one:
>> 
>> either:
>> 
>> apache-lucy-X.Y (e.g.,  apache-lucy-0.1-incubating)
>> 
>> or:
>> 
>> X.Y (e.g.,  0.1-incubating)
>> 
>> Having 2 conventions for branches and tags seems odd to  me. 
>> 
>>> 
>>> And there is no tag for the RC as the instructions set  out:
>>> 
>>> 
>> https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-X.Y.Z-rcN
>> 
>> 
>> IMO  and experience, tags are created when a release VOTE passes to capture a  
>> *final* snapshot of the release that's not expected to change. Some other  
>> projects use tags as the first release VOTE'ing artifact, and then roll a branch  
>> when the VOTE passes to indicate further development in a series. Either way is  
>> fine. I'm happy to create the tag, but honestly, this approach seems like an RM  
>> decision to me and something that we should leave open to the guy picking up a  
>> shovel and doing the RM'ing.
>> 
>>> 
>>> I regret that I must vote  -1.  Please change the name of the tag, following
>>> the documentation  in the ReleaseGuide precisely and reroll.  If you 
> disagree
>>> with  anything you encounter, please raise your concern on the dev list.
>> 
>> No  probs. Concerns raised above. 
>> 
>> Cheers,
>> Chris
>> 
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris  Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory  Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattmann@nasa.gov
>> WWW:     http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct  Assistant Professor, Computer Science Department
>> University of Southern  California, Los Angeles, CA 90089  USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 
>> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Okey dokey, in the interest of just getting the RC out and moving onto the next set of things to get done, RC 2 coming up...

Cheers,
Chris

On May 20, 2011, at 6:43 PM, Joe Schaefer wrote:

> RM docs are always guides, not decrees, but Marvin is
> certainly within his rights to vote according to the
> current docs.  Keep in mind noone gets to veto a release
> (unless it's on legal grounds, and those should be rare).
> 
> FWIW, I think the full 3-part version string belongs
> in the package name, while the 2-part version string
> belongs in the branch, as that is the point of creating
> the branch in the first place- so you can cut maintainence
> releases from it that are just patch-level changes.  Unfortunately
> CPAN won't be very happy about it, but it's a manageable
> problem.
> 
> The tag issue for rc's I am ambivalent about personally.
> 
> But basically I agree with the existing Lucy docs.  In the interest
> of time, since I know you don't have much more you can spare
> on this effort, I suggest you try to just follow them as-is.
> And lets keep the initial voting confined to dev@lucy as
> Marvin suggests.
> 
> 
> 
> ----- Original Message ----
>> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
>> To: "general@incubator.apache.org" <ge...@incubator.apache.org>
>> Cc: "lucy-dev@incubator.apache.org" <lu...@incubator.apache.org>; 
>> "lucy-user@incubator.apache.org" <lu...@incubator.apache.org>
>> Sent: Fri, May 20, 2011 9:30:52 PM
>> Subject: Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate 
>> #1
>> 
>> Hi Marvin,
>> 
>> On May 20, 2011, at 2:44 PM, Marvin Humphrey  wrote:
>> 
>>> Hi, Chris, thanks for expediting.
>>> 
>>> On Fri,  May 20, 2011 at 02:18:37PM -0700, Mattmann, Chris A (388J) wrote:
>>>> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/
>>> 
>>> The artifacts here do not follow the version naming convention that is  used 
>> by
>>> the source code of X.Y.Z, and that the ReleaseGuide specifies  the artifacts
>>> should use:
>>> 
>>>    apache-lucy-0.1-incubating-src.tar.gz   //  actual name
>>>    apache-lucy-incubating-X.Y.Z.tar.gz     //  documented in  ReleaseGuide.
>> 
>> Hmmm....Sorry but this is the first time I've carefully  looked at the 
>> ReleaseGuide, otherwise if I saw it back when you threw it up on  the wiki, I'd 
>> probably have debated this convention for *artifact names* (note  this an 
>> important distinction -- I'm not debating the programmatic use of  version #s as 
>> is covered below). Most of the Apache releases I've seen use  *artifact names*  
>> likes:
>> 
>> apache-<product>-<version>-<src|bin>.<ext>
>> 
>> In  this case, we're the lucy product, version 0.1-incubating, it's a src 
>> release,  and it's a tar.gz extension.
>> 
>> I think that makes more sense  than:
>> 
>> apache-<product>-incubating-<version>.<ext>
>> 
>>> 
>>> It's essential that our artifacts match the actual version number  strings.
>> 
>> Who are you talking about when you say "our"? I am included in  that set? If 
>> so, I'm not necessarily on board with your proposal for what the  *artfiact 
>> name* should be. Note that the discussion we had on your referenced  thread 
>> below is actually talking about programmatic uses of a string/int/number  
>> version within the context of PL-specific forges like CPAN/Maven  
>> Central/PyPI/etc. It's not talking about artifact names.
>> 
>>> This was  hammered out over a long thread here: <http://s.apache.org/lW>.
>>> 
>>> The branch we will use for bugfixes is also misnamed:
>>> 
>>>   // Actual name
>>> 
>> https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating/
>> 
>>>    // Documented in ReleaseGuide
>>>   https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y
>> 
>> Gotcha.  I transposed the branch and tag names.
>> 
>> Speaking of which though, let me  also poke at this. Having 2 conventions for 
>> tags and branches seems odd to me  and it seems like the introduction of 
>> pointless complexity for little gain. Why  not just pick one:
>> 
>> either:
>> 
>> apache-lucy-X.Y (e.g.,  apache-lucy-0.1-incubating)
>> 
>> or:
>> 
>> X.Y (e.g.,  0.1-incubating)
>> 
>> Having 2 conventions for branches and tags seems odd to  me. 
>> 
>>> 
>>> And there is no tag for the RC as the instructions set  out:
>>> 
>>> 
>> https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-X.Y.Z-rcN
>> 
>> 
>> IMO  and experience, tags are created when a release VOTE passes to capture a  
>> *final* snapshot of the release that's not expected to change. Some other  
>> projects use tags as the first release VOTE'ing artifact, and then roll a branch  
>> when the VOTE passes to indicate further development in a series. Either way is  
>> fine. I'm happy to create the tag, but honestly, this approach seems like an RM  
>> decision to me and something that we should leave open to the guy picking up a  
>> shovel and doing the RM'ing.
>> 
>>> 
>>> I regret that I must vote  -1.  Please change the name of the tag, following
>>> the documentation  in the ReleaseGuide precisely and reroll.  If you 
> disagree
>>> with  anything you encounter, please raise your concern on the dev list.
>> 
>> No  probs. Concerns raised above. 
>> 
>> Cheers,
>> Chris
>> 
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Chris  Mattmann, Ph.D.
>> Senior Computer Scientist
>> NASA Jet Propulsion Laboratory  Pasadena, CA 91109 USA
>> Office: 171-266B, Mailstop: 171-246
>> Email: chris.a.mattmann@nasa.gov
>> WWW:     http://sunset.usc.edu/~mattmann/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> Adjunct  Assistant Professor, Computer Science Department
>> University of Southern  California, Los Angeles, CA 90089  USA
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> 
>> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


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


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by Joe Schaefer <jo...@yahoo.com>.
RM docs are always guides, not decrees, but Marvin is
certainly within his rights to vote according to the
current docs.  Keep in mind noone gets to veto a release
(unless it's on legal grounds, and those should be rare).

FWIW, I think the full 3-part version string belongs
in the package name, while the 2-part version string
belongs in the branch, as that is the point of creating
the branch in the first place- so you can cut maintainence
releases from it that are just patch-level changes.  Unfortunately
CPAN won't be very happy about it, but it's a manageable
problem.

The tag issue for rc's I am ambivalent about personally.

But basically I agree with the existing Lucy docs.  In the interest
of time, since I know you don't have much more you can spare
on this effort, I suggest you try to just follow them as-is.
And lets keep the initial voting confined to dev@lucy as
Marvin suggests.



----- Original Message ----
> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
> To: "general@incubator.apache.org" <ge...@incubator.apache.org>
> Cc: "lucy-dev@incubator.apache.org" <lu...@incubator.apache.org>; 
>"lucy-user@incubator.apache.org" <lu...@incubator.apache.org>
> Sent: Fri, May 20, 2011 9:30:52 PM
> Subject: Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate 
>#1
> 
> Hi Marvin,
> 
> On May 20, 2011, at 2:44 PM, Marvin Humphrey  wrote:
> 
> > Hi, Chris, thanks for expediting.
> > 
> > On Fri,  May 20, 2011 at 02:18:37PM -0700, Mattmann, Chris A (388J) wrote:
> >>  http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/
> > 
> > The artifacts here do not follow the version naming convention that is  used 
>by
> > the source code of X.Y.Z, and that the ReleaseGuide specifies  the artifacts
> > should use:
> > 
> >     apache-lucy-0.1-incubating-src.tar.gz   //  actual name
> >     apache-lucy-incubating-X.Y.Z.tar.gz     //  documented in  ReleaseGuide.
> 
> Hmmm....Sorry but this is the first time I've carefully  looked at the 
>ReleaseGuide, otherwise if I saw it back when you threw it up on  the wiki, I'd 
>probably have debated this convention for *artifact names* (note  this an 
>important distinction -- I'm not debating the programmatic use of  version #s as 
>is covered below). Most of the Apache releases I've seen use  *artifact names*  
>likes:
> 
> apache-<product>-<version>-<src|bin>.<ext>
> 
> In  this case, we're the lucy product, version 0.1-incubating, it's a src 
>release,  and it's a tar.gz extension.
> 
> I think that makes more sense  than:
> 
> apache-<product>-incubating-<version>.<ext>
> 
> > 
> > It's essential that our artifacts match the actual version number  strings.
> 
> Who are you talking about when you say "our"? I am included in  that set? If 
>so, I'm not necessarily on board with your proposal for what the  *artfiact 
>name* should be. Note that the discussion we had on your referenced  thread 
>below is actually talking about programmatic uses of a string/int/number  
>version within the context of PL-specific forges like CPAN/Maven  
>Central/PyPI/etc. It's not talking about artifact names.
> 
> > This was  hammered out over a long thread here: <http://s.apache.org/lW>.
> > 
> > The branch we will use for bugfixes is also misnamed:
> > 
> >    // Actual name
> >    
>https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating/
>
> >     // Documented in ReleaseGuide
> >    https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y
> 
> Gotcha.  I transposed the branch and tag names.
> 
> Speaking of which though, let me  also poke at this. Having 2 conventions for 
>tags and branches seems odd to me  and it seems like the introduction of 
>pointless complexity for little gain. Why  not just pick one:
> 
> either:
> 
> apache-lucy-X.Y (e.g.,  apache-lucy-0.1-incubating)
> 
> or:
> 
> X.Y (e.g.,  0.1-incubating)
> 
> Having 2 conventions for branches and tags seems odd to  me. 
> 
> > 
> > And there is no tag for the RC as the instructions set  out:
> > 
> >    
>https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-X.Y.Z-rcN
>
> 
> IMO  and experience, tags are created when a release VOTE passes to capture a  
>*final* snapshot of the release that's not expected to change. Some other  
>projects use tags as the first release VOTE'ing artifact, and then roll a branch  
>when the VOTE passes to indicate further development in a series. Either way is  
>fine. I'm happy to create the tag, but honestly, this approach seems like an RM  
>decision to me and something that we should leave open to the guy picking up a  
>shovel and doing the RM'ing.
> 
> > 
> > I regret that I must vote  -1.  Please change the name of the tag, following
> > the documentation  in the ReleaseGuide precisely and reroll.  If you 
disagree
> > with  anything you encounter, please raise your concern on the dev list.
> 
> No  probs. Concerns raised above. 
> 
> Cheers,
> Chris
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris  Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory  Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW:     http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct  Assistant Professor, Computer Science Department
> University of Southern  California, Los Angeles, CA 90089  USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 

Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by Joe Schaefer <jo...@yahoo.com>.
RM docs are always guides, not decrees, but Marvin is
certainly within his rights to vote according to the
current docs.  Keep in mind noone gets to veto a release
(unless it's on legal grounds, and those should be rare).

FWIW, I think the full 3-part version string belongs
in the package name, while the 2-part version string
belongs in the branch, as that is the point of creating
the branch in the first place- so you can cut maintainence
releases from it that are just patch-level changes.  Unfortunately
CPAN won't be very happy about it, but it's a manageable
problem.

The tag issue for rc's I am ambivalent about personally.

But basically I agree with the existing Lucy docs.  In the interest
of time, since I know you don't have much more you can spare
on this effort, I suggest you try to just follow them as-is.
And lets keep the initial voting confined to dev@lucy as
Marvin suggests.



----- Original Message ----
> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
> To: "general@incubator.apache.org" <ge...@incubator.apache.org>
> Cc: "lucy-dev@incubator.apache.org" <lu...@incubator.apache.org>; 
>"lucy-user@incubator.apache.org" <lu...@incubator.apache.org>
> Sent: Fri, May 20, 2011 9:30:52 PM
> Subject: Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate 
>#1
> 
> Hi Marvin,
> 
> On May 20, 2011, at 2:44 PM, Marvin Humphrey  wrote:
> 
> > Hi, Chris, thanks for expediting.
> > 
> > On Fri,  May 20, 2011 at 02:18:37PM -0700, Mattmann, Chris A (388J) wrote:
> >>  http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/
> > 
> > The artifacts here do not follow the version naming convention that is  used 
>by
> > the source code of X.Y.Z, and that the ReleaseGuide specifies  the artifacts
> > should use:
> > 
> >     apache-lucy-0.1-incubating-src.tar.gz   //  actual name
> >     apache-lucy-incubating-X.Y.Z.tar.gz     //  documented in  ReleaseGuide.
> 
> Hmmm....Sorry but this is the first time I've carefully  looked at the 
>ReleaseGuide, otherwise if I saw it back when you threw it up on  the wiki, I'd 
>probably have debated this convention for *artifact names* (note  this an 
>important distinction -- I'm not debating the programmatic use of  version #s as 
>is covered below). Most of the Apache releases I've seen use  *artifact names*  
>likes:
> 
> apache-<product>-<version>-<src|bin>.<ext>
> 
> In  this case, we're the lucy product, version 0.1-incubating, it's a src 
>release,  and it's a tar.gz extension.
> 
> I think that makes more sense  than:
> 
> apache-<product>-incubating-<version>.<ext>
> 
> > 
> > It's essential that our artifacts match the actual version number  strings.
> 
> Who are you talking about when you say "our"? I am included in  that set? If 
>so, I'm not necessarily on board with your proposal for what the  *artfiact 
>name* should be. Note that the discussion we had on your referenced  thread 
>below is actually talking about programmatic uses of a string/int/number  
>version within the context of PL-specific forges like CPAN/Maven  
>Central/PyPI/etc. It's not talking about artifact names.
> 
> > This was  hammered out over a long thread here: <http://s.apache.org/lW>.
> > 
> > The branch we will use for bugfixes is also misnamed:
> > 
> >    // Actual name
> >    
>https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating/
>
> >     // Documented in ReleaseGuide
> >    https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y
> 
> Gotcha.  I transposed the branch and tag names.
> 
> Speaking of which though, let me  also poke at this. Having 2 conventions for 
>tags and branches seems odd to me  and it seems like the introduction of 
>pointless complexity for little gain. Why  not just pick one:
> 
> either:
> 
> apache-lucy-X.Y (e.g.,  apache-lucy-0.1-incubating)
> 
> or:
> 
> X.Y (e.g.,  0.1-incubating)
> 
> Having 2 conventions for branches and tags seems odd to  me. 
> 
> > 
> > And there is no tag for the RC as the instructions set  out:
> > 
> >    
>https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-X.Y.Z-rcN
>
> 
> IMO  and experience, tags are created when a release VOTE passes to capture a  
>*final* snapshot of the release that's not expected to change. Some other  
>projects use tags as the first release VOTE'ing artifact, and then roll a branch  
>when the VOTE passes to indicate further development in a series. Either way is  
>fine. I'm happy to create the tag, but honestly, this approach seems like an RM  
>decision to me and something that we should leave open to the guy picking up a  
>shovel and doing the RM'ing.
> 
> > 
> > I regret that I must vote  -1.  Please change the name of the tag, following
> > the documentation  in the ReleaseGuide precisely and reroll.  If you 
disagree
> > with  anything you encounter, please raise your concern on the dev list.
> 
> No  probs. Concerns raised above. 
> 
> Cheers,
> Chris
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris  Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory  Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW:     http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct  Assistant Professor, Computer Science Department
> University of Southern  California, Los Angeles, CA 90089  USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 

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


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, May 20, 2011 at 06:30:52PM -0700, Mattmann, Chris A (388J) wrote:
> Hmmm....Sorry but this is the first time I've carefully looked at the
> ReleaseGuide, otherwise if I saw it back when you threw it up on the wiki,
> I'd probably have debated this convention for *artifact names* (note this an
> important distinction -- I'm not debating the programmatic use of version #s
> as is covered below). 

The thing I really care about is the inclusion of all three numbers X.Y.Z in
the artifact names.

For technical reasons documented in that thread, it's essential that the
downstream CPAN artifacts use X.Y.Z consistently.  It strikes me as a bad idea
to have the Apache canonical artifacts sometimes use X.Y and sometimes use
X.Y.Z, sometimes matching downstream and sometimes not.

The version number for this release is either "0.1.0" or "0.1.0-incubating".
It is not "0.1" or "0.1-incubating", because Z is definitely defined as "0".

I should have gone out of my way to fix all usages of "0.1-incubating", such
as in JIRA.  Confusion is understandable, because even though that thread
concludes with a firm decision to use X.Y.Z numbering consistently, we did not
aggressively apply that decision in every nook and cranny or jump up and down
screaming every time somebody subsequently omitted Z.

> Most of the Apache releases I've seen use *artifact names* likes:
> 
> apache-<product>-<version>-<src|bin>.<ext>

The inclusion of "src" wasn't something I considered.  For what it's worth, we
are unlikely to do "bin" releases for Lucy any time soon, because what with
natively compiled code and multiple binding language targets there are so many
possible configurations.  So, I don't know that it's important to include
"src" to differentiate from "bin" releases that may never exist, but it's not
something I have a concrete reason to oppose.
 
The placement of the word "incubating" follows the Incubator documentation.

    http://incubator.apache.org/guides/releasemanagement.html#naming

    The release name should contain the podling name and may contain apache.
    Incubator policy insists that it must also contain 'incubating' (though
    small variations for the sake of readability are usually acceptable). 

    For example, for podling foo, both 'apache-foo-incubating' and
    'foo-incubating' would be acceptable names. 

However, that was not discussed on the Lucy dev list -- it's something I
discovered and revised while distilling down the ReleaseGuide.

I happen to prefer attaching "incubating" to "apache-lucy" rather than the
version number because no code or metadata includes the word "incubating" in
the version number.  However, either way meets the requirements of the
Incubator.  It's more important to me that once we choose one of these
conventions, we use it consistently for as long as we are in the Incubator.

> >    // Actual name
> >    https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating/
> >    // Documented in ReleaseGuide
> >    https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y
> 
> Gotcha. I transposed the branch and tag names.
> 
> Speaking of which though, let me also poke at this. Having 2 conventions for
> tags and branches seems odd to me and it seems like the introduction of
> pointless complexity for little gain. Why not just pick one:
> 
> either:
> 
> apache-lucy-X.Y (e.g., apache-lucy-0.1-incubating)
> 
> or:
> 
> X.Y (e.g., 0.1-incubating)
> 
> Having 2 conventions for branches and tags seems odd to me. 

This branch naming convention was adopted after studying Lucene's branches:

    https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y

> > And there is no tag for the RC as the instructions set out:
> > 
> >    https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-X.Y.Z-rcN
> 
> IMO and experience, tags are created when a release VOTE passes to capture a
> *final* snapshot of the release that's not expected to change. Some other
> projects use tags as the first release VOTE'ing artifact, and then roll a
> branch when the VOTE passes to indicate further development in a series.
> Either way is fine. I'm happy to create the tag, but honestly, this approach
> seems like an RM decision to me and something that we should leave open to
> the guy picking up a shovel and doing the RM'ing.

The end goal of the release tagging procedure is a tag associated with the
final artifacts.  I don't really care how we get there.  The recipe is there
so that future RMs will get to the end goal consistently and not screw up the
tag-to-release-artifacts association.  It was inspired by someone else's
routine -- don't remember whether I got it from Incubator docs, somebody other
TLP's release procedures, or mailing list spelunking.

Marvin Humphrey


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, May 20, 2011 at 06:30:52PM -0700, Mattmann, Chris A (388J) wrote:
> Hmmm....Sorry but this is the first time I've carefully looked at the
> ReleaseGuide, otherwise if I saw it back when you threw it up on the wiki,
> I'd probably have debated this convention for *artifact names* (note this an
> important distinction -- I'm not debating the programmatic use of version #s
> as is covered below). 

The thing I really care about is the inclusion of all three numbers X.Y.Z in
the artifact names.

For technical reasons documented in that thread, it's essential that the
downstream CPAN artifacts use X.Y.Z consistently.  It strikes me as a bad idea
to have the Apache canonical artifacts sometimes use X.Y and sometimes use
X.Y.Z, sometimes matching downstream and sometimes not.

The version number for this release is either "0.1.0" or "0.1.0-incubating".
It is not "0.1" or "0.1-incubating", because Z is definitely defined as "0".

I should have gone out of my way to fix all usages of "0.1-incubating", such
as in JIRA.  Confusion is understandable, because even though that thread
concludes with a firm decision to use X.Y.Z numbering consistently, we did not
aggressively apply that decision in every nook and cranny or jump up and down
screaming every time somebody subsequently omitted Z.

> Most of the Apache releases I've seen use *artifact names* likes:
> 
> apache-<product>-<version>-<src|bin>.<ext>

The inclusion of "src" wasn't something I considered.  For what it's worth, we
are unlikely to do "bin" releases for Lucy any time soon, because what with
natively compiled code and multiple binding language targets there are so many
possible configurations.  So, I don't know that it's important to include
"src" to differentiate from "bin" releases that may never exist, but it's not
something I have a concrete reason to oppose.
 
The placement of the word "incubating" follows the Incubator documentation.

    http://incubator.apache.org/guides/releasemanagement.html#naming

    The release name should contain the podling name and may contain apache.
    Incubator policy insists that it must also contain 'incubating' (though
    small variations for the sake of readability are usually acceptable). 

    For example, for podling foo, both 'apache-foo-incubating' and
    'foo-incubating' would be acceptable names. 

However, that was not discussed on the Lucy dev list -- it's something I
discovered and revised while distilling down the ReleaseGuide.

I happen to prefer attaching "incubating" to "apache-lucy" rather than the
version number because no code or metadata includes the word "incubating" in
the version number.  However, either way meets the requirements of the
Incubator.  It's more important to me that once we choose one of these
conventions, we use it consistently for as long as we are in the Incubator.

> >    // Actual name
> >    https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating/
> >    // Documented in ReleaseGuide
> >    https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y
> 
> Gotcha. I transposed the branch and tag names.
> 
> Speaking of which though, let me also poke at this. Having 2 conventions for
> tags and branches seems odd to me and it seems like the introduction of
> pointless complexity for little gain. Why not just pick one:
> 
> either:
> 
> apache-lucy-X.Y (e.g., apache-lucy-0.1-incubating)
> 
> or:
> 
> X.Y (e.g., 0.1-incubating)
> 
> Having 2 conventions for branches and tags seems odd to me. 

This branch naming convention was adopted after studying Lucene's branches:

    https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y

> > And there is no tag for the RC as the instructions set out:
> > 
> >    https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-X.Y.Z-rcN
> 
> IMO and experience, tags are created when a release VOTE passes to capture a
> *final* snapshot of the release that's not expected to change. Some other
> projects use tags as the first release VOTE'ing artifact, and then roll a
> branch when the VOTE passes to indicate further development in a series.
> Either way is fine. I'm happy to create the tag, but honestly, this approach
> seems like an RM decision to me and something that we should leave open to
> the guy picking up a shovel and doing the RM'ing.

The end goal of the release tagging procedure is a tag associated with the
final artifacts.  I don't really care how we get there.  The recipe is there
so that future RMs will get to the end goal consistently and not screw up the
tag-to-release-artifacts association.  It was inspired by someone else's
routine -- don't remember whether I got it from Incubator docs, somebody other
TLP's release procedures, or mailing list spelunking.

Marvin Humphrey


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


[lucy-user] Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Marvin,

On May 20, 2011, at 2:44 PM, Marvin Humphrey wrote:

> Hi, Chris, thanks for expediting.
> 
> On Fri, May 20, 2011 at 02:18:37PM -0700, Mattmann, Chris A (388J) wrote:
>> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/
> 
> The artifacts here do not follow the version naming convention that is used by
> the source code of X.Y.Z, and that the ReleaseGuide specifies the artifacts
> should use:
> 
>    apache-lucy-0.1-incubating-src.tar.gz   //  actual name
>    apache-lucy-incubating-X.Y.Z.tar.gz     //  documented in ReleaseGuide.

Hmmm....Sorry but this is the first time I've carefully looked at the ReleaseGuide, otherwise if I saw it back when you threw it up on the wiki, I'd probably have debated this convention for *artifact names* (note this an important distinction -- I'm not debating the programmatic use of version #s as is covered below). Most of the Apache releases I've seen use *artifact names* likes:

apache-<product>-<version>-<src|bin>.<ext>

In this case, we're the lucy product, version 0.1-incubating, it's a src release, and it's a tar.gz extension.

I think that makes more sense than:

apache-<product>-incubating-<version>.<ext>

> 
> It's essential that our artifacts match the actual version number strings.

Who are you talking about when you say "our"? I am included in that set? If so, I'm not necessarily on board with your proposal for what the *artfiact name* should be. Note that the discussion we had on your referenced thread below is actually talking about programmatic uses of a string/int/number version within the context of PL-specific forges like CPAN/Maven Central/PyPI/etc. It's not talking about artifact names.

> This was hammered out over a long thread here: <http://s.apache.org/lW>.
> 
> The branch we will use for bugfixes is also misnamed:
> 
>    // Actual name
>    https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating/
>    // Documented in ReleaseGuide
>    https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y

Gotcha. I transposed the branch and tag names.

Speaking of which though, let me also poke at this. Having 2 conventions for tags and branches seems odd to me and it seems like the introduction of pointless complexity for little gain. Why not just pick one:

either:

apache-lucy-X.Y (e.g., apache-lucy-0.1-incubating)

or:

X.Y (e.g., 0.1-incubating)

Having 2 conventions for branches and tags seems odd to me. 

> 
> And there is no tag for the RC as the instructions set out:
> 
>    https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-X.Y.Z-rcN

IMO and experience, tags are created when a release VOTE passes to capture a *final* snapshot of the release that's not expected to change. Some other projects use tags as the first release VOTE'ing artifact, and then roll a branch when the VOTE passes to indicate further development in a series. Either way is fine. I'm happy to create the tag, but honestly, this approach seems like an RM decision to me and something that we should leave open to the guy picking up a shovel and doing the RM'ing.

> 
> I regret that I must vote -1.  Please change the name of the tag, following
> the documentation in the ReleaseGuide precisely and reroll.  If you disagree
> with anything you encounter, please raise your concern on the dev list.

No probs. Concerns raised above. 

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Marvin,

On May 20, 2011, at 2:44 PM, Marvin Humphrey wrote:

> Hi, Chris, thanks for expediting.
> 
> On Fri, May 20, 2011 at 02:18:37PM -0700, Mattmann, Chris A (388J) wrote:
>> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/
> 
> The artifacts here do not follow the version naming convention that is used by
> the source code of X.Y.Z, and that the ReleaseGuide specifies the artifacts
> should use:
> 
>    apache-lucy-0.1-incubating-src.tar.gz   //  actual name
>    apache-lucy-incubating-X.Y.Z.tar.gz     //  documented in ReleaseGuide.

Hmmm....Sorry but this is the first time I've carefully looked at the ReleaseGuide, otherwise if I saw it back when you threw it up on the wiki, I'd probably have debated this convention for *artifact names* (note this an important distinction -- I'm not debating the programmatic use of version #s as is covered below). Most of the Apache releases I've seen use *artifact names* likes:

apache-<product>-<version>-<src|bin>.<ext>

In this case, we're the lucy product, version 0.1-incubating, it's a src release, and it's a tar.gz extension.

I think that makes more sense than:

apache-<product>-incubating-<version>.<ext>

> 
> It's essential that our artifacts match the actual version number strings.

Who are you talking about when you say "our"? I am included in that set? If so, I'm not necessarily on board with your proposal for what the *artfiact name* should be. Note that the discussion we had on your referenced thread below is actually talking about programmatic uses of a string/int/number version within the context of PL-specific forges like CPAN/Maven Central/PyPI/etc. It's not talking about artifact names.

> This was hammered out over a long thread here: <http://s.apache.org/lW>.
> 
> The branch we will use for bugfixes is also misnamed:
> 
>    // Actual name
>    https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating/
>    // Documented in ReleaseGuide
>    https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y

Gotcha. I transposed the branch and tag names.

Speaking of which though, let me also poke at this. Having 2 conventions for tags and branches seems odd to me and it seems like the introduction of pointless complexity for little gain. Why not just pick one:

either:

apache-lucy-X.Y (e.g., apache-lucy-0.1-incubating)

or:

X.Y (e.g., 0.1-incubating)

Having 2 conventions for branches and tags seems odd to me. 

> 
> And there is no tag for the RC as the instructions set out:
> 
>    https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-X.Y.Z-rcN

IMO and experience, tags are created when a release VOTE passes to capture a *final* snapshot of the release that's not expected to change. Some other projects use tags as the first release VOTE'ing artifact, and then roll a branch when the VOTE passes to indicate further development in a series. Either way is fine. I'm happy to create the tag, but honestly, this approach seems like an RM decision to me and something that we should leave open to the guy picking up a shovel and doing the RM'ing.

> 
> I regret that I must vote -1.  Please change the name of the tag, following
> the documentation in the ReleaseGuide precisely and reroll.  If you disagree
> with anything you encounter, please raise your concern on the dev list.

No probs. Concerns raised above. 

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


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


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Marvin,

On May 20, 2011, at 2:44 PM, Marvin Humphrey wrote:

> Hi, Chris, thanks for expediting.
> 
> On Fri, May 20, 2011 at 02:18:37PM -0700, Mattmann, Chris A (388J) wrote:
>> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/
> 
> The artifacts here do not follow the version naming convention that is used by
> the source code of X.Y.Z, and that the ReleaseGuide specifies the artifacts
> should use:
> 
>    apache-lucy-0.1-incubating-src.tar.gz   //  actual name
>    apache-lucy-incubating-X.Y.Z.tar.gz     //  documented in ReleaseGuide.

Hmmm....Sorry but this is the first time I've carefully looked at the ReleaseGuide, otherwise if I saw it back when you threw it up on the wiki, I'd probably have debated this convention for *artifact names* (note this an important distinction -- I'm not debating the programmatic use of version #s as is covered below). Most of the Apache releases I've seen use *artifact names* likes:

apache-<product>-<version>-<src|bin>.<ext>

In this case, we're the lucy product, version 0.1-incubating, it's a src release, and it's a tar.gz extension.

I think that makes more sense than:

apache-<product>-incubating-<version>.<ext>

> 
> It's essential that our artifacts match the actual version number strings.

Who are you talking about when you say "our"? I am included in that set? If so, I'm not necessarily on board with your proposal for what the *artfiact name* should be. Note that the discussion we had on your referenced thread below is actually talking about programmatic uses of a string/int/number version within the context of PL-specific forges like CPAN/Maven Central/PyPI/etc. It's not talking about artifact names.

> This was hammered out over a long thread here: <http://s.apache.org/lW>.
> 
> The branch we will use for bugfixes is also misnamed:
> 
>    // Actual name
>    https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating/
>    // Documented in ReleaseGuide
>    https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y

Gotcha. I transposed the branch and tag names.

Speaking of which though, let me also poke at this. Having 2 conventions for tags and branches seems odd to me and it seems like the introduction of pointless complexity for little gain. Why not just pick one:

either:

apache-lucy-X.Y (e.g., apache-lucy-0.1-incubating)

or:

X.Y (e.g., 0.1-incubating)

Having 2 conventions for branches and tags seems odd to me. 

> 
> And there is no tag for the RC as the instructions set out:
> 
>    https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-X.Y.Z-rcN

IMO and experience, tags are created when a release VOTE passes to capture a *final* snapshot of the release that's not expected to change. Some other projects use tags as the first release VOTE'ing artifact, and then roll a branch when the VOTE passes to indicate further development in a series. Either way is fine. I'm happy to create the tag, but honestly, this approach seems like an RM decision to me and something that we should leave open to the guy picking up a shovel and doing the RM'ing.

> 
> I regret that I must vote -1.  Please change the name of the tag, following
> the documentation in the ReleaseGuide precisely and reroll.  If you disagree
> with anything you encounter, please raise your concern on the dev list.

No probs. Concerns raised above. 

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by Marvin Humphrey <ma...@rectangular.com>.
Hi, Chris, thanks for expediting.

On Fri, May 20, 2011 at 02:18:37PM -0700, Mattmann, Chris A (388J) wrote:
> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/

The artifacts here do not follow the version naming convention that is used by
the source code of X.Y.Z, and that the ReleaseGuide specifies the artifacts
should use:

    apache-lucy-0.1-incubating-src.tar.gz   //  actual name
    apache-lucy-incubating-X.Y.Z.tar.gz     //  documented in ReleaseGuide.

It's essential that our artifacts match the actual version number strings.
This was hammered out over a long thread here: <http://s.apache.org/lW>.

The branch we will use for bugfixes is also misnamed:

    // Actual name
    https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating/
    // Documented in ReleaseGuide
    https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y

And there is no tag for the RC as the instructions set out:

    https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-X.Y.Z-rcN

I regret that I must vote -1.  Please change the name of the tag, following
the documentation in the ReleaseGuide precisely and reroll.  If you disagree
with anything you encounter, please raise your concern on the dev list.

Thanks, 

Marvin Humphrey


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


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by Joe Schaefer <jo...@yahoo.com>.
+1, with the caviat that the key in your keys file
isn't the key you signed this package with.  Please
add you code-signing key to the KEYS file.



----- Original Message ----
> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
> To: "lucy-dev@incubator.apache.org" <lu...@incubator.apache.org>
> Cc: "lucy-user@incubator.apache.org" <lu...@incubator.apache.org>; 
>"general@incubator.apache.org" <ge...@incubator.apache.org>
> Sent: Fri, May 20, 2011 5:18:37 PM
> Subject: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1
> 
> Hi Folks,
> 
> I am proud to announce the first candidate for the Apache  Lucy  0.1-incubating 
>
> release. The source code is  at:
> 
> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/
> 
> For  more detailed information, see the included CHANGES file for details  on
> release contents and latest changes. The release was made using the  Lucy
> release process, documented on the Wiki  here:
> 
> http://wiki.apache.org/lucy/ReleaseGuide
> 
> The release was  made from the Lucy 0.1-incubating branch (r1125570) at:
> 
>https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating
>g
> 
> The  release built fine for me and all tests passed:
> 
> All tests successful, 2  tests and 10 subtests skipped.
> Files=169, Tests=10465, 24 wallclock secs  (16.88 cusr +  3.27 csys = 20.15  
>CPU)
> [chipotle:0.1-incubating-release/apache-lucy-0.1-incubating/perl]  mattmann% 
> 
> Please vote on releasing these packages as Apache Lucy  0.1-incubating. The 
>vote is
> open for the next 72 hours.
> 
> Only votes  from Incubator PMC are binding, but folks are welcome to check the
> release  candidate and voice their approval or disapproval. The vote passes
> if at  least three binding +1 votes are cast.
> 
> [ ] +1 Release the packages as  Apache Lucy 0.1-incubating
> [ ] +0 Don't care
> [ ] -1 Do not release the  packages as Apache Lucy 0.1-incubating  because...
> 
> Thanks!
> 
> Cheers,
> Chris
> 
> P.S. Here is my  +1.
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris  Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory  Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW:     http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct  Assistant Professor, Computer Science Department
> University of Southern  California, Los Angeles, CA 90089  USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 

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


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Marvin,

On May 20, 2011, at 3:03 PM, Marvin Humphrey wrote:

> // cutting out the cc's to lucy-user and general@incubator
> 
> Hi, 
> 
> Even though it will take extra time, I think we would also benefit from
> running a PPMC vote here on lucy-dev before involving the Incubator PMC and
> the Incubator general list.  I know it *can* be done that way, but from what
> I've seen almost nobody does.

I don't really agree with that at all. 

We don't really lose anything by going to both the IPMC and the PPMC at the same time. They are both subscribed on the included lists. PPMC members are free to VOTE along with the rest of the IPMC and user/dev communities of the Incubator and of Lucy. 

Holding a separate set of VOTEs just adds more time required of the already scarce resources.

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by Marvin Humphrey <ma...@rectangular.com>.
// cutting out the cc's to lucy-user and general@incubator

Hi, 

Even though it will take extra time, I think we would also benefit from
running a PPMC vote here on lucy-dev before involving the Incubator PMC and
the Incubator general list.  I know it *can* be done that way, but from what
I've seen almost nobody does.

Marvin Humphrey

On Fri, May 20, 2011 at 02:18:37PM -0700, Mattmann, Chris A (388J) wrote:
> [ ] +1 Release the packages as Apache Lucy 0.1-incubating
> [ ] +0 Don't care
> [ ] -1 Do not release the packages as Apache Lucy 0.1-incubating because...


[lucy-user] Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by Joe Schaefer <jo...@yahoo.com>.
+1, with the caviat that the key in your keys file
isn't the key you signed this package with.  Please
add you code-signing key to the KEYS file.



----- Original Message ----
> From: "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>
> To: "lucy-dev@incubator.apache.org" <lu...@incubator.apache.org>
> Cc: "lucy-user@incubator.apache.org" <lu...@incubator.apache.org>; 
>"general@incubator.apache.org" <ge...@incubator.apache.org>
> Sent: Fri, May 20, 2011 5:18:37 PM
> Subject: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1
> 
> Hi Folks,
> 
> I am proud to announce the first candidate for the Apache  Lucy  0.1-incubating 
>
> release. The source code is  at:
> 
> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/
> 
> For  more detailed information, see the included CHANGES file for details  on
> release contents and latest changes. The release was made using the  Lucy
> release process, documented on the Wiki  here:
> 
> http://wiki.apache.org/lucy/ReleaseGuide
> 
> The release was  made from the Lucy 0.1-incubating branch (r1125570) at:
> 
>https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating
>g
> 
> The  release built fine for me and all tests passed:
> 
> All tests successful, 2  tests and 10 subtests skipped.
> Files=169, Tests=10465, 24 wallclock secs  (16.88 cusr +  3.27 csys = 20.15  
>CPU)
> [chipotle:0.1-incubating-release/apache-lucy-0.1-incubating/perl]  mattmann% 
> 
> Please vote on releasing these packages as Apache Lucy  0.1-incubating. The 
>vote is
> open for the next 72 hours.
> 
> Only votes  from Incubator PMC are binding, but folks are welcome to check the
> release  candidate and voice their approval or disapproval. The vote passes
> if at  least three binding +1 votes are cast.
> 
> [ ] +1 Release the packages as  Apache Lucy 0.1-incubating
> [ ] +0 Don't care
> [ ] -1 Do not release the  packages as Apache Lucy 0.1-incubating  because...
> 
> Thanks!
> 
> Cheers,
> Chris
> 
> P.S. Here is my  +1.
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris  Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory  Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann@nasa.gov
> WWW:     http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct  Assistant Professor, Computer Science Department
> University of Southern  California, Los Angeles, CA 90089  USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 

[lucy-user] Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by Marvin Humphrey <ma...@rectangular.com>.
Hi, Chris, thanks for expediting.

On Fri, May 20, 2011 at 02:18:37PM -0700, Mattmann, Chris A (388J) wrote:
> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/

The artifacts here do not follow the version naming convention that is used by
the source code of X.Y.Z, and that the ReleaseGuide specifies the artifacts
should use:

    apache-lucy-0.1-incubating-src.tar.gz   //  actual name
    apache-lucy-incubating-X.Y.Z.tar.gz     //  documented in ReleaseGuide.

It's essential that our artifacts match the actual version number strings.
This was hammered out over a long thread here: <http://s.apache.org/lW>.

The branch we will use for bugfixes is also misnamed:

    // Actual name
    https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating/
    // Documented in ReleaseGuide
    https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y

And there is no tag for the RC as the instructions set out:

    https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-X.Y.Z-rcN

I regret that I must vote -1.  Please change the name of the tag, following
the documentation in the ReleaseGuide precisely and reroll.  If you disagree
with anything you encounter, please raise your concern on the dev list.

Thanks, 

Marvin Humphrey


Re: [lucy-dev] [VOTE] Apache Lucy 0.1.0-incubating release candidate #1

Posted by Marvin Humphrey <ma...@rectangular.com>.
Hi, Chris, thanks for expediting.

On Fri, May 20, 2011 at 02:18:37PM -0700, Mattmann, Chris A (388J) wrote:
> http://people.apache.org/~mattmann/apache-lucy-0.1-incubating/rc1/

The artifacts here do not follow the version naming convention that is used by
the source code of X.Y.Z, and that the ReleaseGuide specifies the artifacts
should use:

    apache-lucy-0.1-incubating-src.tar.gz   //  actual name
    apache-lucy-incubating-X.Y.Z.tar.gz     //  documented in ReleaseGuide.

It's essential that our artifacts match the actual version number strings.
This was hammered out over a long thread here: <http://s.apache.org/lW>.

The branch we will use for bugfixes is also misnamed:

    // Actual name
    https://svn.apache.org/repos/asf/incubator/lucy/branches/apache-lucy-0.1-incubating/
    // Documented in ReleaseGuide
    https://svn.apache.org/repos/asf/incubator/lucy/branches/X.Y

And there is no tag for the RC as the instructions set out:

    https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-X.Y.Z-rcN

I regret that I must vote -1.  Please change the name of the tag, following
the documentation in the ReleaseGuide precisely and reroll.  If you disagree
with anything you encounter, please raise your concern on the dev list.

Thanks, 

Marvin Humphrey