Re: Shift 0.7.0-incubating?

[Simone Tripodi <si...@apache.org>]

Hi all guys,
for the CLI improvements please follow up the discussion on
https://issues.apache.org/jira/browse/ANY23-71

Unfortunately there has been too much sun during the Weekend to stay
at home programming, I took advantage to take outside the puppy so
that patch is the only one I had the chance to take care. More
incoming during the week!

All the best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Fri, Mar 30, 2012 at 4:28 PM, Simone Tripodi
<si...@apache.org> wrote:
> Hello!!!
>
>> This isn't the only release - indeed, some would say that that being too
>> perfect discourages others getting involved as the barrier to contribution
>> is higher.
>>
>
> sure of course, that makes me reconsider a couple of points...
>
>> So I suggest setting a timescale with hard date for the code freeze.
>>
>
> yup agreed, at least we won't postpone to the infinity :)
>
>> If something gets done, great, if it doesn't, shrug.  There will be another
>> release coming along.  First release may go through easily, it may cause
>> comment - focus on process this time.  Once that is bedded down in the
>> project, it's easy to release but first release is about the process.
>>
>
> I should have almost the whole weekend available, I'll take care about
> any23 as much as I can :P
>
>>
>> I don't know how much you've discussed this already - I haven't been able to
>> follow everything recently ...
>>
>> In Jena, we have got this down to three steps:
>>
>>    mvn release:clean release:prepare -Papache-release
>>    mvn release:perform -Papache-release
>>
>> then run
>>
>>   <shell script that builds the dist/ area>
>>
>> mvn puts everything into staging (yukness => you get .asc.md5, .asc.sha1 --
>> everyone finds this and eventually just lives with it as a fact of life).
>>
>
> yup this is what I actually do in commons, cocoon, ..., and already
> prepared in any23 (apache-release profile will be enabled
> automatically when releasing) but I really wanted to avoid a 2-step
> process - anyway I already asked my mvn fellows and looks like there's
> no escape to this "trap" :( I'll continue deploying source/binary
> releas bundles manually.
>
> Release bundles in Any23 are created via the assembly-plugin (ehm,
> sources are still missing *blush*) I'll take care of reviewing during
> the WE. Anyway, 2 (or more) pair of eyes more to review the done work
> will be much more than appreciated and welcome :)
>
> All the best and thanks a lot for your inputs, have a nice day!
>
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Fri, Mar 30, 2012 at 12:38 PM, Andy Seaborne <an...@apache.org> wrote:
>> On 30/03/12 09:22, Simone Tripodi wrote:
>>> Hi Lewis,
>>>
>>> there are just few minor additions I'd like to discuss before to start
>>> cutting an RC:
>>>
>>>   1 update the plugin page according to the ServiceLoader pattern we
>>> adopted;
>>>   2 improving the CLI code - we can do a little better maintainable
>>> code, switching to JCommander[1] pattern
>>>   3 add a maven archetype to simplify plugins development
>>
>> This isn't the only release - indeed, some would say that that being too
>> perfect discourages others getting involved as the barrier to contribution
>> is higher.
>>
>> So I suggest setting a timescale with hard date for the code freeze.
>>
>> If something gets done, great, if it doesn't, shrug.  There will be another
>> release coming along.  First release may go through easily, it may cause
>> comment - focus on process this time.  Once that is bedded down in the
>> project, it's easy to release but first release is about the process.
>>
>> Sometimes, I think a podling should do the release thing, then throw it
>> away.  At least that way, it's clear the release is much more about Apache
>> process than a normal release.
>>
>> High ceremony ... with people watching.
>>
>>
>>>   4 understand how to concurrently deploy mvn artifacts on nexus and
>>> binaries bundles (included asc signs and md5/sha1 checksums) on the
>>> builds server, in one shot (I would avoid the RC manager has to
>>> perform manual operations as much as I can)
>>
>> I don't know how much you've discussed this already - I haven't been able to
>> follow everything recently ...
>>
>> In Jena, we have got this down to three steps:
>>
>>    mvn release:clean release:prepare -Papache-release
>>    mvn release:perform -Papache-release
>>
>> then run
>>
>>   <shell script that builds the dist/ area>
>>
>> mvn puts everything into staging (yukness => you get .asc.md5, .asc.sha1 --
>> everyone finds this and eventually just lives with it as a fact of life).
>>
>> This also creates the "source-release.zip" item which is the thing that is
>> *the* release.  Strictly, that's what the vote is about. All the other stuff
>> is not "the release".  It just the stuff people use!
>>
>> The shell script picks bytes out of the local machine maven repository.
>>  That does not include .md5/.sha1.
>>
>> In fact, we now recalculate those rather than go pull them back from Nexus
>> staging.  maven creates .md5 with just the md5 has in the file. md5sum(1)
>> puts the file name in and then "md5sum -c *.md5" works.
>>
>> Some other projects have different processes - some have good write ups.
>>  See "sling" and "rave" for examples.  "rave" has a 130 line shell script
>> that does everything - but for this first release, it might be easier to be
>> a bit more manual because it means you get the knowledge to capture in a
>> script.
>>
>>
>>> while 3 and 4 are minor, I see 1 and 2 more important - it will define
>>> the *Apache* Any23 design and the thousands (hopefully :P) of users
>>> that start develop their tools on top of Any23, will do in a way that
>>> will be backward/forward compatible.
>>>
>>> WDYT?
>>
>> 1, 2 and 3 are technical.
>>
>> 4 is major.
>>
>> I went checking ...
>>
>> The build is in a good state and most of the N&L files look OK (I didn't see
>> if the N&L files inside a jar were right - I didn't see a combined
>> redistribution N&L in the with-deps jar though).
>>
>> The RAT report is quite good - most unlicensed files are test materials (yet
>> another area for "debate" on g@i).
>>
>>        Andy
>>
>> ((
>> My experience: the first Jena release took a while to set up the N&L files,
>> but votes on -dev and g@i were straight forward.  The first TDB release got
>> a somewhat detailed analysis on g@i and provoked some discussion about what
>> actually is correct and required practice.  It's all-meant but wearing a
>> flame retardant jacket is advised.
>>
>> And the Nexus buttons in staging are very close together.  "Release" and
>> "Drop" are rather different actions but right next to each other :-)
>> ))
>>
>>
>>
>>> I'll dedicate the coming WE to Any23 to start arranging things.
>>>
>>> Have a nice day, all the best!
>>> -Simo
>>>
>>> [1] http://jcommander.org/
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Thu, Mar 29, 2012 at 6:22 PM, Lewis John Mcgibbney
>>> <le...@gmail.com>  wrote:
>>>> Hi Everyone,
>>>>
>>>> The final remaining 0.7.0 issue which I created is certainly not a
>>>> blocker,
>>>> and can wait until a later date to be addressed as I don't have time this
>>>> week.
>>>>
>>>> Are we ready to blow a 0.7.0-incubating RC?
>>>>
>>>> Here's to hoping :)
>>>>
>>>> Thanks
>>>>
>>>> Lewis
>>>>
>>>> --
>>>> *Lewis*
>>