ed"
> > - Original Message -From: Brian Nixon
> > 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
>
- Original Message -From: Brian Nixon
> 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
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
To: dev@zookeeper.apache.org
Subject: Re: Question
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
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 ha scritto:
> Yea, the commit I just did was a single missing space so no big deal.
>
I tend to agree with Tamaas. A few lines of typo fix and similar patches
should be OK.
Anything bigger, it should have a jira. Basically how it was done recently.
Regards,
Norbert
On Wed, Feb 27, 2019 at 6:51 PM Tamas Penzes
wrote:
> I think we should have a jira for all significant changes,
I think we should have a jira for all significant changes, and I would let
the committer decide about what is significant or not.
Basically anything worth to mention in the release notes should get a jira,
but for typo fixes or other similar things we could spare it.
Just my thoughts.
Regards,
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
Is it because of simplicity (no need to decide whether a jira is necessary) or
there’s a huge downside of committing patches without Jiras?
Andor
> On 2019. Feb 27., at 17:41, Jordan Zimmerman
> wrote:
>
> For Curator we require a Jira. If we get a PR without a Jira we always ask
> them
For Curator we require a Jira. If we get a PR without a Jira we always ask them
to create one.
-JZ
> On Feb 27, 2019, at 11:37 AM, Patrick Hunt wrote:
>
> Historically we've only committed changes that have an associated JIRA. Now
> with the move to gitbox we are seeing increased submissions
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
Note: we discuss this on our wiki too:
https://cwiki.apache.org/confluence/display/CURATOR/Submitting+Pull+Requests
> On Feb 27, 2019, at 11:37 AM, Patrick Hunt wrote:
>
> Historically we've only committed changes that have an associated JIRA. Now
> with the move to gitbox we are seeing
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
13 matches
Mail list logo
