Le jeu. 26 nov. 2020 à 16:04, Gary Gregory <garydgreg...@gmail.com> a écrit : > > On Thu, Nov 26, 2020 at 10:00 AM Gilles Sadowski <gillese...@gmail.com> > wrote: > > > Gary, > > > > Le jeu. 26 nov. 2020 à 15:47, Gary Gregory <garydgreg...@gmail.com> a > > écrit : > > > > > > On Thu, Nov 26, 2020 at 9:43 AM Gilles Sadowski <gillese...@gmail.com> > > > wrote: > > > > > > > Hello Gary. > > > > > > > > Le jeu. 26 nov. 2020 à 15:09, Gary Gregory <garydgreg...@gmail.com> a > > > > écrit : > > > > > > > > > > Please update changes.xml when you merge a PR. > > > > > > > > Since when do we require that for Javadoc clean-up? > > > > > > > > > > It's more about providing *transparency* and *documenting* the fact that > > > this change came from a PR. If the change came from a Jira issue, we'd > > have > > > an entry to show the Jira issue ID. > > > > > > This is an open-source project and to me that means being open *and* > > > transparent. > > > > I agree, but that's beside my point: You require undue work from a > > committer. People who want/need to engage in history tracking will > > need to turn to the version control system anyways. The PR number > > alone does not mean anything and is just noise in that report. > > > > A one liner in a text file is "undue work"? Yikes.
For such a change, yes. Worse than that: IMO, "nit-pick" changes should *not* be listed in "changes.xml", lest we end up with an illegible report where important modifications are drowned within a useless enumeration of spelling corrections. Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org