@Gilles
> The Commons project has existed for more than 15 years, and
> the history of the repositories is the best resource for the
> current style. By spending a few minutes perusing through the
> commit logs, a new contributor can obtain a pretty good image
> of how to comment the various
On 7/5/20 6:02 PM, Phil Steitz wrote:
On 7/5/20 11:07 AM, Phil Steitz wrote:
The test looks a little off to me. I am not sure I fully understand
what it is trying to do, but I suspect that the reason that it fails
sporadically (I have seen this myself) is that to succeed it needs to
run
On 7/5/20 11:07 AM, Phil Steitz wrote:
The test looks a little off to me. I am not sure I fully understand
what it is trying to do, but I suspect that the reason that it fails
sporadically (I have seen this myself) is that to succeed it needs to
run two evictor cycles when it is set to
Not a committer, just an interested observer, I got on this list because of
a PR I submitted to commons-math long ago, and have stayed on since.
There is a standard for commit messages I came across recently and which
our team is trying to apply to our own commit messages. Idea is to make
commit
Hi.
Le dim. 5 juil. 2020 à 22:31, Gary Gregory a écrit :
>
> I agree with Xenos.
Accepting PRs with uninformative (for short) messages is eroding
what regular contributors have established over the years in order
to make it possible to track the history of changes.
Do you suggest that we
Hi.
Le dim. 5 juil. 2020 à 21:26, Xeno Amess a écrit :
>
> @Gilles
> If you want a good commit message you should define good first.
I did provide some hints, in the first post. And others have given
additional suggestions.
> And you should understand everybody is using what he think the best
I agree with Xenos.
Gary
On Sun, Jul 5, 2020, 15:26 Xeno Amess wrote:
> @Gilles
> If you want a good commit message you should define good first.
> And you should understand everybody is using what he think the best style
> in commit logs. (at least most of the times, when they are not in
@Gilles
If you want a good commit message you should define good first.
And you should understand everybody is using what he think the best style
in commit logs. (at least most of the times, when they are not in hurry).
If you really want this I think you should write a guideline or rule set
for
Hi Matt.
Le dim. 5 juil. 2020 à 13:39, Matt Juntunen
a écrit :
>
> Yes, I should have modified that commit message to indicate that the change
> was warranted.
Thanks for the good intention, but what I'm really getting at is that
PRs for our projects should already contain a good commit
Hi.
Le dim. 5 juil. 2020 à 13:26, Matt Juntunen
a écrit :
>
> What are your objections to the name? The new name is more consistent with
> JDK conventions.
It is a programming error (as opposed to a usage error, which
subclasses of "RuntimeException" represent). As such it is
more
The test looks a little off to me. I am not sure I fully understand
what it is trying to do, but I suspect that the reason that it fails
sporadically (I have seen this myself) is that to succeed it needs to
run two evictor cycles when it is set to wait for only one. I may be
wrong as I don't
This must be some timing issue as the test passed on GitHub and Travis,
but, I do see one failure for that on Java 11 on GitHub.
I am guessing the test might need to be set up differently.
Gary
On Fri, Jul 3, 2020, 14:35 Robert Paschek
wrote:
> Hello,
>
> when I'm running mvn clean test on
It's ok IMO to say "Add Javadoc" vs. "Fix Javadoc" vs. "Expand Javadoc".
Plain "Javadoc" is ok if terse.
I like the format of the first line standing on its own as a sentence. Then
there can be a blank line followed by details. That first line can be a
JIRA title.
For example, excluding the
Here is an excellent blog post summarizing what makes good commit messages:
https://chris.beams.io/posts/git-commit/
On Sun, Jul 5, 2020 at 7:38 AM Matt Juntunen
wrote:
> Yes, I should have modified that commit message to indicate that the
> change was warranted.
> -Matt
>
IMO, the log message serves the following main purposes:
- explains why the change was made, so reviewers can properly check
that the diff agrees
- identifies the change in the historical log so it can be found easily
Information necessary to understand the code should be added to the
source, not
Yes, I should have modified that commit message to indicate that the change was
warranted.
-Matt
From: Gilles Sadowski
Sent: Sunday, July 5, 2020 4:00 AM
To: Commons Developers List
Subject: [All][Geometry] Commit log (Was: [GitHub] ...)
Hello.
I'd like to
What are your objections to the name? The new name is more consistent with JDK
conventions.
Also, this class is not part of the public API.
-Matt
From: Gilles Sadowski
Sent: Sunday, July 5, 2020 4:06 AM
To: Commons Developers List
Subject: Re:
-1
Personally, I don't agree with the rationale.
Anyways, such a change must be proposed on the "dev" ML and, if
agreed upon, be related to a JIRA report.
Regards,
Gilles
Le sam. 4 juil. 2020 à 13:44, a écrit :
>
> This is an automated email from the ASF dual-hosted git repository.
>
>
Hello.
I'd like to collect some opinions about enforcing a minimal form in
commit messages.
My preference is that a log message is either
* terse, when the commit is trivial (e.g. "Javadoc" or "Unused variable"), or
* detailed but factual, if the change is not obvious.
IMHO, a commit message
19 matches
Mail list logo
