Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rohit Yadav]

All, I've started a voting thread for the proposal.


Please do vote and share any thoughts, questions that we've not already 
discussed. Thanks.


- Rohit

<https://cloudstack.apache.org>




From: Rohit Yadav <rohit.ya...@shapeblue.com>
Sent: Friday, March 23, 2018 6:54:55 PM
To: dev@cloudstack.apache.org
Cc: us...@cloudstack.apache.org
Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

Thanks all for your feedback. Since it's been positive so far, I'll start a 
vote on Monday to formalize this.

In the meanwhile, please keep sharing your feedback and opinion. Thanks (and 
happy weekends).


- Rohit

<https://cloudstack.apache.org>




From: Syed Ahmed <sah...@cloudops.com>
Sent: Thursday, March 22, 2018 12:51:01 AM
To: dev@cloudstack.apache.org
Cc: us...@cloudstack.apache.org
Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

+1 To Rohit’s suggestion
On Wed, Mar 21, 2018 at 11:35 AM Khosrow Moossavi <kmooss...@cloudops.com>
wrote:

> Thanks Rohit, that's a really great sum-up of proposition!
>
> According to the private issue topic, as far as I understand, we don't have
> any private issue per se, unless they are security, vulnerability
> or CVE related and the process of reporting them -being really private
> until they are fixed- are well-defined. So I would say the mentioned
> security@ ML and have an interim ticket in Jira or the ML itself works and
> when the fix is out, for sake of archive, the issue can be created
> in GH and set as closed right away.
>
>
>
> On Wed, Mar 21, 2018 at 6:38 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > I think that works as well. Let's see what others think about it.
> >
> > On Wed, Mar 21, 2018 at 4:15 AM, Rohit Yadav <rohit.ya...@shapeblue.com>
> > wrote:
> >
> > > Thanks Rafael for your inputs. You're right about access control
> > > limitation on Github.
> > >
> > >
> > > However, I think having another repository to track security stuff can
> > add
> > > overhead (and to manage its custom ACLs with INFRA, as all cloudstack*
> > > repos are allowed access to all PMC/committers now).
> > >
> > >
> > > Users are advised to report security issues on security@, so how about
> > we
> > > continue to use JIRA for security issues (logging, tracking, and
> > > discussions) and limit the proposed change to just moving to Github
> > issues
> > > as a first step?
> > >
> > >
> > > - Rohit
> > >
> > > <https://cloudstack.apache.org>
> > >
> > >
> > >
> > > 
> > > From: Rafael Weingärtner <rafaelweingart...@gmail.com>
> > > Sent: Tuesday, March 20, 2018 11:46:32 PM
> > > To: dev
> > > Cc: us...@cloudstack.apache.org
> > > Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
> > >
> > > It looks like you have done all of the homework here. If it comes to a
> > > vote, I am +1 on migrating issues to Github, and even the Wiki in the
> > > future.  The Github would be able to pretty much provide everything
> that
> > we
> > > have in both Wiki and Jira. Therefore, it feels better to work on a
> > single
> > > platform than to spread information across them. However, we still have
> > one
> > > problem. The security issues/tickets in Jira. How can we manage them in
> > > Github? As far as I know, there is no way to control the access to
> > certain
> > > issues/tickets in Github.
> > >
> > > To tackle that problem with security issues we could open a ticket with
> > > Github; and in the meantime, we could set up a private repository in
> the
> > > Apache organization to hold the security issues (e.g.
> > cloudstack-security).
> > >
> > >
> > > Thanks Rohit.
> > >
> > >
> > >
> > > On Mon, Mar 19, 2018 at 7:58 AM, Rohit Yadav <
> rohit.ya...@shapeblue.com>
> > > wrote:
> > >
> > > > (I've cc-ed user ML to gather feedback from users for this email as
> > > well.)
> > > > All,
> > > > Thank you for your feedbacks, discussions, and suggestions. I have
> > tried
> > > > to take on board all the feedback from the discussion and I propose
> the
> > > > following:
> > > > # Problem
> > > > Let me summarize the problems we're facing and propose some solution
> > > > (which may require voting

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rohit Yadav]

Thanks all for your feedback. Since it's been positive so far, I'll start a 
vote on Monday to formalize this.

In the meanwhile, please keep sharing your feedback and opinion. Thanks (and 
happy weekends).


- Rohit

<https://cloudstack.apache.org>




From: Syed Ahmed <sah...@cloudops.com>
Sent: Thursday, March 22, 2018 12:51:01 AM
To: dev@cloudstack.apache.org
Cc: us...@cloudstack.apache.org
Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

+1 To Rohit’s suggestion
On Wed, Mar 21, 2018 at 11:35 AM Khosrow Moossavi <kmooss...@cloudops.com>
wrote:

> Thanks Rohit, that's a really great sum-up of proposition!
>
> According to the private issue topic, as far as I understand, we don't have
> any private issue per se, unless they are security, vulnerability
> or CVE related and the process of reporting them -being really private
> until they are fixed- are well-defined. So I would say the mentioned
> security@ ML and have an interim ticket in Jira or the ML itself works and
> when the fix is out, for sake of archive, the issue can be created
> in GH and set as closed right away.
>
>
>
> On Wed, Mar 21, 2018 at 6:38 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > I think that works as well. Let's see what others think about it.
> >
> > On Wed, Mar 21, 2018 at 4:15 AM, Rohit Yadav <rohit.ya...@shapeblue.com>
> > wrote:
> >
> > > Thanks Rafael for your inputs. You're right about access control
> > > limitation on Github.
> > >
> > >
> > > However, I think having another repository to track security stuff can
> > add
> > > overhead (and to manage its custom ACLs with INFRA, as all cloudstack*
> > > repos are allowed access to all PMC/committers now).
> > >
> > >
> > > Users are advised to report security issues on security@, so how about
> > we
> > > continue to use JIRA for security issues (logging, tracking, and
> > > discussions) and limit the proposed change to just moving to Github
> > issues
> > > as a first step?
> > >
> > >
> > > - Rohit
> > >
> > > <https://cloudstack.apache.org>
> > >
> > >
> > >
> > > 
> > > From: Rafael Weingärtner <rafaelweingart...@gmail.com>
> > > Sent: Tuesday, March 20, 2018 11:46:32 PM
> > > To: dev
> > > Cc: us...@cloudstack.apache.org
> > > Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
> > >
> > > It looks like you have done all of the homework here. If it comes to a
> > > vote, I am +1 on migrating issues to Github, and even the Wiki in the
> > > future.  The Github would be able to pretty much provide everything
> that
> > we
> > > have in both Wiki and Jira. Therefore, it feels better to work on a
> > single
> > > platform than to spread information across them. However, we still have
> > one
> > > problem. The security issues/tickets in Jira. How can we manage them in
> > > Github? As far as I know, there is no way to control the access to
> > certain
> > > issues/tickets in Github.
> > >
> > > To tackle that problem with security issues we could open a ticket with
> > > Github; and in the meantime, we could set up a private repository in
> the
> > > Apache organization to hold the security issues (e.g.
> > cloudstack-security).
> > >
> > >
> > > Thanks Rohit.
> > >
> > >
> > >
> > > On Mon, Mar 19, 2018 at 7:58 AM, Rohit Yadav <
> rohit.ya...@shapeblue.com>
> > > wrote:
> > >
> > > > (I've cc-ed user ML to gather feedback from users for this email as
> > > well.)
> > > > All,
> > > > Thank you for your feedbacks, discussions, and suggestions. I have
> > tried
> > > > to take on board all the feedback from the discussion and I propose
> the
> > > > following:
> > > > # Problem
> > > > Let me summarize the problems we're facing and propose some solution
> > > > (which may require voting) in the next section:
> > > > - Search:
> > > > The source of truth is in the git repository (Github or asf mirror),
> > > > however, our issue tracking and wiki systems are different. Therefore
> > any
> > > > task requires us to move back and forth between these various
> > > > portals/systems. As an example - a contributor trying to find whether
> > an
> > &

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Syed Ahmed]

+1 To Rohit’s suggestion
On Wed, Mar 21, 2018 at 11:35 AM Khosrow Moossavi <kmooss...@cloudops.com>
wrote:

> Thanks Rohit, that's a really great sum-up of proposition!
>
> According to the private issue topic, as far as I understand, we don't have
> any private issue per se, unless they are security, vulnerability
> or CVE related and the process of reporting them -being really private
> until they are fixed- are well-defined. So I would say the mentioned
> security@ ML and have an interim ticket in Jira or the ML itself works and
> when the fix is out, for sake of archive, the issue can be created
> in GH and set as closed right away.
>
>
>
> On Wed, Mar 21, 2018 at 6:38 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > I think that works as well. Let's see what others think about it.
> >
> > On Wed, Mar 21, 2018 at 4:15 AM, Rohit Yadav <rohit.ya...@shapeblue.com>
> > wrote:
> >
> > > Thanks Rafael for your inputs. You're right about access control
> > > limitation on Github.
> > >
> > >
> > > However, I think having another repository to track security stuff can
> > add
> > > overhead (and to manage its custom ACLs with INFRA, as all cloudstack*
> > > repos are allowed access to all PMC/committers now).
> > >
> > >
> > > Users are advised to report security issues on security@, so how about
> > we
> > > continue to use JIRA for security issues (logging, tracking, and
> > > discussions) and limit the proposed change to just moving to Github
> > issues
> > > as a first step?
> > >
> > >
> > > - Rohit
> > >
> > > <https://cloudstack.apache.org>
> > >
> > >
> > >
> > > 
> > > From: Rafael Weingärtner <rafaelweingart...@gmail.com>
> > > Sent: Tuesday, March 20, 2018 11:46:32 PM
> > > To: dev
> > > Cc: us...@cloudstack.apache.org
> > > Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
> > >
> > > It looks like you have done all of the homework here. If it comes to a
> > > vote, I am +1 on migrating issues to Github, and even the Wiki in the
> > > future.  The Github would be able to pretty much provide everything
> that
> > we
> > > have in both Wiki and Jira. Therefore, it feels better to work on a
> > single
> > > platform than to spread information across them. However, we still have
> > one
> > > problem. The security issues/tickets in Jira. How can we manage them in
> > > Github? As far as I know, there is no way to control the access to
> > certain
> > > issues/tickets in Github.
> > >
> > > To tackle that problem with security issues we could open a ticket with
> > > Github; and in the meantime, we could set up a private repository in
> the
> > > Apache organization to hold the security issues (e.g.
> > cloudstack-security).
> > >
> > >
> > > Thanks Rohit.
> > >
> > >
> > >
> > > On Mon, Mar 19, 2018 at 7:58 AM, Rohit Yadav <
> rohit.ya...@shapeblue.com>
> > > wrote:
> > >
> > > > (I've cc-ed user ML to gather feedback from users for this email as
> > > well.)
> > > > All,
> > > > Thank you for your feedbacks, discussions, and suggestions. I have
> > tried
> > > > to take on board all the feedback from the discussion and I propose
> the
> > > > following:
> > > > # Problem
> > > > Let me summarize the problems we're facing and propose some solution
> > > > (which may require voting) in the next section:
> > > > - Search:
> > > > The source of truth is in the git repository (Github or asf mirror),
> > > > however, our issue tracking and wiki systems are different. Therefore
> > any
> > > > task requires us to move back and forth between these various
> > > > portals/systems. As an example - a contributor trying to find whether
> > an
> > > > issue was fixed, requires them to search both JIRA, Github for pull
> > > > requests or commits (and sometimes the release notes and MLs).
> > > > - Audience/Platform:
> > > > From an audience's perspective, the user ML and JIRA issue are for
> > users
> > > > to be able to reach the community and seek help with a bug or
> request a
> > > new
> > > > feature.
> > > > The dev ML, and github PR are ways that developers u

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Khosrow Moossavi]

Thanks Rohit, that's a really great sum-up of proposition!

According to the private issue topic, as far as I understand, we don't have
any private issue per se, unless they are security, vulnerability
or CVE related and the process of reporting them -being really private
until they are fixed- are well-defined. So I would say the mentioned
security@ ML and have an interim ticket in Jira or the ML itself works and
when the fix is out, for sake of archive, the issue can be created
in GH and set as closed right away.



On Wed, Mar 21, 2018 at 6:38 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> I think that works as well. Let's see what others think about it.
>
> On Wed, Mar 21, 2018 at 4:15 AM, Rohit Yadav <rohit.ya...@shapeblue.com>
> wrote:
>
> > Thanks Rafael for your inputs. You're right about access control
> > limitation on Github.
> >
> >
> > However, I think having another repository to track security stuff can
> add
> > overhead (and to manage its custom ACLs with INFRA, as all cloudstack*
> > repos are allowed access to all PMC/committers now).
> >
> >
> > Users are advised to report security issues on security@, so how about
> we
> > continue to use JIRA for security issues (logging, tracking, and
> > discussions) and limit the proposed change to just moving to Github
> issues
> > as a first step?
> >
> >
> > - Rohit
> >
> > <https://cloudstack.apache.org>
> >
> >
> >
> > ________
> > From: Rafael Weingärtner <rafaelweingart...@gmail.com>
> > Sent: Tuesday, March 20, 2018 11:46:32 PM
> > To: dev
> > Cc: us...@cloudstack.apache.org
> > Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
> >
> > It looks like you have done all of the homework here. If it comes to a
> > vote, I am +1 on migrating issues to Github, and even the Wiki in the
> > future.  The Github would be able to pretty much provide everything that
> we
> > have in both Wiki and Jira. Therefore, it feels better to work on a
> single
> > platform than to spread information across them. However, we still have
> one
> > problem. The security issues/tickets in Jira. How can we manage them in
> > Github? As far as I know, there is no way to control the access to
> certain
> > issues/tickets in Github.
> >
> > To tackle that problem with security issues we could open a ticket with
> > Github; and in the meantime, we could set up a private repository in the
> > Apache organization to hold the security issues (e.g.
> cloudstack-security).
> >
> >
> > Thanks Rohit.
> >
> >
> >
> > On Mon, Mar 19, 2018 at 7:58 AM, Rohit Yadav <rohit.ya...@shapeblue.com>
> > wrote:
> >
> > > (I've cc-ed user ML to gather feedback from users for this email as
> > well.)
> > > All,
> > > Thank you for your feedbacks, discussions, and suggestions. I have
> tried
> > > to take on board all the feedback from the discussion and I propose the
> > > following:
> > > # Problem
> > > Let me summarize the problems we're facing and propose some solution
> > > (which may require voting) in the next section:
> > > - Search:
> > > The source of truth is in the git repository (Github or asf mirror),
> > > however, our issue tracking and wiki systems are different. Therefore
> any
> > > task requires us to move back and forth between these various
> > > portals/systems. As an example - a contributor trying to find whether
> an
> > > issue was fixed, requires them to search both JIRA, Github for pull
> > > requests or commits (and sometimes the release notes and MLs).
> > > - Audience/Platform:
> > > From an audience's perspective, the user ML and JIRA issue are for
> users
> > > to be able to reach the community and seek help with a bug or request a
> > new
> > > feature.
> > > The dev ML, and github PR are ways that developers usually use to
> > > fix/address an issue or develop a new feature, and get them accepted
> > > towards a release.
> > > CWiki is used by both to track articles, documentation and FSs, the
> docs
> > > website hosts docs for install/admin/release notes is user-facing. Both
> > > JIRA and Confluence are slow compared to Github. The docs website is a
> > > static website and is fast.
> > > - Relationship and discovery:
> > > Historically, the main reason for having a JIRA id with a PR/commit is
> to
> > > be able to track changes for an open bug and gathe

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rafael Weingärtner]

I think that works as well. Let's see what others think about it.

On Wed, Mar 21, 2018 at 4:15 AM, Rohit Yadav <rohit.ya...@shapeblue.com>
wrote:

