As I said in my original post I don't think we need to be super strict and
probably don't need to enforce anything (at least not yet). When I started
the thread to establish guidelines I meant that...they would just be
guidelines or a checklist that can be loosely followed as a template for
people
Is this a matter of just be careful and provide the information with
the format we have now... or we want to enforce and change to a
certain format within commit messages (like Netty does for instance)?
On Sat, Mar 26, 2022 at 8:28 AM Christopher Shannon
wrote:
>
> JB,
>
> Right, simple things do
JB,
Right, simple things don’t need much detail. It’s pretty easy to just use
some common sense and to tell when something is trivial and doesn’t need a
lot of detail vs a more complex issue that should have a lot more written.
Things like fixing a NPE, dependency updates, logging changes, etc don
If we distinguish the simple jira where the title is enough (I'm
thinking about the dependency updates where the title is enough, but
these Jiras are good for the tracking), I generally agree.
+1 to have some guidelines in the contributor guide (in source repo
and/or website) and also in PR templa
Hi Chris-
Thanks for bringing this up.
> On Mar 25, 2022, at 5:43 AM, Christopher Shannon
> wrote:
>
> Also, keep in mind not everyone is a developer. Many users are not going to
> want to dive into the code and are not familiar with Git or how to search
> Git history etc. Yeah it's not too h
I similarly think many of the JIRAs dont have nearly enough detail. We
prepare release notes links/pages that link to JIRAs precisely because
they are meant for tracking issues, it really should have a good
summary of the issue for a user. Thats typically not really just the
same thing as a commit
Having useful information in both is necessary of course but I still think
the place the most detail is Jira and having a more compact commit message
makes more sense. Git commits should be useful and describe the issue but
if you need to add a lot of detail then Jira is the place to put it.
Also
I prefer having more information on the commit rather than the JIRA.
When I’m referring to git blame it would help to have more information on
the git commit than on the Jira BTW.
I had many cases where I had to git bisect. Or find what was the change on
the line.
As you said it (cshanon) does n
+1 to this. Particularly if there's a desire to automate more of the
announcements on the website.
If we wanted to go further someone could set up Jira fields and Github
templates to enforce these.
It's good to have context in both commits and Jira, so worst case you copy your
detailed commit
Clebert, that is a fair point, mostly I was just giving examples off the
top of my head. How the issue was found may or may not be relevant
depending on the issue so it can be skipped. Really I just want there to be
something relevant that explains the issue in some detail and how much
detail depen
Does it matter how an issue was found ?
Some explanation in what the fix is that’s a fair point. But how it was
found seems irrelevant to me.
Like not trying to play sarcasm here but I once found an issue on my
dreams. (Literally)
On Thu, Mar 24, 2022 at 4:26 PM Christopher’ Shannon .l.shan
Can you provide a few examples of problematic Jiras and/or commit messages?
Recently I started putting most (if not all) of the details for the change
in the commit message itself rather than in the Jira. These details are
added to the Jira implicitly as comments when the code is merged. However,
i
Here are a few examples of Jiras I did. Obviously I'm not perfect but I
just wanted to show samples of what I think are decent descriptions and
what I'm talkin about when I'm asking for people to include more
information:
https://issues.apache.org/jira/browse/AMQ-8287
https://issues.apache.org/jir
13 matches
Mail list logo
