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 <milambersp...@gmail.com> , are you still ok for creating the release ? Regards Thanks On Thu, Aug 30, 2018 at 11:23 AM Milamber <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.