> Thanks Rafael for your inputs. You're right about access control
> limitation on Github.
>
>
> However, I think having another repository to track security stuff can add
> overhead (and to manage its custom ACLs with INFRA, as all cloudstack*
> repos are allowed access to all PMC/committers now).
>
>
> Users are advised to report security issues on security@, so how about we
> continue to use JIRA for security issues (logging, tracking, and
> discussions) and limit the proposed change to just moving to Github issues
> as a first step?
>
>
> - Rohit
>
> <https://cloudstack.apache.org>
>
>
>
> 
> From: Rafael Weingärtner <rafaelweingart...@gmail.com>
> Sent: Tuesday, March 20, 2018 11:46:32 PM
> To: dev
> Cc: us...@cloudstack.apache.org
> Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
>
> It looks like you have done all of the homework here. If it comes to a
> vote, I am +1 on migrating issues to Github, and even the Wiki in the
> future.  The Github would be able to pretty much provide everything that we
> have in both Wiki and Jira. Therefore, it feels better to work on a single
> platform than to spread information across them. However, we still have one
> problem. The security issues/tickets in Jira. How can we manage them in
> Github? As far as I know, there is no way to control the access to certain
> issues/tickets in Github.
>
> To tackle that problem with security issues we could open a ticket with
> Github; and in the meantime, we could set up a private repository in the
> Apache organization to hold the security issues (e.g. cloudstack-security).
>
>
> Thanks Rohit.
>
>
>
> On Mon, Mar 19, 2018 at 7:58 AM, Rohit Yadav <rohit.ya...@shapeblue.com>
> wrote:
>
> > (I've cc-ed user ML to gather feedback from users for this email as
> well.)
> > All,
> > Thank you for your feedbacks, discussions, and suggestions. I have tried
> > to take on board all the feedback from the discussion and I propose the
> > following:
> > # Problem
> > Let me summarize the problems we're facing and propose some solution
> > (which may require voting) in the next section:
> > - Search:
> > The source of truth is in the git repository (Github or asf mirror),
> > however, our issue tracking and wiki systems are different. Therefore any
> > task requires us to move back and forth between these various
> > portals/systems. As an example - a contributor trying to find whether an
> > issue was fixed, requires them to search both JIRA, Github for pull
> > requests or commits (and sometimes the release notes and MLs).
> > - Audience/Platform:
> > From an audience's perspective, the user ML and JIRA issue are for users
> > to be able to reach the community and seek help with a bug or request a
> new
> > feature.
> > The dev ML, and github PR are ways that developers usually use to
> > fix/address an issue or develop a new feature, and get them accepted
> > towards a release.
> > CWiki is used by both to track articles, documentation and FSs, the docs
> > website hosts docs for install/admin/release notes is user-facing. Both
> > JIRA and Confluence are slow compared to Github. The docs website is a
> > static website and is fast.
> > - Relationship and discovery:
> > Historically, the main reason for having a JIRA id with a PR/commit is to
> > be able to track changes for an open bug and gather such a list in the
> > release notes. It also helps with cross-searching of a PR against a JIRA
> > ticket and searching a JIRA id for possible discussion from an accepted
> PR.
> > A git commit (for example on github) can also help by telling us which
> tags
> > or branches the commit was included in, so helps in knowing which version
> > of ACS will have that in.
> >  - Behaviours:
> > With the current strict requirement of JIRA ids for each PR, we see these
> > behaviours:
> > (a) many times the author may not engage after sending the PR and may not
> > add a JIRA id causing that PR to get blocked indefinitely,
> > (b) the author would create a JIRA id just for the sake of it with
> minimal
> > description and not filling all available fields such as affects and/or
> fix
> > version.
> > After a PR is accepted the JIRA ticket may not be properly
> closed/resolved
> > to leave us with several open tickets which are in fact close-able.
> > - Pollution:
> > Due to JIRA-caused behavi

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rohit Yadav]

Thanks Rafael for your inputs. You're right about access control limitation on 
Github.


However, I think having another repository to track security stuff can add 
overhead (and to manage its custom ACLs with INFRA, as all cloudstack* repos 
are allowed access to all PMC/committers now).


Users are advised to report security issues on security@, so how about we 
continue to use JIRA for security issues (logging, tracking, and discussions) 
and limit the proposed change to just moving to Github issues as a first step?


- Rohit

<https://cloudstack.apache.org>




From: Rafael Weingärtner <rafaelweingart...@gmail.com>
Sent: Tuesday, March 20, 2018 11:46:32 PM
To: dev
Cc: us...@cloudstack.apache.org
Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

It looks like you have done all of the homework here. If it comes to a
vote, I am +1 on migrating issues to Github, and even the Wiki in the
future.  The Github would be able to pretty much provide everything that we
have in both Wiki and Jira. Therefore, it feels better to work on a single
platform than to spread information across them. However, we still have one
problem. The security issues/tickets in Jira. How can we manage them in
Github? As far as I know, there is no way to control the access to certain
issues/tickets in Github.

To tackle that problem with security issues we could open a ticket with
Github; and in the meantime, we could set up a private repository in the
Apache organization to hold the security issues (e.g. cloudstack-security).


Thanks Rohit.



On Mon, Mar 19, 2018 at 7:58 AM, Rohit Yadav <rohit.ya...@shapeblue.com>
wrote:

> (I've cc-ed user ML to gather feedback from users for this email as well.)
> All,
> Thank you for your feedbacks, discussions, and suggestions. I have tried
> to take on board all the feedback from the discussion and I propose the
> following:
> # Problem
> Let me summarize the problems we're facing and propose some solution
> (which may require voting) in the next section:
> - Search:
> The source of truth is in the git repository (Github or asf mirror),
> however, our issue tracking and wiki systems are different. Therefore any
> task requires us to move back and forth between these various
> portals/systems. As an example - a contributor trying to find whether an
> issue was fixed, requires them to search both JIRA, Github for pull
> requests or commits (and sometimes the release notes and MLs).
> - Audience/Platform:
> From an audience's perspective, the user ML and JIRA issue are for users
> to be able to reach the community and seek help with a bug or request a new
> feature.
> The dev ML, and github PR are ways that developers usually use to
> fix/address an issue or develop a new feature, and get them accepted
> towards a release.
> CWiki is used by both to track articles, documentation and FSs, the docs
> website hosts docs for install/admin/release notes is user-facing. Both
> JIRA and Confluence are slow compared to Github. The docs website is a
> static website and is fast.
> - Relationship and discovery:
> Historically, the main reason for having a JIRA id with a PR/commit is to
> be able to track changes for an open bug and gather such a list in the
> release notes. It also helps with cross-searching of a PR against a JIRA
> ticket and searching a JIRA id for possible discussion from an accepted PR.
> A git commit (for example on github) can also help by telling us which tags
> or branches the commit was included in, so helps in knowing which version
> of ACS will have that in.
>  - Behaviours:
> With the current strict requirement of JIRA ids for each PR, we see these
> behaviours:
> (a) many times the author may not engage after sending the PR and may not
> add a JIRA id causing that PR to get blocked indefinitely,
> (b) the author would create a JIRA id just for the sake of it with minimal
> description and not filling all available fields such as affects and/or fix
> version.
> After a PR is accepted the JIRA ticket may not be properly closed/resolved
> to leave us with several open tickets which are in fact close-able.
> - Pollution:
> Due to JIRA-caused behaviours 'administrative' changes such as changing of
> versions, addition of upgrade paths after a version is cut, changes to
> update the iso url, dependency version in pom.xml etc end up creating '00s
> of new JIRA ticket. We're already in our 10k numbers. At this point in time
> it is not likely that all these tickets will be addressed, the workload
> involved would simply not make this feasible.
> # Let's discuss Solutions
> Let me acknowledge here that enforcing any process in the community is a
> challenge and to some extent not possible in a community of contributors
> doing work in their *free time

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rafael Weingärtner]

It looks like you have done all of the homework here. If it comes to a
vote, I am +1 on migrating issues to Github, and even the Wiki in the
future.  The Github would be able to pretty much provide everything that we
have in both Wiki and Jira. Therefore, it feels better to work on a single
platform than to spread information across them. However, we still have one
problem. The security issues/tickets in Jira. How can we manage them in
Github? As far as I know, there is no way to control the access to certain
issues/tickets in Github.

To tackle that problem with security issues we could open a ticket with
Github; and in the meantime, we could set up a private repository in the
Apache organization to hold the security issues (e.g. cloudstack-security).


Thanks Rohit.



On Mon, Mar 19, 2018 at 7:58 AM, Rohit Yadav 
wrote:

> (I've cc-ed user ML to gather feedback from users for this email as well.)
> All,
> Thank you for your feedbacks, discussions, and suggestions. I have tried
> to take on board all the feedback from the discussion and I propose the
> following:
> # Problem
> Let me summarize the problems we're facing and propose some solution
> (which may require voting) in the next section:
> - Search:
> The source of truth is in the git repository (Github or asf mirror),
> however, our issue tracking and wiki systems are different. Therefore any
> task requires us to move back and forth between these various
> portals/systems. As an example - a contributor trying to find whether an
> issue was fixed, requires them to search both JIRA, Github for pull
> requests or commits (and sometimes the release notes and MLs).
> - Audience/Platform:
> From an audience's perspective, the user ML and JIRA issue are for users
> to be able to reach the community and seek help with a bug or request a new
> feature.
> The dev ML, and github PR are ways that developers usually use to
> fix/address an issue or develop a new feature, and get them accepted
> towards a release.
> CWiki is used by both to track articles, documentation and FSs, the docs
> website hosts docs for install/admin/release notes is user-facing. Both
> JIRA and Confluence are slow compared to Github. The docs website is a
> static website and is fast.
> - Relationship and discovery:
> Historically, the main reason for having a JIRA id with a PR/commit is to
> be able to track changes for an open bug and gather such a list in the
> release notes. It also helps with cross-searching of a PR against a JIRA
> ticket and searching a JIRA id for possible discussion from an accepted PR.
> A git commit (for example on github) can also help by telling us which tags
> or branches the commit was included in, so helps in knowing which version
> of ACS will have that in.
>  - Behaviours:
> With the current strict requirement of JIRA ids for each PR, we see these
> behaviours:
> (a) many times the author may not engage after sending the PR and may not
> add a JIRA id causing that PR to get blocked indefinitely,
> (b) the author would create a JIRA id just for the sake of it with minimal
> description and not filling all available fields such as affects and/or fix
> version.
> After a PR is accepted the JIRA ticket may not be properly closed/resolved
> to leave us with several open tickets which are in fact close-able.
> - Pollution:
> Due to JIRA-caused behaviours 'administrative' changes such as changing of
> versions, addition of upgrade paths after a version is cut, changes to
> update the iso url, dependency version in pom.xml etc end up creating '00s
> of new JIRA ticket. We're already in our 10k numbers. At this point in time
> it is not likely that all these tickets will be addressed, the workload
> involved would simply not make this feasible.
> # Let's discuss Solutions
> Let me acknowledge here that enforcing any process in the community is a
> challenge and to some extent not possible in a community of contributors
> doing work in their *free time*. In an ideal world, I understand we would
> want all procedures to be followed (as some of mentioned in favour of that)
> but practically if there are other ways to fix our problems and reduce
> red-tape we should explore that. Let me propose a comprehensive solution
> and request your feedback and thoughts:
> - Search:
> We've all organically made great progress with higher cadence after
> switching to a Github based contribution workflow. I hope nobody disagrees
> how easy it is now to contribute and review, compared to what we did in
> past with "reviewboard". With the final/ultimate source of truth stored in
> the git repository, it only make sense to stick to one platform that is
> easier to use. Github, I think, is usually faster than both ASF jira and
> cwiki.
> - Audience/Platform:
> Based on a query with ASF INFRA, I was adivsed that a project can use all
> the features of Github (see https://issues.apache.org/
> jira/browse/INFRA-16186). I also checked and confirmed that 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rohit Yadav]

(I've cc-ed user ML to gather feedback from users for this email as well.)
All,
Thank you for your feedbacks, discussions, and suggestions. I have tried to 
take on board all the feedback from the discussion and I propose the following:
# Problem
Let me summarize the problems we're facing and propose some solution (which may 
require voting) in the next section:
- Search:
The source of truth is in the git repository (Github or asf mirror), however, 
our issue tracking and wiki systems are different. Therefore any task requires 
us to move back and forth between these various portals/systems. As an example 
- a contributor trying to find whether an issue was fixed, requires them to 
search both JIRA, Github for pull requests or commits (and sometimes the 
release notes and MLs).
- Audience/Platform:
From an audience's perspective, the user ML and JIRA issue are for users to be 
able to reach the community and seek help with a bug or request a new feature.
The dev ML, and github PR are ways that developers usually use to fix/address 
an issue or develop a new feature, and get them accepted towards a release.
CWiki is used by both to track articles, documentation and FSs, the docs 
website hosts docs for install/admin/release notes is user-facing. Both JIRA 
and Confluence are slow compared to Github. The docs website is a static 
website and is fast.
- Relationship and discovery:
Historically, the main reason for having a JIRA id with a PR/commit is to be 
able to track changes for an open bug and gather such a list in the release 
notes. It also helps with cross-searching of a PR against a JIRA ticket and 
searching a JIRA id for possible discussion from an accepted PR. A git commit 
(for example on github) can also help by telling us which tags or branches the 
commit was included in, so helps in knowing which version of ACS will have that 
in.
 - Behaviours:
With the current strict requirement of JIRA ids for each PR, we see these 
behaviours:
(a) many times the author may not engage after sending the PR and may not add a 
JIRA id causing that PR to get blocked indefinitely,
(b) the author would create a JIRA id just for the sake of it with minimal 
description and not filling all available fields such as affects and/or fix 
version.
After a PR is accepted the JIRA ticket may not be properly closed/resolved to 
leave us with several open tickets which are in fact close-able.
- Pollution:
Due to JIRA-caused behaviours 'administrative' changes such as changing of 
versions, addition of upgrade paths after a version is cut, changes to update 
the iso url, dependency version in pom.xml etc end up creating '00s of new JIRA 
ticket. We're already in our 10k numbers. At this point in time it is not 
likely that all these tickets will be addressed, the workload involved would 
simply not make this feasible.
# Let's discuss Solutions
Let me acknowledge here that enforcing any process in the community is a 
challenge and to some extent not possible in a community of contributors doing 
work in their *free time*. In an ideal world, I understand we would want all 
procedures to be followed (as some of mentioned in favour of that) but 
practically if there are other ways to fix our problems and reduce red-tape we 
should explore that. Let me propose a comprehensive solution and request your 
feedback and thoughts:
- Search:
We've all organically made great progress with higher cadence after switching 
to a Github based contribution workflow. I hope nobody disagrees how easy it is 
now to contribute and review, compared to what we did in past with 
"reviewboard". With the final/ultimate source of truth stored in the git 
repository, it only make sense to stick to one platform that is easier to use. 
Github, I think, is usually faster than both ASF jira and cwiki.
- Audience/Platform:
Based on a query with ASF INFRA, I was adivsed that a project can use all the 
features of Github (see https://issues.apache.org/jira/browse/INFRA-16186). I 
also checked and confirmed that any changes to Github repo goes to the commits 
ML.
I propose we stick with Github and for starters explore using the 'github 
issues' for issue tracking. We may explore wiki and projects in future (or on 
an experimental basis). Having both issues and pull requests/reviewing on the 
same platform will make it easier for both users and developers to use one 
platform for searching, logging, and use.
I propose to limit our scope of changes and start with Github issues first. A 
discussion of moving away from cwiki can be held in future.
Historical data in existing systems will be kept for reference, but may be 
deprecated in the future. The legacy systems can avoid taking new additions, 
and all users and developers encouraged to use the Github equivalents
- Discovery and relationships:
As experimented with 4.11.0.0, we can use Github milestone (that are basically 
CloudStack versions) to track PRs that should go towards a release. Github 
project 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Ron Wheeler]

I am not sure that it makes any difference about which tracking system 
is chosen.
Google will find the issues related to my problem (and a million that 
somehow have a vague connection to the words that I used).
Developers will be able to find the issue tracking system regardless of 
where it is hosted.
My IDE (Eclipse STS) automatically shows the issues for the issue repos 
that I configure.


I thought that the discussion was about approving PRs with no issues.

On 14/03/2018 10:42 AM, Will Stevens wrote:
Ron, for this I think we would be using Github Issues if we were not 
using Jira. Essentially all of the project information would be found 
in the same place rather than the user having to discover all the 
different systems that we use to track things and then try to make 
sense of it.


*Will Stevens*
Chief Technology Officer
c514.826.0190

<https://goo.gl/NYZ8KK>

On Wed, Mar 14, 2018 at 10:04 AM, Ron Wheeler 
<rwhee...@artifact-software.com 
<mailto:rwhee...@artifact-software.com>> wrote:


I am not a Cloudstack developer and generally have no interest in PRs.
If I have a problem, I want to search the Jira
 - What was the symptom  - is it related to the problem that I am
having - may not be exactly the same but might be related
 - How was it reproduced - is this related to what I am trying to
do - can I change my configuration decisions to avoid the issue
 - What remedies were considered - could any of these have side
effects that could account for my issue
 - Why was the specific fix chosen - is my problem an edge case
that was created or ignored by this decision
 - Is there any discussion that could help me decide if my problem
is related.
 - Is there any info in the discussion that educates me to a point
where I know what tests to run to refine my understanding my issue.
 - What are the side-effects of the fix.
 - Was it back ported
 - What issues were discovered during backporting

I am not sure that a PR will be much use to a sysadmin if the
issue is non-trivial.
If we ask people creating PRs to add all the things that a
sysadmin requires, PRs may get too difficult to make.

