The proposal sounds good to me - just to be sure, are we talking about
a new release before graduation or are we talking about how to fix
things after graduation?
Carsten
2011/11/24 Jean-Baptiste Onofré <j...@nanthrax.net>:
> +1 about the Karl's proposal.
>
> I'm gonna work on the Maven build in that way, agreed with the Karl's
> proposal.
>
> Regards
> JB
>
> On 11/23/2011 09:14 PM, Karl Pauls wrote:
>>
>> On Wed, Nov 23, 2011 at 8:39 PM, Marcel Offermans
>> <marcel.offerm...@luminis.nl> wrote:
>>>
>>> +1, I think providing such a script is a good way to do it, it makes
>>> checking and building the individual components a lot easier whilst still
>>> maintaining the flexibility of being able to release any subset of
>>> artifacts. I also agree that we should correct the oversight of not shipping
>>> the pom.xml file as part of the source distribution for future releases.
>>
>> Yeah, again, that is just a configuration we have to set so that it
>> not only generates the -sources.jar but also the -project.{zip,tar.gz}
>> just like we do at felix. Without that (and there I totally agree with
>> ant and sebb on this one), it sucks rocks as you have to massage the
>> stuff quite a bit to get it to work and don't even have the tests,
>> etc. :-(.
>>
>> I think having the -projects plus the two scripts are a good way to go
>> (technically, its close to releasing the reactor pom - which would be
>> even easier - but this way, we don't have to tag the trunk). The
>> script will be simple, just unzip all -projects,cd into each, mvn
>> clean install, cd out again. That plus the correct list of artifacts
>> we can give in the vote mail is all that is needed inside the script.
>>
>> regards,
>>
>> Karl
>>
>>> Greetings, Marcel
>>>
>>> On Nov 23, 2011, at 14:00 PM, Karl Pauls wrote:
>>>
>>>> Hm, after thinking about it for a while, we already have a script for
>>>> getting the release and verify its checksums etc. -- hence, why don't
>>>> we provide another one which builds all artifacts as well?
>>>>
>>>> This way, we would not need to release the trunk but could still have
>>>> the individual releases. It would look something like:
>>>>
>>>> sh check_staged_release.sh<repo-id> <tmp-dir> # downloads all release
>>>> artifact from the given staging repo to tmp-dir and verify checksums
>>>> are present and correct
>>>> sh build_release_artifacts.sh<ordered-list-of-module-names>
>>>> <tmp-dir-with-artifacts-downloaded-by-previous-step> # unpack all
>>>> artifact source distros and build them
>>>>
>>>> Obviously, we would provide the missing params in the release vote
>>>> mail so that all one has to do is to copy'n'past the two lines into
>>>> the shell (after maybe downloading the two scripts from svn).
>>>>
>>>> I think that (together with providing the maven source distributions
>>>> per artifact which we missed in 0.8.0 ) would make it not that hard to
>>>> checkout and build and with the source distros one also gets the unit
>>>> tests which would run during the build (so some level of testing is
>>>> there as well).
>>>>
>>>> How about that?
>>>>
>>>> regards,
>>>>
>>>> Karl
>>>>
>>>> On Wed, Nov 23, 2011 at 10:12 AM, ant elder<ant.el...@gmail.com> wrote:
>>>>>
>>>>> Hi, I'm one of the ones over on general@incubator that was commenting
>>>>> about the 0.8.0 release not being perfect. To avoid all the traffic on
>>>>> the other lists could we talk about that here?
>>>>>
>>>>> I think there was some agreement releases had to have the complete
>>>>> source in a form that enables development to be done using that
>>>>> source, there is some doc on this at
>>>>> http://www.apache.org/dev/release.html#what and also some helpful
>>>>> commentary in this email
>>>>> http://apache.markmail.org/message/3odlybipss4wnczl - "we require that
>>>>> the release include all of the source code for the product (every
>>>>> component of that product in a format that can be edited for later
>>>>> maintenance of that product as open source)"
>>>>>
>>>>> Also, when doing a release its required that at least three PMC
>>>>> members review and vote on the release to verify that its good.
>>>>> There's some commentary on that in this email
>>>>> http://apache.markmail.org/message/njray5dbazwcdcts - "we require a
>>>>> person to download the signed source code package, compile it as
>>>>> provided, and test the resulting executable on their own platform
>>>>> *before* voting +1 on the release"
>>>>>
>>>>> Looking at the 0.8.0 release vote i think that would be difficult to
>>>>> do because there are so many individual parts, probably too many for
>>>>> anyone to try to build them all, so i'm guessing no one did and thats
>>>>> why no one noticed that the source was incomplete.
>>>>>
>>>>>
>>>>> http://mail-archives.apache.org/mod_mbox/incubator-ace-dev/201105.mbox/%3CBANLkTimw_15axkojKwVSVtdHfOPVB_fLEw%40mail.gmail.com%3E
>>>>>
>>>>> Other projects when releasing multiple modules like this include one
>>>>> big source distribution to enable building everything together just
>>>>> like you do when developing on an SVN trunk checkout. Do you think
>>>>> there could be one of those for ACE? Or If not and there was another
>>>>> release like the 0.8.0 one then on the release vote like that what
>>>>> exactly is it people should do to decide whether or not to vote +1?
>>>>>
>>>>> ...ant
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Karl Pauls
>>>> karlpa...@gmail.com
>>>> http://twitter.com/karlpauls
>>>> http://www.linkedin.com/in/karlpauls
>>>> https://profiles.google.com/karlpauls
>>>>
>>>
>>>
>>
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Carsten Ziegeler
cziege...@apache.org
