Hello, I've completed New and Noteworthy section. Regards
On Fri, Sep 7, 2018 at 9:18 PM Philippe Mouawad <[email protected]> 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 < > [email protected]> wrote: > >> Great. >> Thanks >> >> On Fri, Sep 7, 2018 at 8:42 PM Milamber <[email protected]> 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:[email protected]> , 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 <[email protected] >>> > <mailto:[email protected]>> 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.