OTOH, I agree with Paul that PRs without Jira issues for doc
updates and corrections that do *not affect functionality* would
not make life too difficult and might encourage people to fix doc
problems, clean code and update libraries.

Ron


On 14/03/2018 7:25 AM, Paul Angus wrote:

Oh boy! Where to start

Ok, so wrt Rohit's original point, I'm a +1 for doc updates
and very trivial stuff a GOOD & COMPLETE title and summary in
a PR probably suffices.

Wrt Jira, for keeping track of *un*implemented changes and
*un*fixed bugs - I think that it (or something similar) is a
must.  Which shouldn't leave much to be honest.  As some point
a person has decided to make a code change or has found a bug,
right then the 'thing', by definition, falls into one of the
above categories.



Kind regards,

Paul Angus

paul.an...@shapeblue.com <mailto:paul.an...@shapeblue.com>
www.shapeblue.com <http://www.shapeblue.com>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue


-Original Message-
From: Daan Hoogland <daan.hoogl...@gmail.com
<mailto:daan.hoogl...@gmail.com>>
Sent: 14 March 2018 10:05
To: dev <dev@cloudstack.apache.org
<mailto:dev@cloudstack.apache.org>>
    Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

Let me add to the below that I do think a ticketing system is
a big help for keeping track of *un*implemented changes and
*un*fixed bugs.

On Wed, Mar 14, 2018 at 11:04 AM, Daan Hoogland
<daan.hoogl...@gmail.com <mailto:daan.hoogl...@gmail.com>>
wrote:

Boris, I hate to be strongly opinionated but I have to
violently
disagree with you on some things here;

On Wed, Mar 14, 2018 at 9:48 AM, Boris Stoyanov <
boris.stoya...@shapeblue.com
<mailto:boris.stoya...@shapeblue.com>> wrote:

Hi all,

I do understand your point as developers if you want
to fix something
just open the PR and not deal with any extra details
like JIRA
tickets and etc, but I must say that JIRA tickets are
quite often
looked up from users as they experience an issue.

​It is not more or less effort for users to look up github
PRs than
Jira tickets. They still need to be clever about search
terms and
still might miss out.
​

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Will Stevens]

Ron, for this I think we would be using Github Issues if we were not using
Jira.  Essentially all of the project information would be found in the
same place rather than the user having to discover all the different
systems that we use to track things and then try to make sense of it.

*Will Stevens*
Chief Technology Officer
c 514.826.0190

<https://goo.gl/NYZ8KK>

On Wed, Mar 14, 2018 at 10:04 AM, Ron Wheeler <
rwhee...@artifact-software.com> wrote:

> I am not a Cloudstack developer and generally have no interest in PRs.
> If I have a problem, I want to search the Jira
>  - What was the symptom  - is it related to the problem that I am having -
> may not be exactly the same but might be related
>  - How was it reproduced - is this related to what I am trying to do - can
> I change my configuration decisions to avoid the issue
>  - What remedies were considered - could any of these have side effects
> that could account for my issue
>  - Why was the specific fix chosen - is my problem an edge case that was
> created or ignored by this decision
>  - Is there any discussion that could help me decide if my problem is
> related.
>  - Is there any info in the discussion that educates me to a point where I
> know what tests to run to refine my understanding my issue.
>  - What are the side-effects of the fix.
>  - Was it back ported
>  - What issues were discovered during backporting
>
> I am not sure that a PR will be much use to a sysadmin if the issue is
> non-trivial.
> If we ask people creating PRs to add all the things that a sysadmin
> requires, PRs may get too difficult to make.
>
> OTOH, I agree with Paul that PRs without Jira issues for doc updates and
> corrections that do *not affect functionality* would not make life too
> difficult and might encourage people to fix doc problems, clean code and
> update libraries.
>
> Ron
>
>
> On 14/03/2018 7:25 AM, Paul Angus wrote:
>
>> Oh boy! Where to start
>>
>> Ok, so wrt Rohit's original point, I'm a +1 for doc updates and very
>> trivial stuff a GOOD & COMPLETE title and summary in a PR probably suffices.
>>
>> Wrt Jira, for keeping track of *un*implemented changes and *un*fixed bugs
>> - I think that it (or something similar) is a must.  Which shouldn't leave
>> much to be honest.  As some point a person has decided to make a code
>> change or has found a bug, right then the 'thing', by definition, falls
>> into one of the above categories.
>>
>>
>>
>> Kind regards,
>>
>> Paul Angus
>>
>> paul.an...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>> -Original Message-
>> From: Daan Hoogland <daan.hoogl...@gmail.com>
>> Sent: 14 March 2018 10:05
>> To: dev <dev@cloudstack.apache.org>
>> Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
>>
>> Let me add to the below that I do think a ticketing system is a big help
>> for keeping track of *un*implemented changes and *un*fixed bugs.
>>
>> On Wed, Mar 14, 2018 at 11:04 AM, Daan Hoogland <daan.hoogl...@gmail.com>
>> wrote:
>>
>> Boris, I hate to be strongly opinionated but I have to violently
>>> disagree with you on some things here;
>>>
>>> On Wed, Mar 14, 2018 at 9:48 AM, Boris Stoyanov <
>>> boris.stoya...@shapeblue.com> wrote:
>>>
>>> Hi all,
>>>>
>>>> I do understand your point as developers if you want to fix something
>>>> just open the PR and not deal with any extra details like JIRA
>>>> tickets and etc, but I must say that JIRA tickets are quite often
>>>> looked up from users as they experience an issue.
>>>>
>>> ​It is not more or less effort for users to look up github PRs than
>>> Jira tickets. They still need to be clever about search terms and
>>> still might miss out.
>>> ​
>>>
>>>
>>> Let’s say we’ve fixed an annoying UI bug in master and there’s no
>>>> ticket for it in JIRA. As a user, if you try to search for this
>>>> particular issue where would you go? In JIRA or GitHub? How would you
>>>> know which release to pickup if you’re just an infrastructure guy and
>>>> not following Github.
>>>>
>>>> ​What is following here and why not Github but Jira.​ ​
>>>
>>>
>>> Tracking every change with such tool is proven good practice in SDLC,
>>>>
>>> ​No it is not. Absolutely not. That is what we have revision control
>>> systems for. Your good pra

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Ron Wheeler]

I am not a Cloudstack developer and generally have no interest in PRs.
If I have a problem, I want to search the Jira
 - What was the symptom  - is it related to the problem that I am 
having - may not be exactly the same but might be related
 - How was it reproduced - is this related to what I am trying to do - 
can I change my configuration decisions to avoid the issue
 - What remedies were considered - could any of these have side effects 
that could account for my issue
 - Why was the specific fix chosen - is my problem an edge case that 
was created or ignored by this decision
 - Is there any discussion that could help me decide if my problem is 
related.
 - Is there any info in the discussion that educates me to a point 
where I know what tests to run to refine my understanding my issue.

 - What are the side-effects of the fix.
 - Was it back ported
 - What issues were discovered during backporting

I am not sure that a PR will be much use to a sysadmin if the issue is 
non-trivial.
If we ask people creating PRs to add all the things that a sysadmin 
requires, PRs may get too difficult to make.


OTOH, I agree with Paul that PRs without Jira issues for doc updates and 
corrections that do *not affect functionality* would not make life too 
difficult and might encourage people to fix doc problems, clean code and 
update libraries.


Ron

On 14/03/2018 7:25 AM, Paul Angus wrote:

Oh boy! Where to start

Ok, so wrt Rohit's original point, I'm a +1 for doc updates and very trivial stuff 
a GOOD & COMPLETE title and summary in a PR probably suffices.

Wrt Jira, for keeping track of *un*implemented changes and *un*fixed bugs - I 
think that it (or something similar) is a must.  Which shouldn't leave much to 
be honest.  As some point a person has decided to make a code change or has 
found a bug, right then the 'thing', by definition, falls into one of the above 
categories.



Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
   
  



-Original Message-
From: Daan Hoogland <daan.hoogl...@gmail.com>
Sent: 14 March 2018 10:05
To: dev <dev@cloudstack.apache.org>
Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

Let me add to the below that I do think a ticketing system is a big help for 
keeping track of *un*implemented changes and *un*fixed bugs.

On Wed, Mar 14, 2018 at 11:04 AM, Daan Hoogland <daan.hoogl...@gmail.com>
wrote:


Boris, I hate to be strongly opinionated but I have to violently
disagree with you on some things here;

On Wed, Mar 14, 2018 at 9:48 AM, Boris Stoyanov <
boris.stoya...@shapeblue.com> wrote:


Hi all,

I do understand your point as developers if you want to fix something
just open the PR and not deal with any extra details like JIRA
tickets and etc, but I must say that JIRA tickets are quite often
looked up from users as they experience an issue.

​It is not more or less effort for users to look up github PRs than
Jira tickets. They still need to be clever about search terms and
still might miss out.
​



Let’s say we’ve fixed an annoying UI bug in master and there’s no
ticket for it in JIRA. As a user, if you try to search for this
particular issue where would you go? In JIRA or GitHub? How would you
know which release to pickup if you’re just an infrastructure guy and not 
following Github.


​What is following here and why not Github but Jira.​ ​



Tracking every change with such tool is proven good practice in SDLC,

​No it is not. Absolutely not. That is what we have revision control
systems for. Your good practice is only true for enterprise controlled
projects. In cloudstack there are a lot of wild forks because this
enterprisy way of controlling change has pushed people away from
mainstream. This is a force to be reckoned with and we can not completely
ban it, but we have to minimise it if we want to survive as project.
​



it brings visibility and it’s a tool meant to be used not only from
developers, but from everyone involved in the project.


​How is this true for Jira anywhere near as much as it is true for github?​




I also got the feeling that lacking a JIRA ticket could become a common
practice in community submission and it’s yet another reason for me to be
-1 on this.

​Another reason to be very much +1 on it. That is a good thing. Think
about it. People submistting features and bugfixes instead of asking for
them in a ticket. That is great.
​



Also I don’t think it’s causing big overhead, since it’s being updated
mostly automatically.


​No it is not. What is done automatically? put in progress?? closing?
undertest status? Only noise is added to those tickets automatically.
​



Boris Stoyanov


boris.stoya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue




On 13 Mar 2018, at 17:01, Khosrow Moossavi <kmooss...@cloudops.com>

wrote:

I'm completely +1 on us

RE: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Paul Angus]

Oh boy! Where to start

Ok, so wrt Rohit's original point, I'm a +1 for doc updates and very trivial 
stuff a GOOD & COMPLETE title and summary in a PR probably suffices.

Wrt Jira, for keeping track of *un*implemented changes and *un*fixed bugs - I 
think that it (or something similar) is a must.  Which shouldn't leave much to 
be honest.  As some point a person has decided to make a code change or has 
found a bug, right then the 'thing', by definition, falls into one of the above 
categories.



Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Daan Hoogland <daan.hoogl...@gmail.com> 
Sent: 14 March 2018 10:05
To: dev <dev@cloudstack.apache.org>
Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

Let me add to the below that I do think a ticketing system is a big help for 
keeping track of *un*implemented changes and *un*fixed bugs.

On Wed, Mar 14, 2018 at 11:04 AM, Daan Hoogland <daan.hoogl...@gmail.com>
wrote:

> Boris, I hate to be strongly opinionated but I have to violently 
> disagree with you on some things here;
>
> On Wed, Mar 14, 2018 at 9:48 AM, Boris Stoyanov < 
> boris.stoya...@shapeblue.com> wrote:
>
>> Hi all,
>>
>> I do understand your point as developers if you want to fix something 
>> just open the PR and not deal with any extra details like JIRA 
>> tickets and etc, but I must say that JIRA tickets are quite often 
>> looked up from users as they experience an issue.
>
> ​It is not more or less effort for users to look up github PRs than 
> Jira tickets. They still need to be clever about search terms and 
> still might miss out.
> ​
>
>
>> Let’s say we’ve fixed an annoying UI bug in master and there’s no 
>> ticket for it in JIRA. As a user, if you try to search for this 
>> particular issue where would you go? In JIRA or GitHub? How would you 
>> know which release to pickup if you’re just an infrastructure guy and not 
>> following Github.
>>
> ​What is following here and why not Github but Jira.​ ​
>
>
>>
>> Tracking every change with such tool is proven good practice in SDLC,
>
> ​No it is not. Absolutely not. That is what we have revision control
> systems for. Your good practice is only true for enterprise controlled
> projects. In cloudstack there are a lot of wild forks because this
> enterprisy way of controlling change has pushed people away from
> mainstream. This is a force to be reckoned with and we can not completely
> ban it, but we have to minimise it if we want to survive as project.
> ​
>
>
>> it brings visibility and it’s a tool meant to be used not only from
>> developers, but from everyone involved in the project.
>>
> ​How is this true for Jira anywhere near as much as it is true for github?​
>
>
>
>>
>> I also got the feeling that lacking a JIRA ticket could become a common
>> practice in community submission and it’s yet another reason for me to be
>> -1 on this.
>
> ​Another reason to be very much +1 on it. That is a good thing. Think
> about it. People submistting features and bugfixes instead of asking for
> them in a ticket. That is great.
> ​
>
>
>> Also I don’t think it’s causing big overhead, since it’s being updated
>> mostly automatically.
>>
> ​No it is not. What is done automatically? put in progress?? closing?
> undertest status? Only noise is added to those tickets automatically.
> ​
>
>
>>
>> Boris Stoyanov
>>
>>
>> boris.stoya...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>>
>> > On 13 Mar 2018, at 17:01, Khosrow Moossavi <kmooss...@cloudops.com>
>> wrote:
>> >
>> > I'm completely +1 on using GH as source of truth, both PR and issue
>> wise,
>> > with Daan comment regarding Apache rules in mind.
>> > At least it doesn't need to have "yet another" integration to do
>> automated
>> > actions on an issue (such as auto close an issue by "Fixes NUMBER",
>> > "Closes NUMBER") directly from commit or PR body.
>> >
>> > Khosrow Moossavi
>> > CloudOps
>> >
>> > On Tue, Mar 13, 2018 at 10:11 AM, Syed Ahmed <sah...@cloudops.com>
>> wrote:
>> >
>> >> I agree with the relaxation as Rohit pointed out. At this point we
>> should
>> >> ask if Jira is really needed. Most people here I believe agree that it
>> is
>> >> not. The only reason we have Jira is to 

RE: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Giles Sirett]

Boris does have a valid point

We have to imagine a user - think of somebody installing cloudstack long  after 
a version release.

They hit  problem, they google that problem. If its already been seen, they 
will *usually* find a JIRA ticket which describes their problem and (depending 
on whether it has been fixed) describe the fix, version numbers,etc

Think of JIRA as a documentation platform

As a non-developer, trying to decipher a PR and its comments simply does not 
give me that same functionality. It may give people on this list what they 
want, but not necessarily users

Having said all of that, the discussion here has been about moving to Github 
issues. AKAIK, that would recreate the functionality that I describe above - so 
his may be a moot point






Kind regards
Giles

giles.sir...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Daan Hoogland <daan.hoogl...@gmail.com> 
Sent: 14 March 2018 10:05
To: dev <dev@cloudstack.apache.org>
Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

Let me add to the below that I do think a ticketing system is a big help for 
keeping track of *un*implemented changes and *un*fixed bugs.

On Wed, Mar 14, 2018 at 11:04 AM, Daan Hoogland <daan.hoogl...@gmail.com>
wrote:

