You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jmeter.apache.org by Philippe Mouawad <ph...@gmail.com> on 2018/09/06 20:44:50 UTC
Re: Release 5.0 ?
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 <mi...@gmail.com> , are you still ok for creating the
release ?
Regards
Thanks
On Thu, Aug 30, 2018 at 11:23 AM Milamber <mi...@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.
Re: Release 5.0 ?
Posted by Philippe Mouawad <ph...@gmail.com>.
Hello,
I've completed New and Noteworthy section.
Regards
On Fri, Sep 7, 2018 at 9:18 PM Philippe Mouawad <ph...@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 <mi...@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 <ma...@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
>>> > <ma...@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.
Re: Release 5.0 ?
Posted by Philippe Mouawad <ph...@gmail.com>.
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 <ph...@gmail.com>
wrote:
> Great.
> Thanks
>
> On Fri, Sep 7, 2018 at 8:42 PM Milamber <mi...@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 <ma...@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
>> > <ma...@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.
Re: Release 5.0 ?
Posted by Philippe Mouawad <ph...@gmail.com>.
Great.
Thanks
On Fri, Sep 7, 2018 at 8:42 PM Milamber <mi...@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 <ma...@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
> > <ma...@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.
Re: Release 5.0 ?
Posted by Milamber <mi...@apache.org>.
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 <ma...@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
> <ma...@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.
>
>