Re: Release help, stuck on gpg-sign?
On Tue, 20 Oct 2009 23:53:42 +0100 Sean Owen wrote: > Thanks, this is probably vital. I had not seen this. > > Let me ask questions here before taking them to the Apache staff -- > > I am unable to update > https://svn.apache.org/repos/asf/maven/project/KEYS -- get a 403 The url for code signing keys for Mahout should be https://svn.apache.org/repos/asf/lucene/mahout/trunk/KEYS Isabel
Re: Release help, stuck on gpg-sign?
Nah maybe this is required, same result. I wonder, could whoever did the 0.1 release give it a shot? to see if it's just me? and, to perhaps just do the deployment? the legwork is done, it's ready to publish. On Tue, Oct 20, 2009 at 11:53 PM, Sean Owen wrote: > Thanks, this is probably vital. I had not seen this. > > Let me ask questions here before taking them to the Apache staff -- > > I am unable to update > https://svn.apache.org/repos/asf/maven/project/KEYS -- get a 403 > Forbidden. Grant did you ever have to do this / do you have the power > to? > > I will see how far I can get without it.
Re: Release help, stuck on gpg-sign?
Thanks, this is probably vital. I had not seen this.
Let me ask questions here before taking them to the Apache staff --
I am unable to update
https://svn.apache.org/repos/asf/maven/project/KEYS -- get a 403
Forbidden. Grant did you ever have to do this / do you have the power
to?
I will see how far I can get without it.
On Tue, Oct 20, 2009 at 6:04 PM, Isabel Drost wrote:
> On Tuesday 20 October 2009 17:11:59 Sean Owen wrote:
>> release:prepare is hanging for me at...
>>
>> [INFO] [INFO] [gpg:sign {execution: default}]
>> I dont' think this is to do with the GPG signing I just added, as it
>> shows up even if I remove that bit. Anyone more familiar with this? is
>> my settings.xml OK?
>
> Jukka gave me the following guide for releasing according to the new Apache
> parent pom:
>
> http://maven.apache.org/developers/release/releasing.html
>
> It has some additional hints on prerequisites, trouble shooting etc. Not sure
> if that helps in your case.
>
> Isabel
>
> --
> |\ _,,,---,,_ Web:
> /,`.-'`' -. ;-;;,_
> |,4- ) )-,_..;\ ( `'-'
> '---''(_/--' `-'\_) (fL) IM:
>
>
Re: Release help, stuck on gpg-sign?
On Tuesday 20 October 2009 17:11:59 Sean Owen wrote:
> release:prepare is hanging for me at...
>
> [INFO] [INFO] [gpg:sign {execution: default}]
> I dont' think this is to do with the GPG signing I just added, as it
> shows up even if I remove that bit. Anyone more familiar with this? is
> my settings.xml OK?
Jukka gave me the following guide for releasing according to the new Apache
parent pom:
http://maven.apache.org/developers/release/releasing.html
It has some additional hints on prerequisites, trouble shooting etc. Not sure
if that helps in your case.
Isabel
--
|\ _,,,---,,_ Web:
/,`.-'`'-. ;-;;,_
|,4- ) )-,_..;\ ( `'-'
'---''(_/--' `-'\_) (fL) IM:
signature.asc
Description: This is a digitally signed message part.
Release help, stuck on gpg-sign?
release:prepare is hanging for me at...
[INFO] [INFO] [gpg:sign {execution: default}]
I dont' think this is to do with the GPG signing I just added, as it
shows up even if I remove that bit. Anyone more familiar with this? is
my settings.xml OK?
mahout_release
[my passphrase for GPG, not my key]
mahout.releases::default::scp://people.apache.org/home/srowen/public_html/staging-repo/mahout
srowen
scp://people.apache.org/home/srowen/public_html/staging-repo/mahout
Re: Anyone else having SVN trouble?
It just worked again. On Tue, Oct 20, 2009 at 7:10 PM, Robin Anil wrote: > So am I > > > > On Tue, Oct 20, 2009 at 6:46 PM, Sean Owen wrote: > >> Anyone else suddenly seeing this error on all SVN operations: >> >> svn: The specified baseline is not the latest baseline, so it may not >> be checked out. >> >> I see messages about this happening in the past to svn.apache.org, >> wondering if anyone else is seeing it or it's somehow just me. >> > >
Re: Anyone else having SVN trouble?
So am I On Tue, Oct 20, 2009 at 6:46 PM, Sean Owen wrote: > Anyone else suddenly seeing this error on all SVN operations: > > svn: The specified baseline is not the latest baseline, so it may not > be checked out. > > I see messages about this happening in the past to svn.apache.org, > wondering if anyone else is seeing it or it's somehow just me. >
Anyone else having SVN trouble?
Anyone else suddenly seeing this error on all SVN operations: svn: The specified baseline is not the latest baseline, so it may not be checked out. I see messages about this happening in the past to svn.apache.org, wondering if anyone else is seeing it or it's somehow just me.
Re: Small issues before 0.2
Right now it's a for loop on i, but, the for loop also declares an apparent index variable called j, which is not the index. A for loop ought to be used when the index variable begins life at the start of the loop, and of course the index variable declared in the for syntax ought be the actual index variable of the loop. For those two reasons it seems clearer to unpack this as a while loop and rename j. I'm not going to block on the Iterator issues but those really ought to be fixed. On Tue, Oct 20, 2009 at 11:05 AM, Robin Anil wrote: >> i is being updated not j, the initial location is selected by a binary > search(4 lines above). And the function continues only if search returns > correct. >
Re: Small issues before 0.2
On Tue, Oct 20, 2009 at 2:19 PM, Sean Owen wrote: > Going through the code one more time before starting release for 0.2 > and I have noticed some possible issues -- or else I miss something. > > > FPGrowth:258 : is this for loop really supposed to declare one > variable but update another? this could be correct but reads as > confusing > > i is being updated not j, the initial location is selected by a binary search(4 lines above). And the function continues only if search returns correct. LuceneIterable, SequenceFileIterable. The Iterators here have the same > problem - hasNext() can't have side effects. next() is what does the > updating. In these implementations hasNext() is what advances the > underlying data structure. This isn't going to work in general. > > (In fact, might be good to look for "TODO" in the code where I have > over time flagged things that look like a possible bug to me, mostly > stuff that is updated but never read or something like that. Some may > well not be; just remove the TODO then.) > > > Also let's not call System.exit()? it's abrupt to the point of not > necessarily running finalizers, which might be a bad thing. The return > value of main() rarely matters, and, throwing an exception is a more > conventional way to indicate failure and generate a non-zero return > value. > > Also I find it confusing to give a generic parameter a name longer > than 1-2 characters. It looks like a class name. > > and from the past ... > > No * imports > Don't throw RuntimeException or Exception > CONSTANTS should be final > No serialVersionUID, it breaks things > Conventional modifier order is 'public static final' > Conventional order of elements of class file: statics, members, > constructor, methods, inner classes > Still lots of javadoc problems -- bad refs, empty elements > > it's small, but good to follow a standard coding convention, and keep > the code clean. >
Small issues before 0.2
Going through the code one more time before starting release for 0.2 and I have noticed some possible issues -- or else I miss something. FPGrowth:258 : is this for loop really supposed to declare one variable but update another? this could be correct but reads as confusing LuceneIterable, SequenceFileIterable. The Iterators here have the same problem - hasNext() can't have side effects. next() is what does the updating. In these implementations hasNext() is what advances the underlying data structure. This isn't going to work in general. (In fact, might be good to look for "TODO" in the code where I have over time flagged things that look like a possible bug to me, mostly stuff that is updated but never read or something like that. Some may well not be; just remove the TODO then.) Also let's not call System.exit()? it's abrupt to the point of not necessarily running finalizers, which might be a bad thing. The return value of main() rarely matters, and, throwing an exception is a more conventional way to indicate failure and generate a non-zero return value. Also I find it confusing to give a generic parameter a name longer than 1-2 characters. It looks like a class name. and from the past ... No * imports Don't throw RuntimeException or Exception CONSTANTS should be final No serialVersionUID, it breaks things Conventional modifier order is 'public static final' Conventional order of elements of class file: statics, members, constructor, methods, inner classes Still lots of javadoc problems -- bad refs, empty elements it's small, but good to follow a standard coding convention, and keep the code clean.