> Boris, I hate to be strongly opinionated but I have to violently 
> disagree with you on some things here;
>
> On Wed, Mar 14, 2018 at 9:48 AM, Boris Stoyanov < 
> boris.stoya...@shapeblue.com> wrote:
>
>> Hi all,
>>
>> I do understand your point as developers if you want to fix something 
>> just open the PR and not deal with any extra details like JIRA 
>> tickets and etc, but I must say that JIRA tickets are quite often 
>> looked up from users as they experience an issue.
>
> ​It is not more or less effort for users to look up github PRs than 
> Jira tickets. They still need to be clever about search terms and 
> still might miss out.
> ​
>
>
>> Let’s say we’ve fixed an annoying UI bug in master and there’s no 
>> ticket for it in JIRA. As a user, if you try to search for this 
>> particular issue where would you go? In JIRA or GitHub? How would you 
>> know which release to pickup if you’re just an infrastructure guy and not 
>> following Github.
>>
> ​What is following here and why not Github but Jira.​ ​
>
>
>>
>> Tracking every change with such tool is proven good practice in SDLC,
>
> ​No it is not. Absolutely not. That is what we have revision control
> systems for. Your good practice is only true for enterprise controlled
> projects. In cloudstack there are a lot of wild forks because this
> enterprisy way of controlling change has pushed people away from
> mainstream. This is a force to be reckoned with and we can not completely
> ban it, but we have to minimise it if we want to survive as project.
> ​
>
>
>> it brings visibility and it’s a tool meant to be used not only from
>> developers, but from everyone involved in the project.
>>
> ​How is this true for Jira anywhere near as much as it is true for github?​
>
>
>
>>
>> I also got the feeling that lacking a JIRA ticket could become a common
>> practice in community submission and it’s yet another reason for me to be
>> -1 on this.
>
> ​Another reason to be very much +1 on it. That is a good thing. Think
> about it. People submistting features and bugfixes instead of asking for
> them in a ticket. That is great.
> ​
>
>
>> Also I don’t think it’s causing big overhead, since it’s being updated
>> mostly automatically.
>>
> ​No it is not. What is done automatically? put in progress?? closing?
> undertest status? Only noise is added to those tickets automatically.
> ​
>
>
>>
>> Boris Stoyanov
>>
>>
>> boris.stoya...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>>
>> > On 13 Mar 2018, at 17:01, Khosrow Moossavi <kmooss...@cloudops.com>
>> wrote:
>> >
>> > I'm completely +1 on using GH as source of truth, both PR and issue
>> wise,
>> > with Daan comment regarding Apache rules in mind.
>> > At least it doesn't need to have "yet another" integration to do
>> automated
>> > actions on an issue (such as auto close an issue by "Fixes NUMBER",
>> > "Closes NUMBER") directly from commit or PR body.
>> >
>> > Khosrow Moossavi
>> > CloudOps
>> >
>> > On Tue, Mar 13, 2018 at 10:11 AM, Syed Ahmed <sah...@cloudops.com>
>> wrote:
>> >
>> &

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Nicolas Vazquez]

I think we should first define and document what we are considering a minor or 
trivial change, I am +1 on relaxing the requirement of a Jira ticket for those


From: Daan Hoogland <daan.hoogl...@gmail.com>
Sent: Wednesday, March 14, 2018 7:05:04 AM
To: dev
Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

Let me add to the below that I do think a ticketing system is a big help
for keeping track of *un*implemented changes and *un*fixed bugs.

On Wed, Mar 14, 2018 at 11:04 AM, Daan Hoogland <daan.hoogl...@gmail.com>
wrote:

> Boris, I hate to be strongly opinionated but I have to violently disagree
> with you on some things here;
>
> On Wed, Mar 14, 2018 at 9:48 AM, Boris Stoyanov <
> boris.stoya...@shapeblue.com> wrote:
>
>> Hi all,
>>
>> I do understand your point as developers if you want to fix something
>> just open the PR and not deal with any extra details like JIRA tickets and
>> etc, but I must say that JIRA tickets are quite often looked up from users
>> as they experience an issue.
>
> ​It is not more or less effort for users to look up github PRs than Jira
> tickets. They still need to be clever about search terms and still might
> miss out.
> ​
>
>
>> Let’s say we’ve fixed an annoying UI bug in master and there’s no ticket
>> for it in JIRA. As a user, if you try to search for this particular issue
>> where would you go? In JIRA or GitHub? How would you know which release to
>> pickup if you’re just an infrastructure guy and not following Github.
>>
> ​What is following here and why not Github but Jira.​
> ​
>
>
>>
>> Tracking every change with such tool is proven good practice in SDLC,
>
> ​No it is not. Absolutely not. That is what we have revision control
> systems for. Your good practice is only true for enterprise controlled
> projects. In cloudstack there are a lot of wild forks because this
> enterprisy way of controlling change has pushed people away from
> mainstream. This is a force to be reckoned with and we can not completely
> ban it, but we have to minimise it if we want to survive as project.
> ​
>
>
>> it brings visibility and it’s a tool meant to be used not only from
>> developers, but from everyone involved in the project.
>>
> ​How is this true for Jira anywhere near as much as it is true for github?​
>
>
>
>>
>> I also got the feeling that lacking a JIRA ticket could become a common
>> practice in community submission and it’s yet another reason for me to be
>> -1 on this.
>
> ​Another reason to be very much +1 on it. That is a good thing. Think
> about it. People submistting features and bugfixes instead of asking for
> them in a ticket. That is great.
> ​
>
>
>> Also I don’t think it’s causing big overhead, since it’s being updated
>> mostly automatically.
>>
> ​No it is not. What is done automatically? put in progress?? closing?
> undertest status? Only noise is added to those tickets automatically.
> ​
>
>
>>
>> Boris Stoyanov
>>
>>
>> boris.stoya...@shapeblue.com
>> www.shapeblue.com<http://www.shapeblue.com>
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>>
>> > On 13 Mar 2018, at 17:01, Khosrow Moossavi <kmooss...@cloudops.com>
>> wrote:
>> >
>> > I'm completely +1 on using GH as source of truth, both PR and issue
>> wise,
>> > with Daan comment regarding Apache rules in mind.
>> > At least it doesn't need to have "yet another" integration to do
>> automated
>> > actions on an issue (such as auto close an issue by "Fixes NUMBER",
>> > "Closes NUMBER") directly from commit or PR body.
>> >
>> > Khosrow Moossavi
>> > CloudOps
>> >
>> > On Tue, Mar 13, 2018 at 10:11 AM, Syed Ahmed <sah...@cloudops.com>
>> wrote:
>> >
>> >> I agree with the relaxation as Rohit pointed out. At this point we
>> should
>> >> ask if Jira is really needed. Most people here I believe agree that it
>> is
>> >> not. The only reason we have Jira is to track releases. This could
>> easily
>> >> be replicated in GitHub as I see that GitHub is the place where we all
>> >> collaborate. I would be completely in if we use GitHub issues and like
>> it
>> >> with Jira as we do with our PRs.
>> >>
>> >>
>> >> On Tue, Mar 13, 2018 at 10:03 AM Rafael Weingärtner <
>> >> rafaelweingart...@gmail.com> wrote:
>> >>
>> >>> I was

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Daan Hoogland]

Let me add to the below that I do think a ticketing system is a big help
for keeping track of *un*implemented changes and *un*fixed bugs.

On Wed, Mar 14, 2018 at 11:04 AM, Daan Hoogland 
wrote:

> Boris, I hate to be strongly opinionated but I have to violently disagree
> with you on some things here;
>
> On Wed, Mar 14, 2018 at 9:48 AM, Boris Stoyanov <
> boris.stoya...@shapeblue.com> wrote:
>
>> Hi all,
>>
>> I do understand your point as developers if you want to fix something
>> just open the PR and not deal with any extra details like JIRA tickets and
>> etc, but I must say that JIRA tickets are quite often looked up from users
>> as they experience an issue.
>
> ​It is not more or less effort for users to look up github PRs than Jira
> tickets. They still need to be clever about search terms and still might
> miss out.
> ​
>
>
>> Let’s say we’ve fixed an annoying UI bug in master and there’s no ticket
>> for it in JIRA. As a user, if you try to search for this particular issue
>> where would you go? In JIRA or GitHub? How would you know which release to
>> pickup if you’re just an infrastructure guy and not following Github.
>>
> ​What is following here and why not Github but Jira.​
> ​
>
>
>>
>> Tracking every change with such tool is proven good practice in SDLC,
>
> ​No it is not. Absolutely not. That is what we have revision control
> systems for. Your good practice is only true for enterprise controlled
> projects. In cloudstack there are a lot of wild forks because this
> enterprisy way of controlling change has pushed people away from
> mainstream. This is a force to be reckoned with and we can not completely
> ban it, but we have to minimise it if we want to survive as project.
> ​
>
>
>> it brings visibility and it’s a tool meant to be used not only from
>> developers, but from everyone involved in the project.
>>
> ​How is this true for Jira anywhere near as much as it is true for github?​
>
>
>
>>
>> I also got the feeling that lacking a JIRA ticket could become a common
>> practice in community submission and it’s yet another reason for me to be
>> -1 on this.
>
> ​Another reason to be very much +1 on it. That is a good thing. Think
> about it. People submistting features and bugfixes instead of asking for
> them in a ticket. That is great.
> ​
>
>
>> Also I don’t think it’s causing big overhead, since it’s being updated
>> mostly automatically.
>>
> ​No it is not. What is done automatically? put in progress?? closing?
> undertest status? Only noise is added to those tickets automatically.
> ​
>
>
>>
>> Boris Stoyanov
>>
>>
>> boris.stoya...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>>
>> > On 13 Mar 2018, at 17:01, Khosrow Moossavi 
>> wrote:
>> >
>> > I'm completely +1 on using GH as source of truth, both PR and issue
>> wise,
>> > with Daan comment regarding Apache rules in mind.
>> > At least it doesn't need to have "yet another" integration to do
>> automated
>> > actions on an issue (such as auto close an issue by "Fixes NUMBER",
>> > "Closes NUMBER") directly from commit or PR body.
>> >
>> > Khosrow Moossavi
>> > CloudOps
>> >
>> > On Tue, Mar 13, 2018 at 10:11 AM, Syed Ahmed 
>> wrote:
>> >
>> >> I agree with the relaxation as Rohit pointed out. At this point we
>> should
>> >> ask if Jira is really needed. Most people here I believe agree that it
>> is
>> >> not. The only reason we have Jira is to track releases. This could
>> easily
>> >> be replicated in GitHub as I see that GitHub is the place where we all
>> >> collaborate. I would be completely in if we use GitHub issues and like
>> it
>> >> with Jira as we do with our PRs.
>> >>
>> >>
>> >> On Tue, Mar 13, 2018 at 10:03 AM Rafael Weingärtner <
>> >> rafaelweingart...@gmail.com> wrote:
>> >>
>> >>> I was checking and for some reason ACS does not have an issue tab (
>> >>> https://github.com/apache/cloudstack/issues). It might be some
>> >>> configuration in the repository.
>> >>>
>> >>> On Tue, Mar 13, 2018 at 10:54 AM, Rafael Weingärtner <
>> >>> rafaelweingart...@gmail.com> wrote:
>> >>>
>>  What do you mean by issue? PR or issue (Github issue)?
>> 
>>  On Tue, Mar 13, 2018 at 10:53 AM, Daan Hoogland <
>> >> daan.hoogl...@gmail.com
>> 
>>  wrote:
>> 
>> > right, also when an issue is created?
>> >
>> >
>> > On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
>> > rafaelweingart...@gmail.com> wrote:
>> >
>> >> We already have. All messages on ACS' GH go to commits@c.a.o
>> >>
>> >> On Tue, Mar 13, 2018 at 10:49 AM, Daan Hoogland <
>> > daan.hoogl...@gmail.com>
>> >> wrote:
>> >>
>> >>> Ok, one issue there is Apache foundation rules. If we copy every
>> >>> thing
>> >> into
>> >>> jira or the mail list we are fine, where ever we have our
>> >>> discussions.
>> >> The
>> >>> only thing is that 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Daan Hoogland]

Boris, I hate to be strongly opinionated but I have to violently disagree
with you on some things here;

On Wed, Mar 14, 2018 at 9:48 AM, Boris Stoyanov <
boris.stoya...@shapeblue.com> wrote:

> Hi all,
>
> I do understand your point as developers if you want to fix something just
> open the PR and not deal with any extra details like JIRA tickets and etc,
> but I must say that JIRA tickets are quite often looked up from users as
> they experience an issue.

​It is not more or less effort for users to look up github PRs than Jira
tickets. They still need to be clever about search terms and still might
miss out.
​


> Let’s say we’ve fixed an annoying UI bug in master and there’s no ticket
> for it in JIRA. As a user, if you try to search for this particular issue
> where would you go? In JIRA or GitHub? How would you know which release to
> pickup if you’re just an infrastructure guy and not following Github.
>
​What is following here and why not Github but Jira.​
​


>
> Tracking every change with such tool is proven good practice in SDLC,

​No it is not. Absolutely not. That is what we have revision control
systems for. Your good practice is only true for enterprise controlled
projects. In cloudstack there are a lot of wild forks because this
enterprisy way of controlling change has pushed people away from
mainstream. This is a force to be reckoned with and we can not completely
ban it, but we have to minimise it if we want to survive as project.
​


> it brings visibility and it’s a tool meant to be used not only from
> developers, but from everyone involved in the project.
>
​How is this true for Jira anywhere near as much as it is true for github?​



>
> I also got the feeling that lacking a JIRA ticket could become a common
> practice in community submission and it’s yet another reason for me to be
> -1 on this.

​Another reason to be very much +1 on it. That is a good thing. Think about
it. People submistting features and bugfixes instead of asking for them in
a ticket. That is great.
​


> Also I don’t think it’s causing big overhead, since it’s being updated
> mostly automatically.
>
​No it is not. What is done automatically? put in progress?? closing?
undertest status? Only noise is added to those tickets automatically.
​


>
> Boris Stoyanov
>
>
> boris.stoya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
> > On 13 Mar 2018, at 17:01, Khosrow Moossavi 
> wrote:
> >
> > I'm completely +1 on using GH as source of truth, both PR and issue wise,
> > with Daan comment regarding Apache rules in mind.
> > At least it doesn't need to have "yet another" integration to do
> automated
> > actions on an issue (such as auto close an issue by "Fixes NUMBER",
> > "Closes NUMBER") directly from commit or PR body.
> >
> > Khosrow Moossavi
> > CloudOps
> >
> > On Tue, Mar 13, 2018 at 10:11 AM, Syed Ahmed 
> wrote:
> >
> >> I agree with the relaxation as Rohit pointed out. At this point we
> should
> >> ask if Jira is really needed. Most people here I believe agree that it
> is
> >> not. The only reason we have Jira is to track releases. This could
> easily
> >> be replicated in GitHub as I see that GitHub is the place where we all
> >> collaborate. I would be completely in if we use GitHub issues and like
> it
> >> with Jira as we do with our PRs.
> >>
> >>
> >> On Tue, Mar 13, 2018 at 10:03 AM Rafael Weingärtner <
> >> rafaelweingart...@gmail.com> wrote:
> >>
> >>> I was checking and for some reason ACS does not have an issue tab (
> >>> https://github.com/apache/cloudstack/issues). It might be some
> >>> configuration in the repository.
> >>>
> >>> On Tue, Mar 13, 2018 at 10:54 AM, Rafael Weingärtner <
> >>> rafaelweingart...@gmail.com> wrote:
> >>>
>  What do you mean by issue? PR or issue (Github issue)?
> 
>  On Tue, Mar 13, 2018 at 10:53 AM, Daan Hoogland <
> >> daan.hoogl...@gmail.com
> 
>  wrote:
> 
> > right, also when an issue is created?
> >
> >
> > On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> >> We already have. All messages on ACS' GH go to commits@c.a.o
> >>
> >> On Tue, Mar 13, 2018 at 10:49 AM, Daan Hoogland <
> > daan.hoogl...@gmail.com>
> >> wrote:
> >>
> >>> Ok, one issue there is Apache foundation rules. If we copy every
> >>> thing
> >> into
> >>> jira or the mail list we are fine, where ever we have our
> >>> discussions.
> >> The
> >>> only thing is that we need a Apache hosted record. (as in not
> >>> github)
> >>>
> >>> On Tue, Mar 13, 2018 at 2:09 PM, Rafael Weingärtner <
> >>> rafaelweingart...@gmail.com> wrote:
> >>>
>  I prefer the workflow in Github as you guy, but to be fair with
> >>> Jira
> >>> ticket
>  system I mentioned it.
> 
>  @Marc, yes Jira can facilitate a lot the 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Boris Stoyanov]

Hi all, 

I do understand your point as developers if you want to fix something just open 
the PR and not deal with any extra details like JIRA tickets and etc, but I 
must say that JIRA tickets are quite often looked up from users as they 
experience an issue. Let’s say we’ve fixed an annoying UI bug in master and 
there’s no ticket for it in JIRA. As a user, if you try to search for this 
particular issue where would you go? In JIRA or GitHub? How would you know 
which release to pickup if you’re just an infrastructure guy and not following 
Github.

Tracking every change with such tool is proven good practice in SDLC, it brings 
visibility and it’s a tool meant to be used not only from developers, but from 
everyone involved in the project.

I also got the feeling that lacking a JIRA ticket could become a common 
practice in community submission and it’s yet another reason for me to be -1 on 
this. Also I don’t think it’s causing big overhead, since it’s being updated 
mostly automatically. 

Boris Stoyanov 


boris.stoya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

