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

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

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 wrote: > Boris, I hate to be strongly opinionated but I have to violently disagree >

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

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

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

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 Sent: Wednesday, March 14, 2018 7:05:04 AM To: dev Subject:

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

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

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

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

Re: [DISCUSS] CloudStack Connection Pools

Why would we want to expose this choice to administrator of Cloudstack whose responsibility is to keep it running and not knowing about the inner-mechanic of how it works. right? It's not like that we're giving them a choice of which database to connect to. So on that note, I would say we need to

Re: [DISCUSS] CloudStack Connection Pools

I agree with Khosrow. Even though the idea of externalizing a configuration like this seems interesting, I believe that it would bring more complications than benefits. And, at the end of the day operators would only use the default. On Wed, Mar 14, 2018 at 2:50 PM, Khosrow Moossavi

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

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

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

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

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

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

Re: [DISCUSS] CloudStack Connection Pools

Thanks Khosrow and Rafael. You both agree on Spring Data as the best option, I see it would require a big effort and commitment to migrate to it, therefore it can take some (long) time to achieve it. As a more viable option, would you agree on supporting different connection pool management

Re: [DISCUSS] CloudStack Connection Pools

When everything works smooth - the end user does not need to know whats under the hood. However, when things begin to swing and your hands are tied to just one CP - what do you do? On Wed, Mar 14, 2018 at 10:50 AM, Khosrow Moossavi wrote: > Why would we want to expose

Re: [DISCUSS] CloudStack Connection Pools

Rafael and Khosrow, I actually think quite the opposite on DBCP development. Please pull up latest commits and release notes on DBCP. An assumption that its an Apache project and therefore will live and flourish - is a dangerous one. It comes down to who supports the project and if there funding