are JIRAs mandatory for every change?

["Koper, Dies" <di...@fast.au.fujitsu.com>]

Abayer, gaul, nacx and I had a brief discussion about whether we
required a JIRA before merging my PR[1].
This particular PR is for a patch that fixes issues found while running
the live tests for provider fgcp, which is in labs, but the purpose of
this e-mail is to start a discussion about whether we need a general
policy and what it should be.

For your reference, in Deltacloud we sometimes open JIRAs for patches
and sometimes we do not. So I suppose there is no ASF requirement.

It generally depends on the case: a JIRA may help to discuss and track a
new feature requirement or investigate a bug, i.e. when you are
collaboration on the problem that needs to be addressed, and the
collaboration may take days to weeks to months. Or track tasks.
In other cases, there is no collaboration required because the cause is
obvious and quick to fix, and/or because there is only one committer
looking into it deeply anyway (because others don't have the environment
to reproduce it or don't have the knowledge/background). In this case I
suppose we believe the JIRA only adds overhead as PR notifications are
sent to the mailing list anyway.

So in Deltacloud we haven't had a need to make JIRAs mandatory.

[1] https://github.com/jclouds/jclouds-labs/pull/5

Regards,
Dies Koper

Re: are JIRAs mandatory for every change?

[Ignasi <ig...@gmail.com>]

Currently there are only two ways for non-commiters to request/submit
a feature/bugfix: opening a JIRA or opening a pull request, so we can
expect most contributions will have the corresponding JIRA (and if
there is only a pull request we can ask to open a JIRA).

So I think this applies mostly for commiters. IMO JIRAs are good. They
will help us keep track of which changes are in each version, generate
the release notes, and so on, so I'd say, if in doubt, open a JIRA.
Commiters also do a lot of cleanup and maintenance work, and often
opening JIRAs for all that stuff seems not practical. (Take as an
example the changes needed to address the small bits to properly
rlease 1.6.1-incubating).

I'm aligned with Andrew B. I'd not say JIRAs are mandatory, but we
should open JIRAs by default.




On 28 May 2013 21:44, Andrew Gaul <ga...@maginatics.com> wrote:
> I prefer not to require a JIRA for every commit.  We have a lot of churn
> for small, disparate cleanups and modernizations that opening a JIRA for
> seems wasted on, both for the reporter and the readers.
>
> I would like to encourage people to use JIRA for non-bugs, for example,
> adding a new provider like RDS or cleanups to a specific provider like
> FGCP.  This gives a way to track related commits.
>
> The basic rule of thumb I like: if there will be more than one commit in
> a series or changes that likely promote discussion, open a JIRA.
>
> On Tue, May 28, 2013 at 10:44:10AM -0700, Matt Stephenson wrote:
>> I'm in agreement, basically the rule of thumb i've used in the past is if
>> it doesn't merit a Jira, it's probably something we should have a Jira to
>> automate/prevent in the future.  The example of formatting changes should
>> be addressed with a Jira on fixing the checkstyle rules or adding some
>> other tool to prevent someone from having to manually fix it in the future.
>>
>>
>> On Tue, May 28, 2013 at 9:52 AM, Andrew Bayer <an...@gmail.com>wrote:
>>
>> > Anything other than truly minor things like fixing indentation and the like
>> > merit a JIRA, IMO.
>> >
>> > A.
>> >
>> > On Mon, May 27, 2013 at 9:02 PM, Everett Toews
>> > <ev...@rackspace.com>wrote:
>> >
>> > > IMHO, no. I agreed with pretty much everything you said here.
>> > >
>> > > Pedantic rules like "A JIRA issue is required for every PR" are scary. It
>> > > feels like process for process sake.
>> > >
>> > > If someone wants to fix just the indentation for an XML file, does that
>> > > really need a JIRA issue? I don't think so.
>> > >
>> > > Everett
>> > >
>> > > On May 23, 2013, at 6:42 PM, Koper, Dies wrote:
>> > >
>> > > > Abayer, gaul, nacx and I had a brief discussion about whether we
>> > > > required a JIRA before merging my PR[1].
>> > > > This particular PR is for a patch that fixes issues found while running
>> > > > the live tests for provider fgcp, which is in labs, but the purpose of
>> > > > this e-mail is to start a discussion about whether we need a general
>> > > > policy and what it should be.
>> > > >
>> > > > For your reference, in Deltacloud we sometimes open JIRAs for patches
>> > > > and sometimes we do not. So I suppose there is no ASF requirement.
>> > > >
>> > > > It generally depends on the case: a JIRA may help to discuss and track
>> > a
>> > > > new feature requirement or investigate a bug, i.e. when you are
>> > > > collaboration on the problem that needs to be addressed, and the
>> > > > collaboration may take days to weeks to months. Or track tasks.
>> > > > In other cases, there is no collaboration required because the cause is
>> > > > obvious and quick to fix, and/or because there is only one committer
>> > > > looking into it deeply anyway (because others don't have the
>> > environment
>> > > > to reproduce it or don't have the knowledge/background). In this case I
>> > > > suppose we believe the JIRA only adds overhead as PR notifications are
>> > > > sent to the mailing list anyway.
>> > > >
>> > > > So in Deltacloud we haven't had a need to make JIRAs mandatory.
>> > > >
>> > > > [1] https://github.com/jclouds/jclouds-labs/pull/5
>> > > >
>> > > > Regards,
>> > > > Dies Koper
>> > > >
>> > >
>> > >
>> >
>
> --
> Andrew Gaul
> http://maginatics.com/

Re: are JIRAs mandatory for every change?

[Andrew Gaul <ga...@maginatics.com>]

I prefer not to require a JIRA for every commit.  We have a lot of churn
for small, disparate cleanups and modernizations that opening a JIRA for
seems wasted on, both for the reporter and the readers.

I would like to encourage people to use JIRA for non-bugs, for example,
adding a new provider like RDS or cleanups to a specific provider like
FGCP.  This gives a way to track related commits.

The basic rule of thumb I like: if there will be more than one commit in
a series or changes that likely promote discussion, open a JIRA.

On Tue, May 28, 2013 at 10:44:10AM -0700, Matt Stephenson wrote:
> I'm in agreement, basically the rule of thumb i've used in the past is if
> it doesn't merit a Jira, it's probably something we should have a Jira to
> automate/prevent in the future.  The example of formatting changes should
> be addressed with a Jira on fixing the checkstyle rules or adding some
> other tool to prevent someone from having to manually fix it in the future.
> 
> 
> On Tue, May 28, 2013 at 9:52 AM, Andrew Bayer <an...@gmail.com>wrote:
> 
> > Anything other than truly minor things like fixing indentation and the like
> > merit a JIRA, IMO.
> >
> > A.
> >
> > On Mon, May 27, 2013 at 9:02 PM, Everett Toews
> > <ev...@rackspace.com>wrote:
> >
> > > IMHO, no. I agreed with pretty much everything you said here.
> > >
> > > Pedantic rules like "A JIRA issue is required for every PR" are scary. It
> > > feels like process for process sake.
> > >
> > > If someone wants to fix just the indentation for an XML file, does that
> > > really need a JIRA issue? I don't think so.
> > >
> > > Everett
> > >
> > > On May 23, 2013, at 6:42 PM, Koper, Dies wrote:
> > >
> > > > Abayer, gaul, nacx and I had a brief discussion about whether we
> > > > required a JIRA before merging my PR[1].
> > > > This particular PR is for a patch that fixes issues found while running
> > > > the live tests for provider fgcp, which is in labs, but the purpose of
> > > > this e-mail is to start a discussion about whether we need a general
> > > > policy and what it should be.
> > > >
> > > > For your reference, in Deltacloud we sometimes open JIRAs for patches
> > > > and sometimes we do not. So I suppose there is no ASF requirement.
> > > >
> > > > It generally depends on the case: a JIRA may help to discuss and track
> > a
> > > > new feature requirement or investigate a bug, i.e. when you are
> > > > collaboration on the problem that needs to be addressed, and the
> > > > collaboration may take days to weeks to months. Or track tasks.
> > > > In other cases, there is no collaboration required because the cause is
> > > > obvious and quick to fix, and/or because there is only one committer
> > > > looking into it deeply anyway (because others don't have the
> > environment
> > > > to reproduce it or don't have the knowledge/background). In this case I
> > > > suppose we believe the JIRA only adds overhead as PR notifications are
> > > > sent to the mailing list anyway.
> > > >
> > > > So in Deltacloud we haven't had a need to make JIRAs mandatory.
> > > >
> > > > [1] https://github.com/jclouds/jclouds-labs/pull/5
> > > >
> > > > Regards,
> > > > Dies Koper
> > > >
> > >
> > >
> >

-- 
Andrew Gaul
http://maginatics.com/

Re: are JIRAs mandatory for every change?

[Matt Stephenson <ma...@mattstep.net>]

I'm in agreement, basically the rule of thumb i've used in the past is if
it doesn't merit a Jira, it's probably something we should have a Jira to
automate/prevent in the future.  The example of formatting changes should
be addressed with a Jira on fixing the checkstyle rules or adding some
other tool to prevent someone from having to manually fix it in the future.


On Tue, May 28, 2013 at 9:52 AM, Andrew Bayer <an...@gmail.com>wrote:

> Anything other than truly minor things like fixing indentation and the like
> merit a JIRA, IMO.
>
> A.
>
> On Mon, May 27, 2013 at 9:02 PM, Everett Toews
> <ev...@rackspace.com>wrote:
>
> > IMHO, no. I agreed with pretty much everything you said here.
> >
> > Pedantic rules like "A JIRA issue is required for every PR" are scary. It
> > feels like process for process sake.
> >
> > If someone wants to fix just the indentation for an XML file, does that
> > really need a JIRA issue? I don't think so.
> >
> > Everett
> >
> > On May 23, 2013, at 6:42 PM, Koper, Dies wrote:
> >
> > > Abayer, gaul, nacx and I had a brief discussion about whether we
> > > required a JIRA before merging my PR[1].
> > > This particular PR is for a patch that fixes issues found while running
> > > the live tests for provider fgcp, which is in labs, but the purpose of
> > > this e-mail is to start a discussion about whether we need a general
> > > policy and what it should be.
> > >
> > > For your reference, in Deltacloud we sometimes open JIRAs for patches
> > > and sometimes we do not. So I suppose there is no ASF requirement.
> > >
> > > It generally depends on the case: a JIRA may help to discuss and track
> a
> > > new feature requirement or investigate a bug, i.e. when you are
> > > collaboration on the problem that needs to be addressed, and the
> > > collaboration may take days to weeks to months. Or track tasks.
> > > In other cases, there is no collaboration required because the cause is
> > > obvious and quick to fix, and/or because there is only one committer
> > > looking into it deeply anyway (because others don't have the
> environment
> > > to reproduce it or don't have the knowledge/background). In this case I
> > > suppose we believe the JIRA only adds overhead as PR notifications are
> > > sent to the mailing list anyway.
> > >
> > > So in Deltacloud we haven't had a need to make JIRAs mandatory.
> > >
> > > [1] https://github.com/jclouds/jclouds-labs/pull/5
> > >
> > > Regards,
> > > Dies Koper
> > >
> >
> >
>

Re: are JIRAs mandatory for every change?

[Andrew Bayer <an...@gmail.com>]

Anything other than truly minor things like fixing indentation and the like
merit a JIRA, IMO.

A.

On Mon, May 27, 2013 at 9:02 PM, Everett Toews
<ev...@rackspace.com>wrote:

> IMHO, no. I agreed with pretty much everything you said here.
>
> Pedantic rules like "A JIRA issue is required for every PR" are scary. It
> feels like process for process sake.
>
> If someone wants to fix just the indentation for an XML file, does that
> really need a JIRA issue? I don't think so.
>
> Everett
>
> On May 23, 2013, at 6:42 PM, Koper, Dies wrote:
>
> > Abayer, gaul, nacx and I had a brief discussion about whether we
> > required a JIRA before merging my PR[1].
> > This particular PR is for a patch that fixes issues found while running
> > the live tests for provider fgcp, which is in labs, but the purpose of
> > this e-mail is to start a discussion about whether we need a general
> > policy and what it should be.
> >
> > For your reference, in Deltacloud we sometimes open JIRAs for patches
> > and sometimes we do not. So I suppose there is no ASF requirement.
> >
> > It generally depends on the case: a JIRA may help to discuss and track a
> > new feature requirement or investigate a bug, i.e. when you are
> > collaboration on the problem that needs to be addressed, and the
> > collaboration may take days to weeks to months. Or track tasks.
> > In other cases, there is no collaboration required because the cause is
> > obvious and quick to fix, and/or because there is only one committer
> > looking into it deeply anyway (because others don't have the environment
> > to reproduce it or don't have the knowledge/background). In this case I
> > suppose we believe the JIRA only adds overhead as PR notifications are
> > sent to the mailing list anyway.
> >
> > So in Deltacloud we haven't had a need to make JIRAs mandatory.
> >
> > [1] https://github.com/jclouds/jclouds-labs/pull/5
> >
> > Regards,
> > Dies Koper
> >
>
>

Re: are JIRAs mandatory for every change?

[Everett Toews <ev...@RACKSPACE.COM>]

IMHO, no. I agreed with pretty much everything you said here.

Pedantic rules like "A JIRA issue is required for every PR" are scary. It feels like process for process sake.

If someone wants to fix just the indentation for an XML file, does that really need a JIRA issue? I don't think so.

Everett

On May 23, 2013, at 6:42 PM, Koper, Dies wrote:

> Abayer, gaul, nacx and I had a brief discussion about whether we
> required a JIRA before merging my PR[1].
> This particular PR is for a patch that fixes issues found while running
> the live tests for provider fgcp, which is in labs, but the purpose of
> this e-mail is to start a discussion about whether we need a general
> policy and what it should be.
> 
> For your reference, in Deltacloud we sometimes open JIRAs for patches
> and sometimes we do not. So I suppose there is no ASF requirement.
> 
> It generally depends on the case: a JIRA may help to discuss and track a
> new feature requirement or investigate a bug, i.e. when you are
> collaboration on the problem that needs to be addressed, and the
> collaboration may take days to weeks to months. Or track tasks.
> In other cases, there is no collaboration required because the cause is
> obvious and quick to fix, and/or because there is only one committer
> looking into it deeply anyway (because others don't have the environment
> to reproduce it or don't have the knowledge/background). In this case I
> suppose we believe the JIRA only adds overhead as PR notifications are
> sent to the mailing list anyway.
> 
> So in Deltacloud we haven't had a need to make JIRAs mandatory.
> 
> [1] https://github.com/jclouds/jclouds-labs/pull/5
> 
> Regards,
> Dies Koper
>