> On 13 Mar 2018, at 17:01, Khosrow Moossavi  wrote:
> 
> I'm completely +1 on using GH as source of truth, both PR and issue wise,
> with Daan comment regarding Apache rules in mind.
> At least it doesn't need to have "yet another" integration to do automated
> actions on an issue (such as auto close an issue by "Fixes NUMBER",
> "Closes NUMBER") directly from commit or PR body.
> 
> Khosrow Moossavi
> CloudOps
> 
> On Tue, Mar 13, 2018 at 10:11 AM, Syed Ahmed  wrote:
> 
>> I agree with the relaxation as Rohit pointed out. At this point we should
>> ask if Jira is really needed. Most people here I believe agree that it is
>> not. The only reason we have Jira is to track releases. This could easily
>> be replicated in GitHub as I see that GitHub is the place where we all
>> collaborate. I would be completely in if we use GitHub issues and like it
>> with Jira as we do with our PRs.
>> 
>> 
>> On Tue, Mar 13, 2018 at 10:03 AM Rafael Weingärtner <
>> rafaelweingart...@gmail.com> wrote:
>> 
>>> I was checking and for some reason ACS does not have an issue tab (
>>> https://github.com/apache/cloudstack/issues). It might be some
>>> configuration in the repository.
>>> 
>>> On Tue, Mar 13, 2018 at 10:54 AM, Rafael Weingärtner <
>>> rafaelweingart...@gmail.com> wrote:
>>> 
 What do you mean by issue? PR or issue (Github issue)?
 
 On Tue, Mar 13, 2018 at 10:53 AM, Daan Hoogland <
>> daan.hoogl...@gmail.com
 
 wrote:
 
> right, also when an issue is created?
> 
> 
> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
> 
>> We already have. All messages on ACS' GH go to commits@c.a.o
>> 
>> On Tue, Mar 13, 2018 at 10:49 AM, Daan Hoogland <
> daan.hoogl...@gmail.com>
>> wrote:
>> 
>>> Ok, one issue there is Apache foundation rules. If we copy every
>>> thing
>> into
>>> jira or the mail list we are fine, where ever we have our
>>> discussions.
>> The
>>> only thing is that we need a Apache hosted record. (as in not
>>> github)
>>> 
>>> On Tue, Mar 13, 2018 at 2:09 PM, Rafael Weingärtner <
>>> rafaelweingart...@gmail.com> wrote:
>>> 
 I prefer the workflow in Github as you guy, but to be fair with
>>> Jira
>>> ticket
 system I mentioned it.
 
 @Marc, yes Jira can facilitate a lot the management. However, we
>>> do
> not
>>> use
 it fully. In our workflow, there is no planning/roadmap for the
>>> next
 release per se. Things seem to work in an ad-hoc fashion. On the
> other
 hand, when you need to break down milestones into
> issues/tickets/tasks
>>> and
 then divide them into sprints, and manage a team of developers,
>>> the
 oversight provided by Jira system is very good; specially, when
> issues
 start to take more than a single sprint to finish.
 
 On Tue, Mar 13, 2018 at 9:44 AM, Marc-Aurèle Brothier <
>> ma...@exoscale.ch
 
 wrote:
 
> @rafael, you said: they all required Jira tickets to track the
>>> discussion
> and facilitate the management
> 
> I can see the discussion happening in the PR on github, but
>> the
> Jira
 ticket
> by itself doesn't do much, except copy/pasting the github
> discussion.
 Then
> it's down to "facilitate the management", which I only see as
> listing
>>> the
> changes for a release as far as I know. But this can be
>> achieved
> on
 github
> too.
> 
> As Daan mentioned, there are those things that are not code
> related
>>> which
> should have a way of tracking. But what's the 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Khosrow Moossavi]

I'm completely +1 on using GH as source of truth, both PR and issue wise,
with Daan comment regarding Apache rules in mind.
At least it doesn't need to have "yet another" integration to do automated
actions on an issue (such as auto close an issue by "Fixes NUMBER",
"Closes NUMBER") directly from commit or PR body.

Khosrow Moossavi
CloudOps

On Tue, Mar 13, 2018 at 10:11 AM, Syed Ahmed  wrote:

> I agree with the relaxation as Rohit pointed out. At this point we should
> ask if Jira is really needed. Most people here I believe agree that it is
> not. The only reason we have Jira is to track releases. This could easily
> be replicated in GitHub as I see that GitHub is the place where we all
> collaborate. I would be completely in if we use GitHub issues and like it
> with Jira as we do with our PRs.
>
>
> On Tue, Mar 13, 2018 at 10:03 AM Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > I was checking and for some reason ACS does not have an issue tab (
> > https://github.com/apache/cloudstack/issues). It might be some
> > configuration in the repository.
> >
> > On Tue, Mar 13, 2018 at 10:54 AM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> > > What do you mean by issue? PR or issue (Github issue)?
> > >
> > > On Tue, Mar 13, 2018 at 10:53 AM, Daan Hoogland <
> daan.hoogl...@gmail.com
> > >
> > > wrote:
> > >
> > >> right, also when an issue is created?
> > >>
> > >>
> > >> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
> > >> rafaelweingart...@gmail.com> wrote:
> > >>
> > >> > We already have. All messages on ACS' GH go to commits@c.a.o
> > >> >
> > >> > On Tue, Mar 13, 2018 at 10:49 AM, Daan Hoogland <
> > >> daan.hoogl...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Ok, one issue there is Apache foundation rules. If we copy every
> > thing
> > >> > into
> > >> > > jira or the mail list we are fine, where ever we have our
> > discussions.
> > >> > The
> > >> > > only thing is that we need a Apache hosted record. (as in not
> > github)
> > >> > >
> > >> > > On Tue, Mar 13, 2018 at 2:09 PM, Rafael Weingärtner <
> > >> > > rafaelweingart...@gmail.com> wrote:
> > >> > >
> > >> > > > I prefer the workflow in Github as you guy, but to be fair with
> > Jira
> > >> > > ticket
> > >> > > > system I mentioned it.
> > >> > > >
> > >> > > > @Marc, yes Jira can facilitate a lot the management. However, we
> > do
> > >> not
> > >> > > use
> > >> > > > it fully. In our workflow, there is no planning/roadmap for the
> > next
> > >> > > > release per se. Things seem to work in an ad-hoc fashion. On the
> > >> other
> > >> > > > hand, when you need to break down milestones into
> > >> issues/tickets/tasks
> > >> > > and
> > >> > > > then divide them into sprints, and manage a team of developers,
> > the
> > >> > > > oversight provided by Jira system is very good; specially, when
> > >> issues
> > >> > > > start to take more than a single sprint to finish.
> > >> > > >
> > >> > > > On Tue, Mar 13, 2018 at 9:44 AM, Marc-Aurèle Brothier <
> > >> > ma...@exoscale.ch
> > >> > > >
> > >> > > > wrote:
> > >> > > >
> > >> > > > > @rafael, you said: they all required Jira tickets to track the
> > >> > > discussion
> > >> > > > > and facilitate the management
> > >> > > > >
> > >> > > > > I can see the discussion happening in the PR on github, but
> the
> > >> Jira
> > >> > > > ticket
> > >> > > > > by itself doesn't do much, except copy/pasting the github
> > >> discussion.
> > >> > > > Then
> > >> > > > > it's down to "facilitate the management", which I only see as
> > >> listing
> > >> > > the
> > >> > > > > changes for a release as far as I know. But this can be
> achieved
> > >> on
> > >> > > > github
> > >> > > > > too.
> > >> > > > >
> > >> > > > > As Daan mentioned, there are those things that are not code
> > >> related
> > >> > > which
> > >> > > > > should have a way of tracking. But what's the difference in
> > >> tracking
> > >> > > them
> > >> > > > > as a Jira issue vs a Github issue (they can't be a PR)? Those
> > are
> > >> > point
> > >> > > > of
> > >> > > > > view exchanges with messages & links, with a final status,
> most
> > of
> > >> > the
> > >> > > > time
> > >> > > > > without a strong link to a release number. If they do, they
> can
> > be
> > >> > > added
> > >> > > > to
> > >> > > > > a milestone.
> > >> > > > >
> > >> > > > > So far I don't see how things done with Jira cannot be
> achieved
> > on
> > >> > > > Github.
> > >> > > > > It's just a matter of changing habits to simplify the workflow
> > for
> > >> > new
> > >> > > > > comers (and old joiners too ;-) ).
> > >> > > > >
> > >> > > > > On Tue, Mar 13, 2018 at 1:02 PM, Daan Hoogland <
> > >> > > daan.hoogl...@gmail.com>
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > > > Will, you are speaking my mind; any external registration
> tool
> > >> > should
> > >> > > > be
> > >> > > > > > based on the source. The only reason for having an external
> > tool
> > >> > > > without
> > 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Will Stevens]

To add another $0.02 to this conversation, beyond what I posted above.

Ideally, in my humble opinion, we would use Github Issues for issues that
do not currently have code associated with it.  Jira is currently being
used for this and it is useful for users to be able to flag bugs without
knowing how to solve them.  I believe this would require that issues be
turn on for the repo and the details of the issue be pushed to one of our
apache mailing lists.

One of the reasons why Jira has remained in play and we have not gone with
Github Issues in the past was due to security related issues.  I don't
believe we have the ability in Github to have private issues, which I
believe use use in Jira to handle security/CVE related issues.  This is
something we may have to solve for if we do leverage Github Issues, but I
will lets someone closer to how that all goes down comment and confirm or
deny this.

If we could use Github Issues and Github PRs as the only location for
issues and development, I think that would make contribution more
approachable and easier to convey to users.

Those are my additional thoughts...

*Will Stevens*
Chief Technology Officer
c 514.826.0190



On Tue, Mar 13, 2018 at 10:11 AM, Syed Ahmed  wrote:

> I agree with the relaxation as Rohit pointed out. At this point we should
> ask if Jira is really needed. Most people here I believe agree that it is
> not. The only reason we have Jira is to track releases. This could easily
> be replicated in GitHub as I see that GitHub is the place where we all
> collaborate. I would be completely in if we use GitHub issues and like it
> with Jira as we do with our PRs.
>
>
> On Tue, Mar 13, 2018 at 10:03 AM Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > I was checking and for some reason ACS does not have an issue tab (
> > https://github.com/apache/cloudstack/issues). It might be some
> > configuration in the repository.
> >
> > On Tue, Mar 13, 2018 at 10:54 AM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> > > What do you mean by issue? PR or issue (Github issue)?
> > >
> > > On Tue, Mar 13, 2018 at 10:53 AM, Daan Hoogland <
> daan.hoogl...@gmail.com
> > >
> > > wrote:
> > >
> > >> right, also when an issue is created?
> > >>
> > >>
> > >> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
> > >> rafaelweingart...@gmail.com> wrote:
> > >>
> > >> > We already have. All messages on ACS' GH go to commits@c.a.o
> > >> >
> > >> > On Tue, Mar 13, 2018 at 10:49 AM, Daan Hoogland <
> > >> daan.hoogl...@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Ok, one issue there is Apache foundation rules. If we copy every
> > thing
> > >> > into
> > >> > > jira or the mail list we are fine, where ever we have our
> > discussions.
> > >> > The
> > >> > > only thing is that we need a Apache hosted record. (as in not
> > github)
> > >> > >
> > >> > > On Tue, Mar 13, 2018 at 2:09 PM, Rafael Weingärtner <
> > >> > > rafaelweingart...@gmail.com> wrote:
> > >> > >
> > >> > > > I prefer the workflow in Github as you guy, but to be fair with
> > Jira
> > >> > > ticket
> > >> > > > system I mentioned it.
> > >> > > >
> > >> > > > @Marc, yes Jira can facilitate a lot the management. However, we
> > do
> > >> not
> > >> > > use
> > >> > > > it fully. In our workflow, there is no planning/roadmap for the
> > next
> > >> > > > release per se. Things seem to work in an ad-hoc fashion. On the
> > >> other
> > >> > > > hand, when you need to break down milestones into
> > >> issues/tickets/tasks
> > >> > > and
> > >> > > > then divide them into sprints, and manage a team of developers,
> > the
> > >> > > > oversight provided by Jira system is very good; specially, when
> > >> issues
> > >> > > > start to take more than a single sprint to finish.
> > >> > > >
> > >> > > > On Tue, Mar 13, 2018 at 9:44 AM, Marc-Aurèle Brothier <
> > >> > ma...@exoscale.ch
> > >> > > >
> > >> > > > wrote:
> > >> > > >
> > >> > > > > @rafael, you said: they all required Jira tickets to track the
> > >> > > discussion
> > >> > > > > and facilitate the management
> > >> > > > >
> > >> > > > > I can see the discussion happening in the PR on github, but
> the
> > >> Jira
> > >> > > > ticket
> > >> > > > > by itself doesn't do much, except copy/pasting the github
> > >> discussion.
> > >> > > > Then
> > >> > > > > it's down to "facilitate the management", which I only see as
> > >> listing
> > >> > > the
> > >> > > > > changes for a release as far as I know. But this can be
> achieved
> > >> on
> > >> > > > github
> > >> > > > > too.
> > >> > > > >
> > >> > > > > As Daan mentioned, there are those things that are not code
> > >> related
> > >> > > which
> > >> > > > > should have a way of tracking. But what's the difference in
> > >> tracking
> > >> > > them
> > >> > > > > as a Jira issue vs a Github issue (they can't be a PR)? Those
> > are
> > >> > point
> > >> > > > of
> > >> > > > > view exchanges with messages & links, 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Syed Ahmed]

I agree with the relaxation as Rohit pointed out. At this point we should
ask if Jira is really needed. Most people here I believe agree that it is
not. The only reason we have Jira is to track releases. This could easily
be replicated in GitHub as I see that GitHub is the place where we all
collaborate. I would be completely in if we use GitHub issues and like it
with Jira as we do with our PRs.


On Tue, Mar 13, 2018 at 10:03 AM Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> I was checking and for some reason ACS does not have an issue tab (
> https://github.com/apache/cloudstack/issues). It might be some
> configuration in the repository.
>
> On Tue, Mar 13, 2018 at 10:54 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > What do you mean by issue? PR or issue (Github issue)?
> >
> > On Tue, Mar 13, 2018 at 10:53 AM, Daan Hoogland  >
> > wrote:
> >
> >> right, also when an issue is created?
> >>
> >>
> >> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
> >> rafaelweingart...@gmail.com> wrote:
> >>
> >> > We already have. All messages on ACS' GH go to commits@c.a.o
> >> >
> >> > On Tue, Mar 13, 2018 at 10:49 AM, Daan Hoogland <
> >> daan.hoogl...@gmail.com>
> >> > wrote:
> >> >
> >> > > Ok, one issue there is Apache foundation rules. If we copy every
> thing
> >> > into
> >> > > jira or the mail list we are fine, where ever we have our
> discussions.
> >> > The
> >> > > only thing is that we need a Apache hosted record. (as in not
> github)
> >> > >
> >> > > On Tue, Mar 13, 2018 at 2:09 PM, Rafael Weingärtner <
> >> > > rafaelweingart...@gmail.com> wrote:
> >> > >
> >> > > > I prefer the workflow in Github as you guy, but to be fair with
> Jira
> >> > > ticket
> >> > > > system I mentioned it.
> >> > > >
> >> > > > @Marc, yes Jira can facilitate a lot the management. However, we
> do
> >> not
> >> > > use
> >> > > > it fully. In our workflow, there is no planning/roadmap for the
> next
> >> > > > release per se. Things seem to work in an ad-hoc fashion. On the
> >> other
> >> > > > hand, when you need to break down milestones into
> >> issues/tickets/tasks
> >> > > and
> >> > > > then divide them into sprints, and manage a team of developers,
> the
> >> > > > oversight provided by Jira system is very good; specially, when
> >> issues
> >> > > > start to take more than a single sprint to finish.
> >> > > >
> >> > > > On Tue, Mar 13, 2018 at 9:44 AM, Marc-Aurèle Brothier <
> >> > ma...@exoscale.ch
> >> > > >
> >> > > > wrote:
> >> > > >
> >> > > > > @rafael, you said: they all required Jira tickets to track the
> >> > > discussion
> >> > > > > and facilitate the management
> >> > > > >
> >> > > > > I can see the discussion happening in the PR on github, but the
> >> Jira
> >> > > > ticket
> >> > > > > by itself doesn't do much, except copy/pasting the github
> >> discussion.
> >> > > > Then
> >> > > > > it's down to "facilitate the management", which I only see as
> >> listing
> >> > > the
> >> > > > > changes for a release as far as I know. But this can be achieved
> >> on
> >> > > > github
> >> > > > > too.
> >> > > > >
> >> > > > > As Daan mentioned, there are those things that are not code
> >> related
> >> > > which
> >> > > > > should have a way of tracking. But what's the difference in
> >> tracking
> >> > > them
> >> > > > > as a Jira issue vs a Github issue (they can't be a PR)? Those
> are
> >> > point
> >> > > > of
> >> > > > > view exchanges with messages & links, with a final status, most
> of
> >> > the
> >> > > > time
> >> > > > > without a strong link to a release number. If they do, they can
> be
> >> > > added
> >> > > > to
> >> > > > > a milestone.
> >> > > > >
> >> > > > > So far I don't see how things done with Jira cannot be achieved
> on
> >> > > > Github.
> >> > > > > It's just a matter of changing habits to simplify the workflow
> for
> >> > new
> >> > > > > comers (and old joiners too ;-) ).
> >> > > > >
> >> > > > > On Tue, Mar 13, 2018 at 1:02 PM, Daan Hoogland <
> >> > > daan.hoogl...@gmail.com>
> >> > > > > wrote:
> >> > > > >
> >> > > > > > Will, you are speaking my mind; any external registration tool
> >> > should
> >> > > > be
> >> > > > > > based on the source. The only reason for having an external
> tool
> >> > > > without
> >> > > > > > relation to the code is to keep track of what is *not* (or not
> >> > fully)
> >> > > > > > implemented.
> >> > > > > >
> >> > > > > > On Tue, Mar 13, 2018 at 12:58 PM, Rafael Weingärtner <
> >> > > > > > rafaelweingart...@gmail.com> wrote:
> >> > > > > >
> >> > > > > > > I meant a way of describing them (changes/proposals)
> further.
> >> > > > Sometimes
> >> > > > > > we
> >> > > > > > > have commits only with title, and then the Jira ticket would
> >> be a
> >> > > way
> >> > > > > of
> >> > > > > > > documenting that commit. I do prefer the idea of inserting
> the
> >> > > whole
> >> > > > > > > description in the commit body though. [for me] it looks
> >> easier
> >> > 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rafael Weingärtner]

I was checking and for some reason ACS does not have an issue tab (
https://github.com/apache/cloudstack/issues). It might be some
configuration in the repository.

On Tue, Mar 13, 2018 at 10:54 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> What do you mean by issue? PR or issue (Github issue)?
>
> On Tue, Mar 13, 2018 at 10:53 AM, Daan Hoogland 
> wrote:
>
>> right, also when an issue is created?
>>
>>
>> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
>> rafaelweingart...@gmail.com> wrote:
>>
>> > We already have. All messages on ACS' GH go to commits@c.a.o
>> >
>> > On Tue, Mar 13, 2018 at 10:49 AM, Daan Hoogland <
>> daan.hoogl...@gmail.com>
>> > wrote:
>> >
>> > > Ok, one issue there is Apache foundation rules. If we copy every thing
>> > into
>> > > jira or the mail list we are fine, where ever we have our discussions.
>> > The
>> > > only thing is that we need a Apache hosted record. (as in not github)
>> > >
>> > > On Tue, Mar 13, 2018 at 2:09 PM, Rafael Weingärtner <
>> > > rafaelweingart...@gmail.com> wrote:
>> > >
>> > > > I prefer the workflow in Github as you guy, but to be fair with Jira
>> > > ticket
>> > > > system I mentioned it.
>> > > >
>> > > > @Marc, yes Jira can facilitate a lot the management. However, we do
>> not
>> > > use
>> > > > it fully. In our workflow, there is no planning/roadmap for the next
>> > > > release per se. Things seem to work in an ad-hoc fashion. On the
>> other
>> > > > hand, when you need to break down milestones into
>> issues/tickets/tasks
>> > > and
>> > > > then divide them into sprints, and manage a team of developers, the
>> > > > oversight provided by Jira system is very good; specially, when
>> issues
>> > > > start to take more than a single sprint to finish.
>> > > >
>> > > > On Tue, Mar 13, 2018 at 9:44 AM, Marc-Aurèle Brothier <
>> > ma...@exoscale.ch
>> > > >
>> > > > wrote:
>> > > >
>> > > > > @rafael, you said: they all required Jira tickets to track the
>> > > discussion
>> > > > > and facilitate the management
>> > > > >
>> > > > > I can see the discussion happening in the PR on github, but the
>> Jira
>> > > > ticket
>> > > > > by itself doesn't do much, except copy/pasting the github
>> discussion.
>> > > > Then
>> > > > > it's down to "facilitate the management", which I only see as
>> listing
>> > > the
>> > > > > changes for a release as far as I know. But this can be achieved
>> on
>> > > > github
>> > > > > too.
>> > > > >
>> > > > > As Daan mentioned, there are those things that are not code
>> related
>> > > which
>> > > > > should have a way of tracking. But what's the difference in
>> tracking
>> > > them
>> > > > > as a Jira issue vs a Github issue (they can't be a PR)? Those are
>> > point
>> > > > of
>> > > > > view exchanges with messages & links, with a final status, most of
>> > the
>> > > > time
>> > > > > without a strong link to a release number. If they do, they can be
>> > > added
>> > > > to
>> > > > > a milestone.
>> > > > >
>> > > > > So far I don't see how things done with Jira cannot be achieved on
>> > > > Github.
>> > > > > It's just a matter of changing habits to simplify the workflow for
>> > new
>> > > > > comers (and old joiners too ;-) ).
>> > > > >
>> > > > > On Tue, Mar 13, 2018 at 1:02 PM, Daan Hoogland <
>> > > daan.hoogl...@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > Will, you are speaking my mind; any external registration tool
>> > should
>> > > > be
>> > > > > > based on the source. The only reason for having an external tool
>> > > > without
>> > > > > > relation to the code is to keep track of what is *not* (or not
>> > fully)
>> > > > > > implemented.
>> > > > > >
>> > > > > > On Tue, Mar 13, 2018 at 12:58 PM, Rafael Weingärtner <
>> > > > > > rafaelweingart...@gmail.com> wrote:
>> > > > > >
>> > > > > > > I meant a way of describing them (changes/proposals) further.
>> > > > Sometimes
>> > > > > > we
>> > > > > > > have commits only with title, and then the Jira ticket would
>> be a
>> > > way
>> > > > > of
>> > > > > > > documenting that commit. I do prefer the idea of inserting the
>> > > whole
>> > > > > > > description in the commit body though. [for me] it looks
>> easier
>> > to
>> > > > work
>> > > > > > > directly with commits and PRs; as you said, we can generate
>> > release
>> > > > > notes
>> > > > > > > based on commits directly [and issues on GH]. However, for
>> that,
>> > we
>> > > > > need
>> > > > > > to
>> > > > > > > fine-tune our workflow.
>> > > > > > >
>> > > > > > >
>> > > > > > > On Tue, Mar 13, 2018 at 8:40 AM, Will Stevens <
>> > > wstev...@cloudops.com
>> > > > >
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > I am +1 to relaxing the requirement of Jira ticket.
>> > > > > > > >
>> > > > > > > > Rafael, what do you mean when you say "Jira tickets are
>> used to
>> > > > > > register
>> > > > > > > > changes"?
>> > > > > > > >
>> > > > > > > > I think ever since 4.9 the actual PRs included in the code
>> are

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rafael Weingärtner]

What do you mean by issue? PR or issue (Github issue)?

On Tue, Mar 13, 2018 at 10:53 AM, Daan Hoogland 
wrote:

> right, also when an issue is created?
>
>
> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > We already have. All messages on ACS' GH go to commits@c.a.o
> >
> > On Tue, Mar 13, 2018 at 10:49 AM, Daan Hoogland  >
> > wrote:
> >
> > > Ok, one issue there is Apache foundation rules. If we copy every thing
> > into
> > > jira or the mail list we are fine, where ever we have our discussions.
> > The
> > > only thing is that we need a Apache hosted record. (as in not github)
> > >
> > > On Tue, Mar 13, 2018 at 2:09 PM, Rafael Weingärtner <
> > > rafaelweingart...@gmail.com> wrote:
> > >
> > > > I prefer the workflow in Github as you guy, but to be fair with Jira
> > > ticket
> > > > system I mentioned it.
> > > >
> > > > @Marc, yes Jira can facilitate a lot the management. However, we do
> not
> > > use
> > > > it fully. In our workflow, there is no planning/roadmap for the next
> > > > release per se. Things seem to work in an ad-hoc fashion. On the
> other
> > > > hand, when you need to break down milestones into
> issues/tickets/tasks
> > > and
> > > > then divide them into sprints, and manage a team of developers, the
> > > > oversight provided by Jira system is very good; specially, when
> issues
> > > > start to take more than a single sprint to finish.
> > > >
> > > > On Tue, Mar 13, 2018 at 9:44 AM, Marc-Aurèle Brothier <
> > ma...@exoscale.ch
> > > >
> > > > wrote:
> > > >
> > > > > @rafael, you said: they all required Jira tickets to track the
> > > discussion
> > > > > and facilitate the management
> > > > >
> > > > > I can see the discussion happening in the PR on github, but the
> Jira
> > > > ticket
> > > > > by itself doesn't do much, except copy/pasting the github
> discussion.
> > > > Then
> > > > > it's down to "facilitate the management", which I only see as
> listing
> > > the
> > > > > changes for a release as far as I know. But this can be achieved on
> > > > github
> > > > > too.
> > > > >
> > > > > As Daan mentioned, there are those things that are not code related
> > > which
> > > > > should have a way of tracking. But what's the difference in
> tracking
> > > them
> > > > > as a Jira issue vs a Github issue (they can't be a PR)? Those are
> > point
> > > > of
> > > > > view exchanges with messages & links, with a final status, most of
> > the
> > > > time
> > > > > without a strong link to a release number. If they do, they can be
> > > added
> > > > to
> > > > > a milestone.
> > > > >
> > > > > So far I don't see how things done with Jira cannot be achieved on
> > > > Github.
> > > > > It's just a matter of changing habits to simplify the workflow for
> > new
> > > > > comers (and old joiners too ;-) ).
> > > > >
> > > > > On Tue, Mar 13, 2018 at 1:02 PM, Daan Hoogland <
> > > daan.hoogl...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Will, you are speaking my mind; any external registration tool
> > should
> > > > be
> > > > > > based on the source. The only reason for having an external tool
> > > > without
> > > > > > relation to the code is to keep track of what is *not* (or not
> > fully)
> > > > > > implemented.
> > > > > >
> > > > > > On Tue, Mar 13, 2018 at 12:58 PM, Rafael Weingärtner <
> > > > > > rafaelweingart...@gmail.com> wrote:
> > > > > >
> > > > > > > I meant a way of describing them (changes/proposals) further.
> > > > Sometimes
> > > > > > we
> > > > > > > have commits only with title, and then the Jira ticket would
> be a
> > > way
> > > > > of
> > > > > > > documenting that commit. I do prefer the idea of inserting the
> > > whole
> > > > > > > description in the commit body though. [for me] it looks easier
> > to
> > > > work
> > > > > > > directly with commits and PRs; as you said, we can generate
> > release
> > > > > notes
> > > > > > > based on commits directly [and issues on GH]. However, for
> that,
> > we
> > > > > need
> > > > > > to
> > > > > > > fine-tune our workflow.
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Mar 13, 2018 at 8:40 AM, Will Stevens <
> > > wstev...@cloudops.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I am +1 to relaxing the requirement of Jira ticket.
> > > > > > > >
> > > > > > > > Rafael, what do you mean when you say "Jira tickets are used
> to
> > > > > > register
> > > > > > > > changes"?
> > > > > > > >
> > > > > > > > I think ever since 4.9 the actual PRs included in the code
> are
> > > the
> > > > > > source
> > > > > > > > of truth for the changes in the actual code (at least from a
> > > > release
> > > > > > > notes
> > > > > > > > perspective).  This is why the release notes can show changes
> > > that
> > > > > only
> > > > > > > > have PRs and no Jira ticket.  At least my release notes
> > generator
> > > > is
> > > > > > > built
> > > > > > > > that way.  I think Rohit has 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Daan Hoogland]

right, also when an issue is created?


On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> We already have. All messages on ACS' GH go to commits@c.a.o
>
> On Tue, Mar 13, 2018 at 10:49 AM, Daan Hoogland 
> wrote:
>
> > Ok, one issue there is Apache foundation rules. If we copy every thing
> into
> > jira or the mail list we are fine, where ever we have our discussions.
> The
> > only thing is that we need a Apache hosted record. (as in not github)
> >
> > On Tue, Mar 13, 2018 at 2:09 PM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> > > I prefer the workflow in Github as you guy, but to be fair with Jira
> > ticket
> > > system I mentioned it.
> > >
> > > @Marc, yes Jira can facilitate a lot the management. However, we do not
> > use
> > > it fully. In our workflow, there is no planning/roadmap for the next
> > > release per se. Things seem to work in an ad-hoc fashion. On the other
> > > hand, when you need to break down milestones into issues/tickets/tasks
> > and
> > > then divide them into sprints, and manage a team of developers, the
> > > oversight provided by Jira system is very good; specially, when issues
> > > start to take more than a single sprint to finish.
> > >
> > > On Tue, Mar 13, 2018 at 9:44 AM, Marc-Aurèle Brothier <
> ma...@exoscale.ch
> > >
> > > wrote:
> > >
> > > > @rafael, you said: they all required Jira tickets to track the
> > discussion
> > > > and facilitate the management
> > > >
> > > > I can see the discussion happening in the PR on github, but the Jira
> > > ticket
> > > > by itself doesn't do much, except copy/pasting the github discussion.
> > > Then
> > > > it's down to "facilitate the management", which I only see as listing
> > the
> > > > changes for a release as far as I know. But this can be achieved on
> > > github
> > > > too.
> > > >
> > > > As Daan mentioned, there are those things that are not code related
> > which
> > > > should have a way of tracking. But what's the difference in tracking
> > them
> > > > as a Jira issue vs a Github issue (they can't be a PR)? Those are
> point
> > > of
> > > > view exchanges with messages & links, with a final status, most of
> the
> > > time
> > > > without a strong link to a release number. If they do, they can be
> > added
> > > to
> > > > a milestone.
> > > >
> > > > So far I don't see how things done with Jira cannot be achieved on
> > > Github.
> > > > It's just a matter of changing habits to simplify the workflow for
> new
> > > > comers (and old joiners too ;-) ).
> > > >
> > > > On Tue, Mar 13, 2018 at 1:02 PM, Daan Hoogland <
> > daan.hoogl...@gmail.com>
> > > > wrote:
> > > >
> > > > > Will, you are speaking my mind; any external registration tool
> should
> > > be
> > > > > based on the source. The only reason for having an external tool
> > > without
> > > > > relation to the code is to keep track of what is *not* (or not
> fully)
> > > > > implemented.
> > > > >
> > > > > On Tue, Mar 13, 2018 at 12:58 PM, Rafael Weingärtner <
> > > > > rafaelweingart...@gmail.com> wrote:
> > > > >
> > > > > > I meant a way of describing them (changes/proposals) further.
> > > Sometimes
> > > > > we
> > > > > > have commits only with title, and then the Jira ticket would be a
> > way
> > > > of
> > > > > > documenting that commit. I do prefer the idea of inserting the
> > whole
> > > > > > description in the commit body though. [for me] it looks easier
> to
> > > work
> > > > > > directly with commits and PRs; as you said, we can generate
> release
> > > > notes
> > > > > > based on commits directly [and issues on GH]. However, for that,
> we
> > > > need
> > > > > to
> > > > > > fine-tune our workflow.
> > > > > >
> > > > > >
> > > > > > On Tue, Mar 13, 2018 at 8:40 AM, Will Stevens <
> > wstev...@cloudops.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I am +1 to relaxing the requirement of Jira ticket.
> > > > > > >
> > > > > > > Rafael, what do you mean when you say "Jira tickets are used to
> > > > > register
> > > > > > > changes"?
> > > > > > >
> > > > > > > I think ever since 4.9 the actual PRs included in the code are
> > the
> > > > > source
> > > > > > > of truth for the changes in the actual code (at least from a
> > > release
> > > > > > notes
> > > > > > > perspective).  This is why the release notes can show changes
> > that
> > > > only
> > > > > > > have PRs and no Jira ticket.  At least my release notes
> generator
> > > is
> > > > > > built
> > > > > > > that way.  I think Rohit has built a similar release notes
> > > generator,
> > > > > so
> > > > > > I
> > > > > > > can't speak to his version...
> > > > > > >
> > > > > > > *Will Stevens*
> > > > > > > Chief Technology Officer
> > > > > > > c 514.826.0190
> > > > > > >
> > > > > > > 
> > > > > > >
> > > > > > > On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
> > > > > > > rafaelweingart...@gmail.com> wrote:
> > > > > > >
> > > > > 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rafael Weingärtner]

