[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    Re: [DISCUSS] Guidelines for new Jiras and Commit messages
From:       Christopher Shannon <christopher.l.shannon () gmail ! com>
Date:       2022-03-28 10:37:17
Message-ID: CACHnxzx7_Mb0uoLC=w8U6O73DG04vDat+rzHHRGgtUbc9mPnew () mail ! gmail ! com
[Download RAW message or body]


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 to help them out with filling out new Jiras. There's going to be
reasons to deviate but it could be a good starting point.

My goal here is not to create a bunch of work on people or for it to be a
big burden, just to help make sure Jiras have useful info. So maybe at
first we just add a section to the committer page that just describes the
kind of information a good Jira and good commit message should contain and
go from there vs establishing anything formal or enforced.

On Sat, Mar 26, 2022 at 11:20 AM Clebert Suconic <clebert.suconic@gmail.com>
wrote:

> 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
> <christopher.l.shannon@gmail.com> wrote:
> >
> > 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't
> > need much info at all and could just have a title and no description of
> the
> > title is self explanatory.
> >
> > But new features, most bug fixes, or major changes should have some
> details
> > written to help understand the issue.
> >
> > On Sat, Mar 26, 2022 at 1:40 AM Jean-Baptiste Onofré <jb@nanthrax.net>
> > wrote:
> >
> > > 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 template on github.
> > >
> > > Regards
> > > JB
> > >
> > > On Thu, Mar 24, 2022 at 9:25 PM Christopher Shannon
> > > <christopher.l.shannon@gmail.com> wrote:
> > > >
> > > > As I brought up in the Artemis 2.21.0 vote thread I have noticed a
> > > pattern
> > > > of Jiras that have almost no information in them which makes it very
> > > > difficult to follow along with bug fixes and new features. This made
> > > > reviewing the current release more difficult. Some issues are
> trivial but
> > > > most issues should have a good description to document the change.
> > > >
> > > > I am proposing that going forward we come up with a template/guide or
> > > > checklist of some sort for Jiras for people to follow, kind of like
> > > coding
> > > > standards or a checklist for reviewing pull requests.
> > > >
> > > > It doesn't have to be super strict, but some guidelines might be
> nice.
> > > Off
> > > > the top of my head here are a few things:
> > > >
> > > > New Features:
> > > > 1) What's the motivation of the feature? Why is it needed?
> > > > 2) A high level description on the plan to implement the feature
> > > > 2) Maybe some details on how testing will be done
> > > >
> > > > Bug Fixes:
> > > > 1) How was the issue discovered?
> > > > 2) How to reproduce and what versions are affected?
> > > > 3) whats the proposed fix?
> > > >
> > > > My main motivation here is Jiras but we could also have guidelines
> for
> > > > commit messages if we want too.
> > > >
> > > > Thoughts?
> > >
>
>
>
> --
> Clebert Suconic
>


[prev in list] [next in list] [prev in thread] [next in thread]