We're talking about things we will fix for our next release after graduating.
On Nov 24, 2011, at 9:17 AM, Carsten Ziegeler wrote:
> 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
>