We already have. All messages on ACS' GH go to commits@c.a.o

On Tue, Mar 13, 2018 at 10:49 AM, Daan Hoogland 
wrote:

> Ok, one issue there is Apache foundation rules. If we copy every thing into
> jira or the mail list we are fine, where ever we have our discussions. The
> only thing is that we need a Apache hosted record. (as in not github)
>
> On Tue, Mar 13, 2018 at 2:09 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > I prefer the workflow in Github as you guy, but to be fair with Jira
> ticket
> > system I mentioned it.
> >
> > @Marc, yes Jira can facilitate a lot the management. However, we do not
> use
> > it fully. In our workflow, there is no planning/roadmap for the next
> > release per se. Things seem to work in an ad-hoc fashion. On the other
> > hand, when you need to break down milestones into issues/tickets/tasks
> and
> > then divide them into sprints, and manage a team of developers, the
> > oversight provided by Jira system is very good; specially, when issues
> > start to take more than a single sprint to finish.
> >
> > On Tue, Mar 13, 2018 at 9:44 AM, Marc-Aurèle Brothier  >
> > wrote:
> >
> > > @rafael, you said: they all required Jira tickets to track the
> discussion
> > > and facilitate the management
> > >
> > > I can see the discussion happening in the PR on github, but the Jira
> > ticket
> > > by itself doesn't do much, except copy/pasting the github discussion.
> > Then
> > > it's down to "facilitate the management", which I only see as listing
> the
> > > changes for a release as far as I know. But this can be achieved on
> > github
> > > too.
> > >
> > > As Daan mentioned, there are those things that are not code related
> which
> > > should have a way of tracking. But what's the difference in tracking
> them
> > > as a Jira issue vs a Github issue (they can't be a PR)? Those are point
> > of
> > > view exchanges with messages & links, with a final status, most of the
> > time
> > > without a strong link to a release number. If they do, they can be
> added
> > to
> > > a milestone.
> > >
> > > So far I don't see how things done with Jira cannot be achieved on
> > Github.
> > > It's just a matter of changing habits to simplify the workflow for new
> > > comers (and old joiners too ;-) ).
> > >
> > > On Tue, Mar 13, 2018 at 1:02 PM, Daan Hoogland <
> daan.hoogl...@gmail.com>
> > > wrote:
> > >
> > > > Will, you are speaking my mind; any external registration tool should
> > be
> > > > based on the source. The only reason for having an external tool
> > without
> > > > relation to the code is to keep track of what is *not* (or not fully)
> > > > implemented.
> > > >
> > > > On Tue, Mar 13, 2018 at 12:58 PM, Rafael Weingärtner <
> > > > rafaelweingart...@gmail.com> wrote:
> > > >
> > > > > I meant a way of describing them (changes/proposals) further.
> > Sometimes
> > > > we
> > > > > have commits only with title, and then the Jira ticket would be a
> way
> > > of
> > > > > documenting that commit. I do prefer the idea of inserting the
> whole
> > > > > description in the commit body though. [for me] it looks easier to
> > work
> > > > > directly with commits and PRs; as you said, we can generate release
> > > notes
> > > > > based on commits directly [and issues on GH]. However, for that, we
> > > need
> > > > to
> > > > > fine-tune our workflow.
> > > > >
> > > > >
> > > > > On Tue, Mar 13, 2018 at 8:40 AM, Will Stevens <
> wstev...@cloudops.com
> > >
> > > > > wrote:
> > > > >
> > > > > > I am +1 to relaxing the requirement of Jira ticket.
> > > > > >
> > > > > > Rafael, what do you mean when you say "Jira tickets are used to
> > > > register
> > > > > > changes"?
> > > > > >
> > > > > > I think ever since 4.9 the actual PRs included in the code are
> the
> > > > source
> > > > > > of truth for the changes in the actual code (at least from a
> > release
> > > > > notes
> > > > > > perspective).  This is why the release notes can show changes
> that
> > > only
> > > > > > have PRs and no Jira ticket.  At least my release notes generator
> > is
> > > > > built
> > > > > > that way.  I think Rohit has built a similar release notes
> > generator,
> > > > so
> > > > > I
> > > > > > can't speak to his version...
> > > > > >
> > > > > > *Will Stevens*
> > > > > > Chief Technology Officer
> > > > > > c 514.826.0190
> > > > > >
> > > > > > 
> > > > > >
> > > > > > On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
> > > > > > rafaelweingart...@gmail.com> wrote:
> > > > > >
> > > > > > > Marc, yes Jira tickets are used to register changes. However,
> > what
> > > > > Rohit
> > > > > > > and others (including me) are noticing is that there are
> certain
> > > > types
> > > > > of
> > > > > > > changes (minor/bureaucracy) that do not require Jira tickets.
> The
> > > > issue
> > > > > > is
> > > > > > > the wording “change”. What consist of a change that is worth
> > > > mentioning
> > > > > > 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Daan Hoogland]

