zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Olivelli <eolive...@gmail.com>
Subject Re: Question on ZK commit/patch policy.
Date Wed, 27 Feb 2019 21:04:33 GMT
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