On 17 August 2011 18:35, Richard Frovarp <rfrov...@apache.org> wrote:
> On 08/17/2011 10:41 AM, sebb wrote:
>>
>> On 15 August 2011 19:20, Richard Frovarp<rfrov...@apache.org>  wrote:
>>>
>>> Please vote on the release candidate for Apache Droids Incubating,
>>> version
>>> 0.1-incubating. I've received one binding IPMC +1 votes and 4 non-binding
>>> +1
>>> votes.
>>>
>>> PPMC release vote thread:
>>>
>>> http://mail-archives.apache.org/mod_mbox/incubator-droids-dev/201107.mbox/%3c4e31b811.3080...@apache.org%3E
>>>
>>> Source files:
>>> http://people.apache.org/~rfrovarp/droids/
>>
>> -1
>>
>> Only 1 file visible to me - no sigs or hashes.
>>
>> All release artifacts must be signed and have at least one hash.
>
> I fully get your point, but they do. One can find everything here:
>
> https://repository.apache.org/content/repositories/orgapachedroids-008/org/apache/droids/droids/0.1.0-incubating/
>
> In the future, is there anything wrong with pointing to the Maven staging
> repo for the source release part of this? Convention shows that people put
> it in their home directories. I simply just did a wget of the one file and
> forgot to grab the sigs and hashes. I can grab everything, but just pointing
> to the staging directory would be simpler.

Yes, that would be fine, but you provided the URL for review, which is
what I did.

I've not yet looked at the Maven artifacts in any detail.

>>
>> Also the source archive contains some files that are not in SVN:
>>
>> droids-solr/data/index/
>> - segments.gen
>> - segments_l
>>
>> These seem to be generated binary files, and should not be included.
>>
>> Normally Maven is quite good at separating generated code, as that is
>> created under target/
>> Perhaps there is a problem in the build process that puts the
>> generated data in the wrong place?
>
> The Solr config file that is used in the testing phase didn't put them in
> target. That has been fixed in source.
>
>>
>> ==
>>
>> The NOTICE file contains the sentence "See also the file LICENSE."
>> This should be removed, as it's not necessary (not a blocker of itself).
>
> Updated.
>
> As always, thanks for the review.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

Reply via email to