Ok, one issue there is Apache foundation rules. If we copy every thing into
jira or the mail list we are fine, where ever we have our discussions. The
only thing is that we need a Apache hosted record. (as in not github)

On Tue, Mar 13, 2018 at 2:09 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> I prefer the workflow in Github as you guy, but to be fair with Jira ticket
> system I mentioned it.
>
> @Marc, yes Jira can facilitate a lot the management. However, we do not use
> it fully. In our workflow, there is no planning/roadmap for the next
> release per se. Things seem to work in an ad-hoc fashion. On the other
> hand, when you need to break down milestones into issues/tickets/tasks and
> then divide them into sprints, and manage a team of developers, the
> oversight provided by Jira system is very good; specially, when issues
> start to take more than a single sprint to finish.
>
> On Tue, Mar 13, 2018 at 9:44 AM, Marc-Aurèle Brothier 
> wrote:
>
> > @rafael, you said: they all required Jira tickets to track the discussion
> > and facilitate the management
> >
> > I can see the discussion happening in the PR on github, but the Jira
> ticket
> > by itself doesn't do much, except copy/pasting the github discussion.
> Then
> > it's down to "facilitate the management", which I only see as listing the
> > changes for a release as far as I know. But this can be achieved on
> github
> > too.
> >
> > As Daan mentioned, there are those things that are not code related which
> > should have a way of tracking. But what's the difference in tracking them
> > as a Jira issue vs a Github issue (they can't be a PR)? Those are point
> of
> > view exchanges with messages & links, with a final status, most of the
> time
> > without a strong link to a release number. If they do, they can be added
> to
> > a milestone.
> >
> > So far I don't see how things done with Jira cannot be achieved on
> Github.
> > It's just a matter of changing habits to simplify the workflow for new
> > comers (and old joiners too ;-) ).
> >
> > On Tue, Mar 13, 2018 at 1:02 PM, Daan Hoogland 
> > wrote:
> >
> > > Will, you are speaking my mind; any external registration tool should
> be
> > > based on the source. The only reason for having an external tool
> without
> > > relation to the code is to keep track of what is *not* (or not fully)
> > > implemented.
> > >
> > > On Tue, Mar 13, 2018 at 12:58 PM, Rafael Weingärtner <
> > > rafaelweingart...@gmail.com> wrote:
> > >
> > > > I meant a way of describing them (changes/proposals) further.
> Sometimes
> > > we
> > > > have commits only with title, and then the Jira ticket would be a way
> > of
> > > > documenting that commit. I do prefer the idea of inserting the whole
> > > > description in the commit body though. [for me] it looks easier to
> work
> > > > directly with commits and PRs; as you said, we can generate release
> > notes
> > > > based on commits directly [and issues on GH]. However, for that, we
> > need
> > > to
> > > > fine-tune our workflow.
> > > >
> > > >
> > > > On Tue, Mar 13, 2018 at 8:40 AM, Will Stevens  >
> > > > wrote:
> > > >
> > > > > I am +1 to relaxing the requirement of Jira ticket.
> > > > >
> > > > > Rafael, what do you mean when you say "Jira tickets are used to
> > > register
> > > > > changes"?
> > > > >
> > > > > I think ever since 4.9 the actual PRs included in the code are the
> > > source
> > > > > of truth for the changes in the actual code (at least from a
> release
> > > > notes
> > > > > perspective).  This is why the release notes can show changes that
> > only
> > > > > have PRs and no Jira ticket.  At least my release notes generator
> is
> > > > built
> > > > > that way.  I think Rohit has built a similar release notes
> generator,
> > > so
> > > > I
> > > > > can't speak to his version...
> > > > >
> > > > > *Will Stevens*
> > > > > Chief Technology Officer
> > > > > c 514.826.0190
> > > > >
> > > > > 
> > > > >
> > > > > On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
> > > > > rafaelweingart...@gmail.com> wrote:
> > > > >
> > > > > > Marc, yes Jira tickets are used to register changes. However,
> what
> > > > Rohit
> > > > > > and others (including me) are noticing is that there are certain
> > > types
> > > > of
> > > > > > changes (minor/bureaucracy) that do not require Jira tickets. The
> > > issue
> > > > > is
> > > > > > the wording “change”. What consist of a change that is worth
> > > mentioning
> > > > > in
> > > > > > the release notes? Everything we do in a branch is a change
> > towards a
> > > > > > release, but not everything is useful for
> operators/administrators
> > to
> > > > > see.
> > > > > >
> > > > > > I would say that to fix bugs, introduce new features, extend
> > existing
> > > > > > features, introduce a major change in the code such as that
> > standard
> > > > > maven
> > > > > > thing that you did, they 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rafael Weingärtner]

I prefer the workflow in Github as you guy, but to be fair with Jira ticket
system I mentioned it.

@Marc, yes Jira can facilitate a lot the management. However, we do not use
it fully. In our workflow, there is no planning/roadmap for the next
release per se. Things seem to work in an ad-hoc fashion. On the other
hand, when you need to break down milestones into issues/tickets/tasks and
then divide them into sprints, and manage a team of developers, the
oversight provided by Jira system is very good; specially, when issues
start to take more than a single sprint to finish.

On Tue, Mar 13, 2018 at 9:44 AM, Marc-Aurèle Brothier 
wrote:

> @rafael, you said: they all required Jira tickets to track the discussion
> and facilitate the management
>
> I can see the discussion happening in the PR on github, but the Jira ticket
> by itself doesn't do much, except copy/pasting the github discussion. Then
> it's down to "facilitate the management", which I only see as listing the
> changes for a release as far as I know. But this can be achieved on github
> too.
>
> As Daan mentioned, there are those things that are not code related which
> should have a way of tracking. But what's the difference in tracking them
> as a Jira issue vs a Github issue (they can't be a PR)? Those are point of
> view exchanges with messages & links, with a final status, most of the time
> without a strong link to a release number. If they do, they can be added to
> a milestone.
>
> So far I don't see how things done with Jira cannot be achieved on Github.
> It's just a matter of changing habits to simplify the workflow for new
> comers (and old joiners too ;-) ).
>
> On Tue, Mar 13, 2018 at 1:02 PM, Daan Hoogland 
> wrote:
>
> > Will, you are speaking my mind; any external registration tool should be
> > based on the source. The only reason for having an external tool without
> > relation to the code is to keep track of what is *not* (or not fully)
> > implemented.
> >
> > On Tue, Mar 13, 2018 at 12:58 PM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> > > I meant a way of describing them (changes/proposals) further. Sometimes
> > we
> > > have commits only with title, and then the Jira ticket would be a way
> of
> > > documenting that commit. I do prefer the idea of inserting the whole
> > > description in the commit body though. [for me] it looks easier to work
> > > directly with commits and PRs; as you said, we can generate release
> notes
> > > based on commits directly [and issues on GH]. However, for that, we
> need
> > to
> > > fine-tune our workflow.
> > >
> > >
> > > On Tue, Mar 13, 2018 at 8:40 AM, Will Stevens 
> > > wrote:
> > >
> > > > I am +1 to relaxing the requirement of Jira ticket.
> > > >
> > > > Rafael, what do you mean when you say "Jira tickets are used to
> > register
> > > > changes"?
> > > >
> > > > I think ever since 4.9 the actual PRs included in the code are the
> > source
> > > > of truth for the changes in the actual code (at least from a release
> > > notes
> > > > perspective).  This is why the release notes can show changes that
> only
> > > > have PRs and no Jira ticket.  At least my release notes generator is
> > > built
> > > > that way.  I think Rohit has built a similar release notes generator,
> > so
> > > I
> > > > can't speak to his version...
> > > >
> > > > *Will Stevens*
> > > > Chief Technology Officer
> > > > c 514.826.0190
> > > >
> > > > 
> > > >
> > > > On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
> > > > rafaelweingart...@gmail.com> wrote:
> > > >
> > > > > Marc, yes Jira tickets are used to register changes. However, what
> > > Rohit
> > > > > and others (including me) are noticing is that there are certain
> > types
> > > of
> > > > > changes (minor/bureaucracy) that do not require Jira tickets. The
> > issue
> > > > is
> > > > > the wording “change”. What consist of a change that is worth
> > mentioning
> > > > in
> > > > > the release notes? Everything we do in a branch is a change
> towards a
> > > > > release, but not everything is useful for operators/administrators
> to
> > > > see.
> > > > >
> > > > > I would say that to fix bugs, introduce new features, extend
> existing
> > > > > features, introduce a major change in the code such as that
> standard
> > > > maven
> > > > > thing that you did, they all required Jira tickets to track the
> > > > discussion
> > > > > and facilitate the management. On the other side of the spectrum,
> we
> > > have
> > > > > things such as removing dead/unused code, opening a new version
> > > (creating
> > > > > the upgrade path that we still use for the DB), fix a description
> in
> > an
> > > > API
> > > > > method, and so on. Moreover, the excessive use of Jira tickets
> leads
> > to
> > > > > hundreds of Jira tickets that we do not know that status of. We
> have
> > > > quite
> > > > > a big number of tickets opened that 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Marc-Aurèle Brothier]

@rafael, you said: they all required Jira tickets to track the discussion
and facilitate the management

I can see the discussion happening in the PR on github, but the Jira ticket
by itself doesn't do much, except copy/pasting the github discussion. Then
it's down to "facilitate the management", which I only see as listing the
changes for a release as far as I know. But this can be achieved on github
too.

As Daan mentioned, there are those things that are not code related which
should have a way of tracking. But what's the difference in tracking them
as a Jira issue vs a Github issue (they can't be a PR)? Those are point of
view exchanges with messages & links, with a final status, most of the time
without a strong link to a release number. If they do, they can be added to
a milestone.

So far I don't see how things done with Jira cannot be achieved on Github.
It's just a matter of changing habits to simplify the workflow for new
comers (and old joiners too ;-) ).

On Tue, Mar 13, 2018 at 1:02 PM, Daan Hoogland 
wrote:

> Will, you are speaking my mind; any external registration tool should be
> based on the source. The only reason for having an external tool without
> relation to the code is to keep track of what is *not* (or not fully)
> implemented.
>
> On Tue, Mar 13, 2018 at 12:58 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > I meant a way of describing them (changes/proposals) further. Sometimes
> we
> > have commits only with title, and then the Jira ticket would be a way of
> > documenting that commit. I do prefer the idea of inserting the whole
> > description in the commit body though. [for me] it looks easier to work
> > directly with commits and PRs; as you said, we can generate release notes
> > based on commits directly [and issues on GH]. However, for that, we need
> to
> > fine-tune our workflow.
> >
> >
> > On Tue, Mar 13, 2018 at 8:40 AM, Will Stevens 
> > wrote:
> >
> > > I am +1 to relaxing the requirement of Jira ticket.
> > >
> > > Rafael, what do you mean when you say "Jira tickets are used to
> register
> > > changes"?
> > >
> > > I think ever since 4.9 the actual PRs included in the code are the
> source
> > > of truth for the changes in the actual code (at least from a release
> > notes
> > > perspective).  This is why the release notes can show changes that only
> > > have PRs and no Jira ticket.  At least my release notes generator is
> > built
> > > that way.  I think Rohit has built a similar release notes generator,
> so
> > I
> > > can't speak to his version...
> > >
> > > *Will Stevens*
> > > Chief Technology Officer
> > > c 514.826.0190
> > >
> > > 
> > >
> > > On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
> > > rafaelweingart...@gmail.com> wrote:
> > >
> > > > Marc, yes Jira tickets are used to register changes. However, what
> > Rohit
> > > > and others (including me) are noticing is that there are certain
> types
> > of
> > > > changes (minor/bureaucracy) that do not require Jira tickets. The
> issue
> > > is
> > > > the wording “change”. What consist of a change that is worth
> mentioning
> > > in
> > > > the release notes? Everything we do in a branch is a change towards a
> > > > release, but not everything is useful for operators/administrators to
> > > see.
> > > >
> > > > I would say that to fix bugs, introduce new features, extend existing
> > > > features, introduce a major change in the code such as that standard
> > > maven
> > > > thing that you did, they all required Jira tickets to track the
> > > discussion
> > > > and facilitate the management. On the other side of the spectrum, we
> > have
> > > > things such as removing dead/unused code, opening a new version
> > (creating
> > > > the upgrade path that we still use for the DB), fix a description in
> an
> > > API
> > > > method, and so on. Moreover, the excessive use of Jira tickets leads
> to
> > > > hundreds of Jira tickets that we do not know that status of. We have
> > > quite
> > > > a big number of tickets opened that could be closed. This has been
> > worse;
> > > > we are improving as time goes by.
> > > >
> > > > I would say that to make this more transparent to others (especially
> > > > newcomers), we need to discuss it, then write it down to make it
> > > > transparent the way we are working.
> > > >
> > > > On Tue, Mar 13, 2018 at 6:59 AM, Marc-Aurèle Brothier <
> > ma...@exoscale.ch
> > > >
> > > > wrote:
> > > >
> > > > > That's a good idea, because people are more and more used to only
> > > create
> > > > PR
> > > > > on github, and it would be helpful to be more explanatory on the
> way
> > we
> > > > > work to push changes. I still think we should encourage the use of
> > the
> > > > > github milestone as Rohit did with the 4.11.0 (
> > > > > https://github.com/apache/cloudstack/milestone/3?closed=1) to list
> > the
> > > > > changes in the release notes with the help of the labels 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Daan Hoogland]

