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

Reply via email to