Using something like prow via Jenkins X or similar helps in automating merging PRs after they've been approved and the build has passed. Otherwise, making it a manual process will just cause headaches.
On Sun, 10 Feb 2019 at 08:52, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Sun, Feb 10, 2019 at 9:20 AM Pascal Schumacher <pascalschumac...@gmx.net> > wrote: > > > I'm not sure if the error can be fixed in the Maven Javadoc Plugin. > > > > While the bug was rejected by OpenJDK at first, is was later reopened > > and fixed, but only in Java 13 and 12.0.1: > > > > https://bugs.openjdk.java.net/browse/JDK-8212233 > > > https://issues.apache.org/jira/browse/MJAVADOC-555 will not help? > > Gary > > > > > > > Am 10.02.2019 um 14:24 schrieb Gary Gregory: > > > Note that builds that break on Java 11 due to Javadoc errors with unnamed > > > modules _should_ be fixed when the next version of the Maven Javadoc > > Plugin > > > is released (3.1.0 IIRC) > > > > > > Gary > > > > > > On Sat, Feb 9, 2019 at 11:56 AM Gilles Sadowski <gillese...@gmail.com> > > > wrote: > > > > > >> Hi. > > >> > > >> Le sam. 9 févr. 2019 à 17:10, Benedikt Ritter <brit...@apache.org> a > > >> écrit : > > >>> Hi, > > >>> > > >>> several component have are broken builds on the master branch. Should > > be > > >>> change our policy for pushing to master to a pull request based model, > > >>> where each change has to pass the CI pipeline first? I think this would > > >> be > > >>> better as pushing stuff to master and then fixing it afterwards. > > >> One thing to take into account is that some CI jobs break for "unknown" > > >> reasons (e.g. due to new requirements by Jenkins). Few people looking > > >> into these issues leads to builds staying broken for extended period of > > >> times; it would quite annoying that pushing is prevented even though > > >> local builds continue to work as usual. > > >> > > >> Gilles > > >> > > >>> Benedikt > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > -- Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