Will, you are speaking my mind; any external registration tool should be
based on the source. The only reason for having an external tool without
relation to the code is to keep track of what is *not* (or not fully)
implemented.

On Tue, Mar 13, 2018 at 12:58 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> I meant a way of describing them (changes/proposals) further. Sometimes we
> have commits only with title, and then the Jira ticket would be a way of
> documenting that commit. I do prefer the idea of inserting the whole
> description in the commit body though. [for me] it looks easier to work
> directly with commits and PRs; as you said, we can generate release notes
> based on commits directly [and issues on GH]. However, for that, we need to
> fine-tune our workflow.
>
>
> On Tue, Mar 13, 2018 at 8:40 AM, Will Stevens 
> wrote:
>
> > I am +1 to relaxing the requirement of Jira ticket.
> >
> > Rafael, what do you mean when you say "Jira tickets are used to register
> > changes"?
> >
> > I think ever since 4.9 the actual PRs included in the code are the source
> > of truth for the changes in the actual code (at least from a release
> notes
> > perspective).  This is why the release notes can show changes that only
> > have PRs and no Jira ticket.  At least my release notes generator is
> built
> > that way.  I think Rohit has built a similar release notes generator, so
> I
> > can't speak to his version...
> >
> > *Will Stevens*
> > Chief Technology Officer
> > c 514.826.0190
> >
> > 
> >
> > On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> > > Marc, yes Jira tickets are used to register changes. However, what
> Rohit
> > > and others (including me) are noticing is that there are certain types
> of
> > > changes (minor/bureaucracy) that do not require Jira tickets. The issue
> > is
> > > the wording “change”. What consist of a change that is worth mentioning
> > in
> > > the release notes? Everything we do in a branch is a change towards a
> > > release, but not everything is useful for operators/administrators to
> > see.
> > >
> > > I would say that to fix bugs, introduce new features, extend existing
> > > features, introduce a major change in the code such as that standard
> > maven
> > > thing that you did, they all required Jira tickets to track the
> > discussion
> > > and facilitate the management. On the other side of the spectrum, we
> have
> > > things such as removing dead/unused code, opening a new version
> (creating
> > > the upgrade path that we still use for the DB), fix a description in an
> > API
> > > method, and so on. Moreover, the excessive use of Jira tickets leads to
> > > hundreds of Jira tickets that we do not know that status of. We have
> > quite
> > > a big number of tickets opened that could be closed. This has been
> worse;
> > > we are improving as time goes by.
> > >
> > > I would say that to make this more transparent to others (especially
> > > newcomers), we need to discuss it, then write it down to make it
> > > transparent the way we are working.
> > >
> > > On Tue, Mar 13, 2018 at 6:59 AM, Marc-Aurèle Brothier <
> ma...@exoscale.ch
> > >
> > > wrote:
> > >
> > > > That's a good idea, because people are more and more used to only
> > create
> > > PR
> > > > on github, and it would be helpful to be more explanatory on the way
> we
> > > > work to push changes. I still think we should encourage the use of
> the
> > > > github milestone as Rohit did with the 4.11.0 (
> > > > https://github.com/apache/cloudstack/milestone/3?closed=1) to list
> the
> > > > changes in the release notes with the help of the labels to tag the
> PRs
> > > > instead of relying on the jira ticket (it requires to have another
> > > login).
> > > >
> > > > As far as I can remember, the JIRA tickets are used to list the
> changes
> > > of
> > > > a release, but nothing else. Or am I missing something?
> > > >
> > > > Marc-Aurèle
> > > >
> > > > On Tue, Mar 13, 2018 at 9:57 AM, Rohit Yadav <
> > rohit.ya...@shapeblue.com>
> > > > wrote:
> > > >
> > > > > All,
> > > > >
> > > > >
> > > > > To make it easier for people to contribute changes and encourage
> > > > > PR/contributions, should we relax the requirement of a JIRA ticket
> > for
> > > > pull
> > > > > requests that solve trivial/minor issues such as doc bugs, build
> > fixes
> > > > etc?
> > > > > A JIRA ticket may still be necessary for new features and
> non-trivial
> > > > > bugfixes or changes.
> > > > >
> > > > >
> > > > > Another alternative could be to introduce a CONTRIBUTING.md [1]
> that
> > > > > explains the list of expected things to contributors when they
> send a
> > > PR
> > > > > (for example, a jira id, links to fs or other resources, a short
> > > summary
> > > > > and long description, test results etc).
> > > > >
> > > > >
> > > > > Thoughts?
> > > > >
> > > > >
> > > > > [1] 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rafael Weingärtner]

I meant a way of describing them (changes/proposals) further. Sometimes we
have commits only with title, and then the Jira ticket would be a way of
documenting that commit. I do prefer the idea of inserting the whole
description in the commit body though. [for me] it looks easier to work
directly with commits and PRs; as you said, we can generate release notes
based on commits directly [and issues on GH]. However, for that, we need to
fine-tune our workflow.


On Tue, Mar 13, 2018 at 8:40 AM, Will Stevens  wrote:

> I am +1 to relaxing the requirement of Jira ticket.
>
> Rafael, what do you mean when you say "Jira tickets are used to register
> changes"?
>
> I think ever since 4.9 the actual PRs included in the code are the source
> of truth for the changes in the actual code (at least from a release notes
> perspective).  This is why the release notes can show changes that only
> have PRs and no Jira ticket.  At least my release notes generator is built
> that way.  I think Rohit has built a similar release notes generator, so I
> can't speak to his version...
>
> *Will Stevens*
> Chief Technology Officer
> c 514.826.0190
>
> 
>
> On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > Marc, yes Jira tickets are used to register changes. However, what Rohit
> > and others (including me) are noticing is that there are certain types of
> > changes (minor/bureaucracy) that do not require Jira tickets. The issue
> is
> > the wording “change”. What consist of a change that is worth mentioning
> in
> > the release notes? Everything we do in a branch is a change towards a
> > release, but not everything is useful for operators/administrators to
> see.
> >
> > I would say that to fix bugs, introduce new features, extend existing
> > features, introduce a major change in the code such as that standard
> maven
> > thing that you did, they all required Jira tickets to track the
> discussion
> > and facilitate the management. On the other side of the spectrum, we have
> > things such as removing dead/unused code, opening a new version (creating
> > the upgrade path that we still use for the DB), fix a description in an
> API
> > method, and so on. Moreover, the excessive use of Jira tickets leads to
> > hundreds of Jira tickets that we do not know that status of. We have
> quite
> > a big number of tickets opened that could be closed. This has been worse;
> > we are improving as time goes by.
> >
> > I would say that to make this more transparent to others (especially
> > newcomers), we need to discuss it, then write it down to make it
> > transparent the way we are working.
> >
> > On Tue, Mar 13, 2018 at 6:59 AM, Marc-Aurèle Brothier  >
> > wrote:
> >
> > > That's a good idea, because people are more and more used to only
> create
> > PR
> > > on github, and it would be helpful to be more explanatory on the way we
> > > work to push changes. I still think we should encourage the use of the
> > > github milestone as Rohit did with the 4.11.0 (
> > > https://github.com/apache/cloudstack/milestone/3?closed=1) to list the
> > > changes in the release notes with the help of the labels to tag the PRs
> > > instead of relying on the jira ticket (it requires to have another
> > login).
> > >
> > > As far as I can remember, the JIRA tickets are used to list the changes
> > of
> > > a release, but nothing else. Or am I missing something?
> > >
> > > Marc-Aurèle
> > >
> > > On Tue, Mar 13, 2018 at 9:57 AM, Rohit Yadav <
> rohit.ya...@shapeblue.com>
> > > wrote:
> > >
> > > > All,
> > > >
> > > >
> > > > To make it easier for people to contribute changes and encourage
> > > > PR/contributions, should we relax the requirement of a JIRA ticket
> for
> > > pull
> > > > requests that solve trivial/minor issues such as doc bugs, build
> fixes
> > > etc?
> > > > A JIRA ticket may still be necessary for new features and non-trivial
> > > > bugfixes or changes.
> > > >
> > > >
> > > > Another alternative could be to introduce a CONTRIBUTING.md [1] that
> > > > explains the list of expected things to contributors when they send a
> > PR
> > > > (for example, a jira id, links to fs or other resources, a short
> > summary
> > > > and long description, test results etc).
> > > >
> > > >
> > > > Thoughts?
> > > >
> > > >
> > > > [1] https://help.github.com/articles/setting-guidelines-
> > > > for-repository-contributors/
> > > >
> > > >
> > > > - Rohit
> > > >
> > > > 
> > > >
> > > >
> > > >
> > > > rohit.ya...@shapeblue.com
> > > > www.shapeblue.com
> > > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > > @shapeblue
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>



-- 
Rafael Weingärtner

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Will Stevens]

I am +1 to relaxing the requirement of Jira ticket.

Rafael, what do you mean when you say "Jira tickets are used to register
changes"?

I think ever since 4.9 the actual PRs included in the code are the source
of truth for the changes in the actual code (at least from a release notes
perspective).  This is why the release notes can show changes that only
have PRs and no Jira ticket.  At least my release notes generator is built
that way.  I think Rohit has built a similar release notes generator, so I
can't speak to his version...

*Will Stevens*
Chief Technology Officer
c 514.826.0190



On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Marc, yes Jira tickets are used to register changes. However, what Rohit
> and others (including me) are noticing is that there are certain types of
> changes (minor/bureaucracy) that do not require Jira tickets. The issue is
> the wording “change”. What consist of a change that is worth mentioning in
> the release notes? Everything we do in a branch is a change towards a
> release, but not everything is useful for operators/administrators to see.
>
> I would say that to fix bugs, introduce new features, extend existing
> features, introduce a major change in the code such as that standard maven
> thing that you did, they all required Jira tickets to track the discussion
> and facilitate the management. On the other side of the spectrum, we have
> things such as removing dead/unused code, opening a new version (creating
> the upgrade path that we still use for the DB), fix a description in an API
> method, and so on. Moreover, the excessive use of Jira tickets leads to
> hundreds of Jira tickets that we do not know that status of. We have quite
> a big number of tickets opened that could be closed. This has been worse;
> we are improving as time goes by.
>
> I would say that to make this more transparent to others (especially
> newcomers), we need to discuss it, then write it down to make it
> transparent the way we are working.
>
> On Tue, Mar 13, 2018 at 6:59 AM, Marc-Aurèle Brothier 
> wrote:
>
> > That's a good idea, because people are more and more used to only create
> PR
> > on github, and it would be helpful to be more explanatory on the way we
> > work to push changes. I still think we should encourage the use of the
> > github milestone as Rohit did with the 4.11.0 (
> > https://github.com/apache/cloudstack/milestone/3?closed=1) to list the
> > changes in the release notes with the help of the labels to tag the PRs
> > instead of relying on the jira ticket (it requires to have another
> login).
> >
> > As far as I can remember, the JIRA tickets are used to list the changes
> of
> > a release, but nothing else. Or am I missing something?
> >
> > Marc-Aurèle
> >
> > On Tue, Mar 13, 2018 at 9:57 AM, Rohit Yadav 
> > wrote:
> >
> > > All,
> > >
> > >
> > > To make it easier for people to contribute changes and encourage
> > > PR/contributions, should we relax the requirement of a JIRA ticket for
> > pull
> > > requests that solve trivial/minor issues such as doc bugs, build fixes
> > etc?
> > > A JIRA ticket may still be necessary for new features and non-trivial
> > > bugfixes or changes.
> > >
> > >
> > > Another alternative could be to introduce a CONTRIBUTING.md [1] that
> > > explains the list of expected things to contributors when they send a
> PR
> > > (for example, a jira id, links to fs or other resources, a short
> summary
> > > and long description, test results etc).
> > >
> > >
> > > Thoughts?
> > >
> > >
> > > [1] https://help.github.com/articles/setting-guidelines-
> > > for-repository-contributors/
> > >
> > >
> > > - Rohit
> > >
> > > 
> > >
> > >
> > >
> > > rohit.ya...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> > >
> >
>
>
>
> --
> Rafael Weingärtner
>

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rafael Weingärtner]

Marc, yes Jira tickets are used to register changes. However, what Rohit
and others (including me) are noticing is that there are certain types of
changes (minor/bureaucracy) that do not require Jira tickets. The issue is
the wording “change”. What consist of a change that is worth mentioning in
the release notes? Everything we do in a branch is a change towards a
release, but not everything is useful for operators/administrators to see.

I would say that to fix bugs, introduce new features, extend existing
features, introduce a major change in the code such as that standard maven
thing that you did, they all required Jira tickets to track the discussion
and facilitate the management. On the other side of the spectrum, we have
things such as removing dead/unused code, opening a new version (creating
the upgrade path that we still use for the DB), fix a description in an API
method, and so on. Moreover, the excessive use of Jira tickets leads to
hundreds of Jira tickets that we do not know that status of. We have quite
a big number of tickets opened that could be closed. This has been worse;
we are improving as time goes by.

I would say that to make this more transparent to others (especially
newcomers), we need to discuss it, then write it down to make it
transparent the way we are working.

On Tue, Mar 13, 2018 at 6:59 AM, Marc-Aurèle Brothier 
wrote:

> That's a good idea, because people are more and more used to only create PR
> on github, and it would be helpful to be more explanatory on the way we
> work to push changes. I still think we should encourage the use of the
> github milestone as Rohit did with the 4.11.0 (
> https://github.com/apache/cloudstack/milestone/3?closed=1) to list the
> changes in the release notes with the help of the labels to tag the PRs
> instead of relying on the jira ticket (it requires to have another login).
>
> As far as I can remember, the JIRA tickets are used to list the changes of
> a release, but nothing else. Or am I missing something?
>
> Marc-Aurèle
>
> On Tue, Mar 13, 2018 at 9:57 AM, Rohit Yadav 
> wrote:
>
> > All,
> >
> >
> > To make it easier for people to contribute changes and encourage
> > PR/contributions, should we relax the requirement of a JIRA ticket for
> pull
> > requests that solve trivial/minor issues such as doc bugs, build fixes
> etc?
> > A JIRA ticket may still be necessary for new features and non-trivial
> > bugfixes or changes.
> >
> >
> > Another alternative could be to introduce a CONTRIBUTING.md [1] that
> > explains the list of expected things to contributors when they send a PR
> > (for example, a jira id, links to fs or other resources, a short summary
> > and long description, test results etc).
> >
> >
> > Thoughts?
> >
> >
> > [1] https://help.github.com/articles/setting-guidelines-
> > for-repository-contributors/
> >
> >
> > - Rohit
> >
> > 
> >
> >
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>



-- 
Rafael Weingärtner

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Marc-Aurèle Brothier]

That's a good idea, because people are more and more used to only create PR
on github, and it would be helpful to be more explanatory on the way we
work to push changes. I still think we should encourage the use of the
github milestone as Rohit did with the 4.11.0 (
https://github.com/apache/cloudstack/milestone/3?closed=1) to list the
changes in the release notes with the help of the labels to tag the PRs
instead of relying on the jira ticket (it requires to have another login).

As far as I can remember, the JIRA tickets are used to list the changes of
a release, but nothing else. Or am I missing something?

Marc-Aurèle

On Tue, Mar 13, 2018 at 9:57 AM, Rohit Yadav 
wrote:

> All,
>
>
> To make it easier for people to contribute changes and encourage
> PR/contributions, should we relax the requirement of a JIRA ticket for pull
> requests that solve trivial/minor issues such as doc bugs, build fixes etc?
> A JIRA ticket may still be necessary for new features and non-trivial
> bugfixes or changes.
>
>
> Another alternative could be to introduce a CONTRIBUTING.md [1] that
> explains the list of expected things to contributors when they send a PR
> (for example, a jira id, links to fs or other resources, a short summary
> and long description, test results etc).
>
>
> Thoughts?
>
>
> [1] https://help.github.com/articles/setting-guidelines-
> for-repository-contributors/
>
>
> - Rohit
>
> 
>
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>