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:milambersp...@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 <milam...@apache.org
<mailto:milam...@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.
