jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: Release 5.0 ?
Date Sun, 09 Sep 2018 15:12:05 GMT
Hello,
I've completed New and Noteworthy section.

Regards

On Fri, Sep 7, 2018 at 9:18 PM Philippe Mouawad <philippe.mouawad@gmail.com>
wrote:

> I'll be filling the new and noteworthy section but help is welcome.
>
> Regards
>
> On Fri, Sep 7, 2018 at 8:46 PM Philippe Mouawad <
> philippe.mouawad@gmail.com> wrote:
>
>> Great.
>> Thanks
>>
>> On Fri, Sep 7, 2018 at 8:42 PM Milamber <milamber@apache.org> wrote:
>>
>>>
>>>
>>> On 06/09/2018 20:44, Philippe Mouawad wrote:
>>> > Hello,
>>> > We now have 90 enhancements/bugfixes.
>>> >
>>> > The flaky nightly builds are now fine since the bug was fixed.
>>> >
>>> > So I think we can safely release this long awaited 5.0 version.
>>> >
>>> > @Milamber <mailto:milamberspace@gmail.com> , are you still ok for
>>> > creating the release ?
>>>
>>>
>>> Yes I can do the release this sunday.
>>>
>>>
>>> >
>>> >
>>> > Regards
>>> > Thanks
>>> >
>>> > On Thu, Aug 30, 2018 at 11:23 AM Milamber <milamber@apache.org
>>> > <mailto:milamber@apache.org>> wrote:
>>> >
>>> >
>>> >
>>> >     On 29/08/2018 11:52, Vladimir Sitnikov wrote:
>>> >     > Milamber>credentials must be provided
>>> >     >
>>> >     > Maven can read credentials from settings.xml, etc, etc.
>>> >
>>> >
>>> >     I don't talk about maven, but the steps about gpg sign and ant
>>> >     rc_upload/publish.
>>> >
>>> >     >
>>> >     > Milamber>Thus, a lot of steps are manual because the step need
>>> >     an human
>>> >     > checks
>>> >     > Milamber>(javadoc warning, archive checks, RAT report, etc)
>>> >     >
>>> >     > What is the point of manually checking javadoc warnings?
>>> >     > Could we just fail the build if javadoc warnings are present?
>>> >
>>> >     Currently a javadoc warning don't stop the release creation. I
>>> don't
>>> >     know if we can configure to stop if a warning occur.
>>> >
>>> >
>>> >     >
>>> >     > What do you mean by "archive checks"?
>>> >
>>> >     Verify that the source and binary archives contains the good files
>>> >     and
>>> >     that's no missing (new) files.
>>> >
>>> >     > Of course we want to have multi-stage process like:
>>> >     > 1) Prepare release candidate artifacts
>>> >     > 2) Manually inspect them (e.g. people from all over the world
>>> >     check if
>>> >     > artifacts run on their machines)
>>> >     > 3) Hit "promote" button that would make the release generally
>>> >     available
>>> >     >
>>> >     > I think #1 could be automated via Jenkins/Travis kind of job.
>>> >
>>> >     Yes the #1 (ant distribution task) can be done by any build tool
>>> >     (every
>>> >     day if we want have a project "ready to distribute")
>>> >
>>> >     > Of course "jmeter/ReleaseCreation" page could be kept for
>>> >     emergency cases,
>>> >     > however it is a pity the release procedure is so hard to follow.
>>> >     >
>>> >     > It does not matter much if we use Docker or not for the release
>>> >     though,
>>> >     > however I find it is better to use the same set of tools that is
>>> >     used
>>> >     > during regular CI.
>>> >
>>> >
>>> >     I mention Docker to help the developer to have an build
>>> >     environment on
>>> >     his machine independently to the operating system of his machine.
>>> >     The ASF build environment (jenkins) is already on linux platform
>>> >     and all
>>> >     building tools are present. No need to use Docker to regular CI.
>>> >
>>> >     > Do we use Docker for regular CI checks?
>>> >     > I don't think so. That is why I think we do not want to maintain
>>> two
>>> >     > different ways of building JMeter.
>>> >     >
>>> >     > Philippe>        - how could we improve ?:
>>> >     > Philippe>        - jenkins job ?
>>> >     >
>>> >     > I guess the question boils down to: "is it acceptable to store
>>> >     private part
>>> >     > of GPG key somewhere".
>>> >     > For pgjdbc I use Travis as a release job:
>>> >     > https://travis-ci.org/pgjdbc/pgjdbc/builds/421151967 It
>>> assembles a
>>> >     > artifacts (builds for different Java versions) and uploads them
>>> >     to Maven
>>> >     > Central.
>>> >     >
>>> >     > For JMeter, Apache Jenkins job might be good.
>>> >     >
>>> >     > The most complicated steps to automate in my opinion are related
>>> >     with "site
>>> >     > update".
>>> >     > That is "update changelog", "update versions in readme".
>>> >     Good-looking
>>> >     > "notable changes" page can hardly be automated.
>>> >     >
>>> >     > For pgjdbc we have a script
>>> >     > <https://github.com/pgjdbc/pgjdbc/blob/master/release_notes.sh>
>>> that
>>> >     > automatically creates "... released" web pages based on the
>>> >     CHANGELOG.md
>>> >     > (which is populated manually with notable changes)
>>> >     > Well, we even fetch contributor names from GitHub automatically
>>> >     >
>>> >     <
>>> https://github.com/pgjdbc/pgjdbc/blob/d43398a5d4c173da40e8f283f9e5fe20a971de5c/release_notes_filter.pl#L47-L60
>>> >
>>> >     > to populate the list of contributors in release notes
>>> >     >
>>> >     > Of course it takes a while to setup, however I think it pays off.
>>> >
>>> >     +1 if we could find the good way to manage the credential (gpg and
>>> >     ASF
>>> >     login/pass). Perhaps ask to the Infra team or ASF member list if a
>>> >     way
>>> >     already exists (I can do this if you want)
>>> >
>>> >     Milamber
>>> >
>>> >     >
>>> >     > Vladimir
>>> >     >
>>> >
>>> >
>>> >
>>> > --
>>> > Cordialement.
>>> > Philippe Mouawad.
>>> >
>>> >
>>>
>>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>
> --
> Cordialement.
> Philippe Mouawad.
>
>
>

-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message