Re: help with official binary mirrored releases

[robert burrell donkin <rd...@apache.org>]

(this thread has been moved - with eric's permission - onto general, 
which seems a more suitable forum. people might want to read the posts 
at the bottom before starting on my comments)

On 29 Nov 2004, at 11:01, Erik Hatcher wrote:

> Robert,

Eric

> I agree that moving this to general is appropriate.

good :)

<snip>

> Unfortunately I haven't been available to assist with a couple of the 
> releases that Doug did, which he just put at cvs.apache.org and 
> pointed the Lucene website to that URL.  *sigh*

<sigh>

i know that documentation is necessary (the reason i wrote up the 
commons stuff so that it matched the new mirrors was that i couldn't 
remember all the stages accurately without it) and i'll start a thread 
on infrastructure to see if they accept some material (were i to 
produce it) but i'm not sure that it can really replace someone who can 
talk you through it.

when i first started cutting releases, i had the advantage that some of 
the senior jakarta figures were around to talk me through the process 
and make sure the important stuff was in order. i've done my best to 
get other people started in the same fashion.

i know that jakarta has traditionally allowed quite a measure of 
autonomy in release practices but i wonder now whether the time has 
come to insist on a little more consistency in the important things. 
AIUI software releases are very important legally and so it's vital we 
get them right. maybe we should be thinking about asking for mentors 
(assigned by the pmc through the chair) for all releases. i'd be glad 
to have a second pair of eyes checking for mistakes. (i'd much rather 
have an oversight spotted by a friend than by a user.)

- robert

> On Nov 28, 2004, at 5:45 PM, robert burrell donkin wrote:
>
>> hi eric
>>
>> unfortunately, the best resource available now is still probably the 
>> commons release instructions 
>> (http://jakarta.apache.org/commons/releases/index.html). some sort of 
>> federation level instructions are probably needed now.
>>
>> i've talked more than a few people through the mirroring and release 
>> process so feel free to address questions to me. in some ways 
>> (though) it seems best to shift this thread onto general (if that's 
>> ok with you) so that there's some sort of public record to help 
>> others in the future.
>>
>> - robert
>>
>> On 26 Nov 2004, at 17:58, Erik Hatcher wrote:
>>
>>> I've used the instructions that were previously here - 
>>> http://nagoya.apache.org/wiki/apachewiki.cgi?ReleaseManager - for 
>>> Lucene releases in the past.  Our last few "releases" have not been 
>>> done properly with the mirrors, though.  We have a new 1.4.3 release 
>>> coming out and need to finally get with the program.
>>>
>>> Are the instructions for doing a binary, signed, mirrored release 
>>> available somewhere on the new wiki or web site?  If so, where?
>>>
>>> Are there scripts available to automate some of the grunt work 
>>> associated with this process?  Even the few steps I did in the past 
>>> were a bit more manual than it should be.
>>>
>>> Thanks,
>>> 	Erik
>>>
>>>
>
>


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

Re: help with official binary mirrored releases

[Henri Yandell <ba...@generationjava.com>]

On Mon, 29 Nov 2004, robert burrell donkin wrote:

> when i first started cutting releases, i had the advantage that some of the 
> senior jakarta figures were around to talk me through the process and make 
> sure the important stuff was in order. i've done my best to get other people 
> started in the same fashion.
>
> i know that jakarta has traditionally allowed quite a measure of autonomy in 
> release practices but i wonder now whether the time has come to insist on a 
> little more consistency in the important things. AIUI software releases are

The thoughts (many from you) on restructuring the download page would seem 
to lead nicely to a series of release goals (must have MD5, be mirrored, 
whatever). Then there are a few other release goals that jump up (email an 
announcement list, news, put jar in the asf maven repository rsync).

If we define a series of release goals, we can get more consistency 
without having to get too heavily into how sub-project's processes work.

> very important legally and so it's vital we get them right. maybe we should 
> be thinking about asking for mentors (assigned by the pmc through the chair) 
> for all releases. i'd be glad to have a second pair of eyes checking for 
> mistakes. (i'd much rather have an oversight spotted by a friend than by a 
> user.)

Much easier to just state that each release will have a release owner 
and a release builder. The owner does the vote, the builder prepares the 
files, and the owner acts as the second pair of eyes aka the customer. Two 
people to do the previous job of 1, and halve screwups. That is, if we 
decide to try to structure things a bit more.

Some thoughts anyway :)

Hen

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