zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andor Molnar <an...@cloudera.com.INVALID>
Subject Re: Question on ZK commit/patch policy.
Date Tue, 05 Mar 2019 20:04:41 GMT
Having no Jira doesn't prevent you explaining clearly what and why you're
doing in that change with a proper commit message.
It's actually much more convenient when you quickly want to git blame
something.

Andor



On Tue, Mar 5, 2019 at 12:00 PM Jordan Zimmerman <jordan@jordanzimmerman.com>
wrote:

> Even on "trivial" changes having a Jira is very useful. Jira issues show
> up in Release Notes and when end users search for problems/solutions. Even
> a trivial change may be important to some user of ZooKeeper who might want
> to be able to check Jira to see when/why something happened.
>
> -JZ
>
> > On Mar 5, 2019, at 4:16 AM, Justin Ling Mao <maoling199210191@sina.com>
> wrote:
> >
> > agree with this from Brian Nixon.--->"For trivial changes like spelling,
> whitespace, pruning of import, does itmake sense to have one super/umbrella
> ticket with multiple PRs attached"
> > ----- Original Message -----From: Brian Nixon <brian.nixon.cs@gmail.com>
> > To: dev@zookeeper.apache.org
> > Subject: Re: Question on ZK commit/patch policy.
> > Date: 2019-03-05 05:54
> >
> > I like having JIRAs for all changes because it allows one to track all
> the
> > changes to given components through the JIRA web interface and it forces
> > the contributor to spend some time upfront making sure their change is a
> > single coherent unit.
> > For trivial changes like spelling, whitespace, pruning of import, does it
> > make sense to have one super/umbrella ticket with multiple PRs attached?
> > -Brian
> > On Wed, Feb 27, 2019 at 1:04 PM Enrico Olivelli <eolivelli@gmail.com>
> wrote:
> >> I think that having a JIRA makes it simpler to create release notes and
> >> track bugfixes/new features.
> >> Trivial changes, like typos are not worth a JIRA.
> >>
> >> My 2 cents
> >> Enrico
> >>
> >> Il mer 27 feb 2019, 17:57 Patrick Hunt <phunt@apache.org> ha scritto:
> >>
> >>> Yea, the commit I just did was a single missing space so no big deal.
> >>> Jordan's link is to curator current policy which seems very similar to
> >>> ours.
> >>>
> >>> I know what current state is. My question though is what do people
> think?
> >>> Stay with the current mechanism or move to something else? Staying put
> is
> >>> fine, I just wanted to review given it's been a while (10+ years!)
> since
> >> we
> >>> last considered this and with github/gitbox and time baselines have
> >> changed
> >>> considerably over that time.
> >>>
> >>> Patrick
> >>>
> >>>
> >>> On Wed, Feb 27, 2019 at 8:44 AM Andor Molnar
> <andor@cloudera.com.invalid
> >>>
> >>> wrote:
> >>>
> >>>> There were a few typo/language/cosmetic related patches which were so
> >>> small
> >>>> that we've decided it's probably not worth the effort to create a Jira
> >>> for
> >>>> every one of them.
> >>>> Similarly, I haven't created Jiras for issues that were found in
> >> release
> >>>> candidates.
> >>>>
> >>>> Other than this we generally still don't accept patches without Jira
> >>> ticket
> >>>> and properly formatted title / commit message.
> >>>>
> >>>> Andor
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Feb 27, 2019 at 5:38 PM Patrick Hunt <phunt@apache.org>
> wrote:
> >>>>
> >>>>> Historically we've only committed changes that have an associated
> >> JIRA.
> >>>> Now
> >>>>> with the move to gitbox we are seeing increased submissions (PRs)
> >> that
> >>>>> don't include a JIRA - I just committed one and then realized that
it
> >>>>> didn't include a JIRA (sorry about that!). Given github and the
> >> recent
> >>>> move
> >>>>> to gitbox significantly streamlines the contribution process I'm
> >>>> wondering
> >>>>> if we should reconsider our process. Any thoughts? Anyone work on
> >>> another
> >>>>> Apache project that does things differently and has pro/con to share?
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Patrick
> >>>>>
> >>>>
> >>>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message