RE: JIRA - PLEASE READ
From reading back through the thread, I think pauls initial point was around the fact that currently (and I don’t know whether this is hardcoded in our guidelines,etc) there is an assumption that the workflow for an issue will be Jira issue>fix>PR>> - and that is followed erratically The Jira issue usually contains the original problem statement, whether reported by somebody here or a regular user. It then allows people to trace that problem statement through the release note path to see when it was fixed And when I say people here - I am not talking about the people on this list - I am talking about the people out there using ACS in the wild. Will - I fully get your statement "I personally have never searched jira for an issue." And understand why you wouldn't have - but that is maybe the root of the point here. People outside of our core dev community do - a lot (I can verify that from first hand experience) If we want ACS adoption to grow, maintaining *some* form of reliable trackable issues list is essential IMO Jira is currently THE data point that most of our users (who don’t have the luxury of participating in these lists or being able to understand code commits) currently will use to identify the symptoms theyre experiencing & see what version of ACS fixed the problem (again, from first hand experience) The other factor is the fact that jira is very "visible" in searches (Just google "cloudstack unable" foo ) - it will be the first place that many people stumble into when tracking down their problems. Use it or not - that should be consistent IMO I have ZERO affinity to Jira (I'll show my hand and say I've never liked it) and do not like the potential split brain of having no mapped relationship between issues and PR's. So, if github issues do a better job - then great - lets do it. Kind regards Giles giles.sir...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -Original Message- From: Paul Angus [mailto:paul.an...@shapeblue.com] Sent: 30 June 2017 16:34 To: dev@cloudstack.apache.org Subject: RE: JIRA - PLEASE READ Whether we use 'GitHub Issues' or 'Jira Issues' doesn't change the basic point, which is bug fixes and indeed features need to be tracked. If someone wants to know what versions a feature is in, or what version a bug was fixed, or if anyone has experienced/reported/fix a bug that they are experiencing, then they need somewhere to go to find that. When doing a release we need to be able to easily see what bugs are outstanding for that release and which are blocker/critical etc. Burying information in PRs just leads to chaos. And if someone has to write a tool to extract what has gone into a release, then it's obviously too complicated. Kind regards, Paul Angus paul.an...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -Original Message- From: Will Stevens [mailto:williamstev...@gmail.com] Sent: 30 June 2017 16:07 To: dev@cloudstack.apache.org Subject: Re: JIRA - PLEASE READ Yes, we would be adopting github issues for that then. If you want to handle those in jira we could, but i personally dont see any value in a jira ticket for an actual PR. On Jun 30, 2017 10:26 AM, "Ron Wheeler" wrote: > Going back to my previous point. > Whatever makes the preparation of Release Notes easier should drive > the policy. > > It sounds like Will is favouring a complete abandonment of the JIRA. > Does this change the end-user's process for reporting bugs or > requesting new features? > > Ron > > On 30/06/2017 9:09 AM, Will Stevens wrote: > >> Back to jira. I personally have never searched jira for an issue. I >> search github prs for issues often though to see what code is >> actually pending for different issues. I dont think i am alone in >> that. >> >> My stance is that unless we have a solid reason for using jira which >> we can not solve with github at this point, we should reconsider our >> use of jira. >> >> Now that we have gitbox setup, i think we have the ability to use >> Issues as well as PRs. I think it is much wiser to keep the >> discussion around the code much closer to the code and not in a 3rd >> system. By using jira we encourage people who are contributing to >> the discussion to never look at the code because it is not available >> in the same screen. I think it is much more useful to discuss changes >> with the context of the code at your finger tips. Comment on >> specific lines of code, review the conformance to the style guide, >> etc... >> >> Also, I think the argument that jira somehow helps with release notes &g
RE: JIRA - PLEASE READ
Whether we use 'GitHub Issues' or 'Jira Issues' doesn't change the basic point, which is bug fixes and indeed features need to be tracked. If someone wants to know what versions a feature is in, or what version a bug was fixed, or if anyone has experienced/reported/fix a bug that they are experiencing, then they need somewhere to go to find that. When doing a release we need to be able to easily see what bugs are outstanding for that release and which are blocker/critical etc. Burying information in PRs just leads to chaos. And if someone has to write a tool to extract what has gone into a release, then it's obviously too complicated. Kind regards, Paul Angus paul.an...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -Original Message- From: Will Stevens [mailto:williamstev...@gmail.com] Sent: 30 June 2017 16:07 To: dev@cloudstack.apache.org Subject: Re: JIRA - PLEASE READ Yes, we would be adopting github issues for that then. If you want to handle those in jira we could, but i personally dont see any value in a jira ticket for an actual PR. On Jun 30, 2017 10:26 AM, "Ron Wheeler" wrote: > Going back to my previous point. > Whatever makes the preparation of Release Notes easier should drive > the policy. > > It sounds like Will is favouring a complete abandonment of the JIRA. > Does this change the end-user's process for reporting bugs or > requesting new features? > > Ron > > On 30/06/2017 9:09 AM, Will Stevens wrote: > >> Back to jira. I personally have never searched jira for an issue. I >> search github prs for issues often though to see what code is >> actually pending for different issues. I dont think i am alone in >> that. >> >> My stance is that unless we have a solid reason for using jira which >> we can not solve with github at this point, we should reconsider our >> use of jira. >> >> Now that we have gitbox setup, i think we have the ability to use >> Issues as well as PRs. I think it is much wiser to keep the >> discussion around the code much closer to the code and not in a 3rd >> system. By using jira we encourage people who are contributing to >> the discussion to never look at the code because it is not available >> in the same screen. I think it is much more useful to discuss changes >> with the context of the code at your finger tips. Comment on >> specific lines of code, review the conformance to the style guide, >> etc... >> >> Also, I think the argument that jira somehow helps with release notes >> is being made by people who have never created the release notes. >> When using jira, you are assuming that everyone has jira in their >> workflow and the status of a ticket is always right. This is almost >> never the case and there is a huge amount of man effort to try to >> manage that delta. My colleague, Pierre-Luc Dion, has historically >> created the majority of release notes up until 4.9, when I scripted >> based on the PRs actually merged (as I was the >> 4.9 RM). My script tried to associate jira tickets if it could find >> them, but not every piece of code merged had a ticket (which will >> always be the case). There will always be a PR for a change, there >> wont always be a jira ticket. That alone should mean that we should >> be doing release notes based on the PRs and not the jira tickets. >> Also, Pierre-Luc does not have the time to spend a week building the >> release notes anymore for every release, he is a busy man... >> >> Anyway, these are my two cents. As always I am open to other opinions >> and points of view. I would encourage us to try to understand and >> pinpoint what we think adding jira to the flow actually achieves. Now >> that we have the gitbox integration I feel like we should move the >> vast majority of the development and issue related workflows closer >> to the code. >> >> Sorry for the wall of text... >> >> On Jun 30, 2017 6:52 AM, "Alex Hitchins" wrote: >> >> Hello, >> >> I've created a DISCUSS thread to... discuss this subject separately >> from the original Jira issue. >> >> Sorry Paul for hijacking your Jira rant. >> >> >> Alexander Hitchins >> >> E: a...@alexhitchins.com >> W: alexhitchins.com >> M: 07788 423 969 >> T: 01892 523 587 >> >> -Original Message- >> From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com] >> Sent: 29 June 2017 20:41 >> To: dev@cloudstack.apache.org >> Subject: Re: JIRA - PL
Re: JIRA - PLEASE READ
Yes, we would be adopting github issues for that then. If you want to handle those in jira we could, but i personally dont see any value in a jira ticket for an actual PR. On Jun 30, 2017 10:26 AM, "Ron Wheeler" wrote: > Going back to my previous point. > Whatever makes the preparation of Release Notes easier should drive the > policy. > > It sounds like Will is favouring a complete abandonment of the JIRA. > Does this change the end-user's process for reporting bugs or requesting > new features? > > Ron > > On 30/06/2017 9:09 AM, Will Stevens wrote: > >> Back to jira. I personally have never searched jira for an issue. I search >> github prs for issues often though to see what code is actually pending >> for >> different issues. I dont think i am alone in that. >> >> My stance is that unless we have a solid reason for using jira which we >> can >> not solve with github at this point, we should reconsider our use of jira. >> >> Now that we have gitbox setup, i think we have the ability to use Issues >> as >> well as PRs. I think it is much wiser to keep the discussion around the >> code much closer to the code and not in a 3rd system. By using jira we >> encourage people who are contributing to the discussion to never look at >> the code because it is not available in the same screen. I think it is >> much >> more useful to discuss changes with the context of the code at your finger >> tips. Comment on specific lines of code, review the conformance to the >> style guide, etc... >> >> Also, I think the argument that jira somehow helps with release notes is >> being made by people who have never created the release notes. When using >> jira, you are assuming that everyone has jira in their workflow and the >> status of a ticket is always right. This is almost never the case and >> there >> is a huge amount of man effort to try to manage that delta. My colleague, >> Pierre-Luc Dion, has historically created the majority of release notes up >> until 4.9, when I scripted based on the PRs actually merged (as I was the >> 4.9 RM). My script tried to associate jira tickets if it could find them, >> but not every piece of code merged had a ticket (which will always be the >> case). There will always be a PR for a change, there wont always be a jira >> ticket. That alone should mean that we should be doing release notes based >> on the PRs and not the jira tickets. Also, Pierre-Luc does not have the >> time to spend a week building the release notes anymore for every release, >> he is a busy man... >> >> Anyway, these are my two cents. As always I am open to other opinions and >> points of view. I would encourage us to try to understand and pinpoint >> what >> we think adding jira to the flow actually achieves. Now that we have the >> gitbox integration I feel like we should move the vast majority of the >> development and issue related workflows closer to the code. >> >> Sorry for the wall of text... >> >> On Jun 30, 2017 6:52 AM, "Alex Hitchins" wrote: >> >> Hello, >> >> I've created a DISCUSS thread to... discuss this subject separately from >> the original Jira issue. >> >> Sorry Paul for hijacking your Jira rant. >> >> >> Alexander Hitchins >> >> E: a...@alexhitchins.com >> W: alexhitchins.com >> M: 07788 423 969 >> T: 01892 523 587 >> >> -Original Message- >> From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com] >> Sent: 29 June 2017 20:41 >> To: dev@cloudstack.apache.org >> Subject: Re: JIRA - PLEASE READ >> >> That is what I am saying. Apache can (and does) handle donations, and >> there >> have been discussions about donations that can be directed to projects at >> the donation time (someone that knows about the topic could provide some >> help here?). >> >> >> So, the foundation part looks covered for meI think we need something >> else. >> >> On Thu, Jun 29, 2017 at 3:35 PM, Marty Godsey >> wrote: >> >> Rafael, >>> >>> I agree. I am not saying move away from Apache.. I am saying setup a >>> "foundation" to handle donations and even development management.. >>> >>> Regards, >>> Marty Godsey >>> Principal Engineer >>> nSource Solutions, LLC >>> >>> -Original Message- >>> From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com] >>> Sent: Thursday, June 29, 2017 3:28 PM >>
Re: JIRA - PLEASE READ
Going back to my previous point. Whatever makes the preparation of Release Notes easier should drive the policy. It sounds like Will is favouring a complete abandonment of the JIRA. Does this change the end-user's process for reporting bugs or requesting new features? Ron On 30/06/2017 9:09 AM, Will Stevens wrote: Back to jira. I personally have never searched jira for an issue. I search github prs for issues often though to see what code is actually pending for different issues. I dont think i am alone in that. My stance is that unless we have a solid reason for using jira which we can not solve with github at this point, we should reconsider our use of jira. Now that we have gitbox setup, i think we have the ability to use Issues as well as PRs. I think it is much wiser to keep the discussion around the code much closer to the code and not in a 3rd system. By using jira we encourage people who are contributing to the discussion to never look at the code because it is not available in the same screen. I think it is much more useful to discuss changes with the context of the code at your finger tips. Comment on specific lines of code, review the conformance to the style guide, etc... Also, I think the argument that jira somehow helps with release notes is being made by people who have never created the release notes. When using jira, you are assuming that everyone has jira in their workflow and the status of a ticket is always right. This is almost never the case and there is a huge amount of man effort to try to manage that delta. My colleague, Pierre-Luc Dion, has historically created the majority of release notes up until 4.9, when I scripted based on the PRs actually merged (as I was the 4.9 RM). My script tried to associate jira tickets if it could find them, but not every piece of code merged had a ticket (which will always be the case). There will always be a PR for a change, there wont always be a jira ticket. That alone should mean that we should be doing release notes based on the PRs and not the jira tickets. Also, Pierre-Luc does not have the time to spend a week building the release notes anymore for every release, he is a busy man... Anyway, these are my two cents. As always I am open to other opinions and points of view. I would encourage us to try to understand and pinpoint what we think adding jira to the flow actually achieves. Now that we have the gitbox integration I feel like we should move the vast majority of the development and issue related workflows closer to the code. Sorry for the wall of text... On Jun 30, 2017 6:52 AM, "Alex Hitchins" wrote: Hello, I've created a DISCUSS thread to... discuss this subject separately from the original Jira issue. Sorry Paul for hijacking your Jira rant. Alexander Hitchins E: a...@alexhitchins.com W: alexhitchins.com M: 07788 423 969 T: 01892 523 587 -Original Message- From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com] Sent: 29 June 2017 20:41 To: dev@cloudstack.apache.org Subject: Re: JIRA - PLEASE READ That is what I am saying. Apache can (and does) handle donations, and there have been discussions about donations that can be directed to projects at the donation time (someone that knows about the topic could provide some help here?). So, the foundation part looks covered for meI think we need something else. On Thu, Jun 29, 2017 at 3:35 PM, Marty Godsey wrote: Rafael, I agree. I am not saying move away from Apache.. I am saying setup a "foundation" to handle donations and even development management.. Regards, Marty Godsey Principal Engineer nSource Solutions, LLC -Original Message- From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com] Sent: Thursday, June 29, 2017 3:28 PM To: dev@cloudstack.apache.org Subject: Re: JIRA - PLEASE READ ACS is an Apache project, not a foundation per se; donation goes to Apache. I know that there is some discussion/work to create a way for donating things (not just money) to projects, but I do not know how that is going. I do not think we need to create other foundation and move away from Apache (because that is what this move would look like) But still, I wonder, even if we had a CloudStack foundation, would that make organizations that rely on it to donate/contribute more actively? Is that the real problem? On Thu, Jun 29, 2017 at 3:20 PM, Marty Godsey wrote: Alex, I agree.. The only "good" way that we will get more adoption is to treat it like an Enterprise product. But that would require investment. Investment with money, not just time. As an example, I use pfSense alot in my projects. If I put in a pfSense router, I take 2-5% (depends on scope) of the GDM and donate to the pfSense project. I do this because pfSense makes me a lot of money and I want it to get better.. The only way it will get better is by supporting it. And even if I was a coder, &qu
RE: JIRA - PLEASE READ
Back to jira. I personally have never searched jira for an issue. I search github prs for issues often though to see what code is actually pending for different issues. I dont think i am alone in that. My stance is that unless we have a solid reason for using jira which we can not solve with github at this point, we should reconsider our use of jira. Now that we have gitbox setup, i think we have the ability to use Issues as well as PRs. I think it is much wiser to keep the discussion around the code much closer to the code and not in a 3rd system. By using jira we encourage people who are contributing to the discussion to never look at the code because it is not available in the same screen. I think it is much more useful to discuss changes with the context of the code at your finger tips. Comment on specific lines of code, review the conformance to the style guide, etc... Also, I think the argument that jira somehow helps with release notes is being made by people who have never created the release notes. When using jira, you are assuming that everyone has jira in their workflow and the status of a ticket is always right. This is almost never the case and there is a huge amount of man effort to try to manage that delta. My colleague, Pierre-Luc Dion, has historically created the majority of release notes up until 4.9, when I scripted based on the PRs actually merged (as I was the 4.9 RM). My script tried to associate jira tickets if it could find them, but not every piece of code merged had a ticket (which will always be the case). There will always be a PR for a change, there wont always be a jira ticket. That alone should mean that we should be doing release notes based on the PRs and not the jira tickets. Also, Pierre-Luc does not have the time to spend a week building the release notes anymore for every release, he is a busy man... Anyway, these are my two cents. As always I am open to other opinions and points of view. I would encourage us to try to understand and pinpoint what we think adding jira to the flow actually achieves. Now that we have the gitbox integration I feel like we should move the vast majority of the development and issue related workflows closer to the code. Sorry for the wall of text... On Jun 30, 2017 6:52 AM, "Alex Hitchins" wrote: Hello, I've created a DISCUSS thread to... discuss this subject separately from the original Jira issue. Sorry Paul for hijacking your Jira rant. Alexander Hitchins E: a...@alexhitchins.com W: alexhitchins.com M: 07788 423 969 T: 01892 523 587 -Original Message- From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com] Sent: 29 June 2017 20:41 To: dev@cloudstack.apache.org Subject: Re: JIRA - PLEASE READ That is what I am saying. Apache can (and does) handle donations, and there have been discussions about donations that can be directed to projects at the donation time (someone that knows about the topic could provide some help here?). So, the foundation part looks covered for meI think we need something else. On Thu, Jun 29, 2017 at 3:35 PM, Marty Godsey wrote: > Rafael, > > I agree. I am not saying move away from Apache.. I am saying setup a > "foundation" to handle donations and even development management.. > > Regards, > Marty Godsey > Principal Engineer > nSource Solutions, LLC > > -Original Message- > From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com] > Sent: Thursday, June 29, 2017 3:28 PM > To: dev@cloudstack.apache.org > Subject: Re: JIRA - PLEASE READ > > ACS is an Apache project, not a foundation per se; donation goes to Apache. > I know that there is some discussion/work to create a way for donating > things (not just money) to projects, but I do not know how that is going. > > I do not think we need to create other foundation and move away from > Apache (because that is what this move would look like) > > But still, I wonder, even if we had a CloudStack foundation, would > that make organizations that rely on it to donate/contribute more > actively? Is that the real problem? > > > > On Thu, Jun 29, 2017 at 3:20 PM, Marty Godsey wrote: > > > Alex, > > > > I agree.. The only "good" way that we will get more adoption is to > > treat it like an Enterprise product. But that would require investment. > > Investment with money, not just time. > > > > As an example, I use pfSense alot in my projects. If I put in a > > pfSense router, I take 2-5% (depends on scope) of the GDM and donate > > to the pfSense project. I do this because pfSense makes me a lot of > > money and I want it to get better.. The only way it will get better > > is by supporting it. And even if I was a coder, "supporting" it with > > code > only goes so far. > > > >
RE: JIRA - PLEASE READ
Hello, I've created a DISCUSS thread to... discuss this subject separately from the original Jira issue. Sorry Paul for hijacking your Jira rant. Alexander Hitchins E: a...@alexhitchins.com W: alexhitchins.com M: 07788 423 969 T: 01892 523 587 -Original Message- From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com] Sent: 29 June 2017 20:41 To: dev@cloudstack.apache.org Subject: Re: JIRA - PLEASE READ That is what I am saying. Apache can (and does) handle donations, and there have been discussions about donations that can be directed to projects at the donation time (someone that knows about the topic could provide some help here?). So, the foundation part looks covered for meI think we need something else. On Thu, Jun 29, 2017 at 3:35 PM, Marty Godsey wrote: > Rafael, > > I agree. I am not saying move away from Apache.. I am saying setup a > "foundation" to handle donations and even development management.. > > Regards, > Marty Godsey > Principal Engineer > nSource Solutions, LLC > > -Original Message- > From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com] > Sent: Thursday, June 29, 2017 3:28 PM > To: dev@cloudstack.apache.org > Subject: Re: JIRA - PLEASE READ > > ACS is an Apache project, not a foundation per se; donation goes to Apache. > I know that there is some discussion/work to create a way for donating > things (not just money) to projects, but I do not know how that is going. > > I do not think we need to create other foundation and move away from > Apache (because that is what this move would look like) > > But still, I wonder, even if we had a CloudStack foundation, would > that make organizations that rely on it to donate/contribute more > actively? Is that the real problem? > > > > On Thu, Jun 29, 2017 at 3:20 PM, Marty Godsey wrote: > > > Alex, > > > > I agree.. The only "good" way that we will get more adoption is to > > treat it like an Enterprise product. But that would require investment. > > Investment with money, not just time. > > > > As an example, I use pfSense alot in my projects. If I put in a > > pfSense router, I take 2-5% (depends on scope) of the GDM and donate > > to the pfSense project. I do this because pfSense makes me a lot of > > money and I want it to get better.. The only way it will get better > > is by supporting it. And even if I was a coder, "supporting" it with > > code > only goes so far. > > > > And as mentioned, we create a CloudStack Foundation that is a 501C > > corp so it's a non-profit and tax deductible for people donating. > > > > So the next question is who would we speak with to get this ball > > rolling or even a discussion started? > > > > Regards, > > Marty Godsey > > Principal Engineer > > nSource Solutions, LLC > > > > -Original Message- > > From: Alex Hitchins [mailto:a...@alexhitchins.com] > > Sent: Thursday, June 29, 2017 1:49 PM > > To: dev@cloudstack.apache.org > > Subject: Re: JIRA - PLEASE READ > > > > If it isn't being treated as a product it will be very impossible to > > market it as enterprise ready. > > > > I know we all know this. > > > > Similar sized projects under the Apache banner must have the same > > issue, what is the best way to gather experience of these projects? > > See how they handle these growing pains. > > > > A cloudstack foundation entity funded by companies earning from > > cloudstack seems a good way forward. > > > > Another tuppence, this is getting expensive. > > > > > > > > > On 29 Jun 2017, at 18:18, Ron Wheeler > > > > > wrote: > > > > > > I understand that it is a volunteer organization. > > > I do not know how many (if any) of the committers and PMC members > > > are > > funded by their organizations (allowed or ordered to work on > > Cloudstack during company time) which is often the way that Apache > > projects get staffed. > > > > > > Clearly it is hard to tell someone who is being funded by a > > > company to > > fix a problem or who is working on their own time, to do or not do > > something. > > > > > > On the other hand, the PMC has to build a community culture that > > > is > > good for the project. > > > That means describing a vision, planning and enforcing a roadmap, > > > and > > maintaining a focused project "marketing" effort. > > > > > > There is a lot of extremely ta
RE: JIRA - PLEASE READ
All This thread seems to have turned into 2 quite different discussions: 1. The use (or not) of Jira - which was the original discussion 2. Ways/means of encouraging (and paying for more structured contributors) I know that it could be argued that these are related. Could I suggest opening up a thread on "release and project management and funding it" and keeping this thread to the original discussion (I will weigh in on both of these at some stage) Kind regards Giles giles.sir...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -Original Message- From: Alex Hitchins [mailto:a...@alexhitchins.com] Sent: 29 June 2017 18:49 To: dev@cloudstack.apache.org Subject: Re: JIRA - PLEASE READ If it isn't being treated as a product it will be very impossible to market it as enterprise ready. I know we all know this. Similar sized projects under the Apache banner must have the same issue, what is the best way to gather experience of these projects? See how they handle these growing pains. A cloudstack foundation entity funded by companies earning from cloudstack seems a good way forward. Another tuppence, this is getting expensive. > On 29 Jun 2017, at 18:18, Ron Wheeler wrote: > > I understand that it is a volunteer organization. > I do not know how many (if any) of the committers and PMC members are funded > by their organizations (allowed or ordered to work on Cloudstack during > company time) which is often the way that Apache projects get staffed. > > Clearly it is hard to tell someone who is being funded by a company to fix a > problem or who is working on their own time, to do or not do something. > > On the other hand, the PMC has to build a community culture that is good for > the project. > That means describing a vision, planning and enforcing a roadmap, and > maintaining a focused project "marketing" effort. > > There is a lot of extremely talented individuals working on Cloudstack and it > appears to have a very strong and valuable code-base. > > To me the key question is about the PMC and the core committers' ability to > make Cloudstack a "product" that can compete for market share and acceptance. > > Is Cloudstack at a point in its development where it should be treated like a > product? > - sufficient functionality to compete > - sufficient user base to be a competitor in the market > - production reliability and stability > - business model for supporting companies to justify their continued > support > > This may not require more effort but requires different policies and > different activities. > > There has to be someone or a PMC that can say "No". > - This change can not be included in this release because it will delay the > release. > - This change adds an unacceptable level of complexity > - This bug fix will have to wait for the next release because it is too late > to test it and fix the docs. > - This fix breaks the docs > - The release can not be made until this doc is updated. > > Does the core group want to make it a competitive product or is it sufficient > for the interested players to continue in its current form? > > Ron > > > >> On 29/06/2017 9:42 AM, Will Stevens wrote: >> I personally don't know how Jira solves any of this, but assuming it >> does, fine... >> >> The bigger problem which you have raised is that CloudStack has zero >> funding. So we can't hire a project manager, or a release manager or >> someone whose job it is to maintain documentation. I have been trying >> to find a way to, at the very least, fund a full time release manager >> who can focus 100% on the project. As the release manager for 4.9, I >> know it is a full time job. I did my best, but it is a ton of work >> and is hard to stay on top of. >> >> Everyone contributing to CloudStack is donating their time. They >> can't make a living off supporting ACS, so every one is doing their >> best with the little time they can take away from their day job or their >> family life. >> >> Yes, having clear guidelines and sticking to them helps, but without >> a solid CI infrastructure backing the project and improved testing >> and automation, we will always struggles with release schedules and such. >> >> I have been involved in this project long enough to know that all the >> problems you point out exist, but they are also not easily solved. >> Obviously we have to work with the initiatives we have and take small >> steps towards improvement, but we also have to be realistic with our >> expectations because we are counti
Re: JIRA - PLEASE READ
That is what I am saying. Apache can (and does) handle donations, and there have been discussions about donations that can be directed to projects at the donation time (someone that knows about the topic could provide some help here?). So, the foundation part looks covered for meI think we need something else. On Thu, Jun 29, 2017 at 3:35 PM, Marty Godsey wrote: > Rafael, > > I agree. I am not saying move away from Apache.. I am saying setup a > "foundation" to handle donations and even development management.. > > Regards, > Marty Godsey > Principal Engineer > nSource Solutions, LLC > > -Original Message- > From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com] > Sent: Thursday, June 29, 2017 3:28 PM > To: dev@cloudstack.apache.org > Subject: Re: JIRA - PLEASE READ > > ACS is an Apache project, not a foundation per se; donation goes to Apache. > I know that there is some discussion/work to create a way for donating > things (not just money) to projects, but I do not know how that is going. > > I do not think we need to create other foundation and move away from > Apache (because that is what this move would look like) > > But still, I wonder, even if we had a CloudStack foundation, would that > make organizations that rely on it to donate/contribute more actively? Is > that the real problem? > > > > On Thu, Jun 29, 2017 at 3:20 PM, Marty Godsey wrote: > > > Alex, > > > > I agree.. The only "good" way that we will get more adoption is to > > treat it like an Enterprise product. But that would require investment. > > Investment with money, not just time. > > > > As an example, I use pfSense alot in my projects. If I put in a > > pfSense router, I take 2-5% (depends on scope) of the GDM and donate > > to the pfSense project. I do this because pfSense makes me a lot of > > money and I want it to get better.. The only way it will get better is > > by supporting it. And even if I was a coder, "supporting" it with code > only goes so far. > > > > And as mentioned, we create a CloudStack Foundation that is a 501C > > corp so it's a non-profit and tax deductible for people donating. > > > > So the next question is who would we speak with to get this ball > > rolling or even a discussion started? > > > > Regards, > > Marty Godsey > > Principal Engineer > > nSource Solutions, LLC > > > > -Original Message- > > From: Alex Hitchins [mailto:a...@alexhitchins.com] > > Sent: Thursday, June 29, 2017 1:49 PM > > To: dev@cloudstack.apache.org > > Subject: Re: JIRA - PLEASE READ > > > > If it isn't being treated as a product it will be very impossible to > > market it as enterprise ready. > > > > I know we all know this. > > > > Similar sized projects under the Apache banner must have the same > > issue, what is the best way to gather experience of these projects? > > See how they handle these growing pains. > > > > A cloudstack foundation entity funded by companies earning from > > cloudstack seems a good way forward. > > > > Another tuppence, this is getting expensive. > > > > > > > > > On 29 Jun 2017, at 18:18, Ron Wheeler > > > > > wrote: > > > > > > I understand that it is a volunteer organization. > > > I do not know how many (if any) of the committers and PMC members > > > are > > funded by their organizations (allowed or ordered to work on > > Cloudstack during company time) which is often the way that Apache > > projects get staffed. > > > > > > Clearly it is hard to tell someone who is being funded by a company > > > to > > fix a problem or who is working on their own time, to do or not do > > something. > > > > > > On the other hand, the PMC has to build a community culture that is > > good for the project. > > > That means describing a vision, planning and enforcing a roadmap, > > > and > > maintaining a focused project "marketing" effort. > > > > > > There is a lot of extremely talented individuals working on > > > Cloudstack > > and it appears to have a very strong and valuable code-base. > > > > > > To me the key question is about the PMC and the core committers' > > > ability > > to make Cloudstack a "product" that can compete for market share and > > acceptance. > > > > > > Is Cloudstack at a point in its development where it should be > > > treated > > like a product? > > &
RE: JIRA - PLEASE READ
Rafael, I agree. I am not saying move away from Apache.. I am saying setup a "foundation" to handle donations and even development management.. Regards, Marty Godsey Principal Engineer nSource Solutions, LLC -Original Message- From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com] Sent: Thursday, June 29, 2017 3:28 PM To: dev@cloudstack.apache.org Subject: Re: JIRA - PLEASE READ ACS is an Apache project, not a foundation per se; donation goes to Apache. I know that there is some discussion/work to create a way for donating things (not just money) to projects, but I do not know how that is going. I do not think we need to create other foundation and move away from Apache (because that is what this move would look like) But still, I wonder, even if we had a CloudStack foundation, would that make organizations that rely on it to donate/contribute more actively? Is that the real problem? On Thu, Jun 29, 2017 at 3:20 PM, Marty Godsey wrote: > Alex, > > I agree.. The only "good" way that we will get more adoption is to > treat it like an Enterprise product. But that would require investment. > Investment with money, not just time. > > As an example, I use pfSense alot in my projects. If I put in a > pfSense router, I take 2-5% (depends on scope) of the GDM and donate > to the pfSense project. I do this because pfSense makes me a lot of > money and I want it to get better.. The only way it will get better is > by supporting it. And even if I was a coder, "supporting" it with code only > goes so far. > > And as mentioned, we create a CloudStack Foundation that is a 501C > corp so it's a non-profit and tax deductible for people donating. > > So the next question is who would we speak with to get this ball > rolling or even a discussion started? > > Regards, > Marty Godsey > Principal Engineer > nSource Solutions, LLC > > -Original Message- > From: Alex Hitchins [mailto:a...@alexhitchins.com] > Sent: Thursday, June 29, 2017 1:49 PM > To: dev@cloudstack.apache.org > Subject: Re: JIRA - PLEASE READ > > If it isn't being treated as a product it will be very impossible to > market it as enterprise ready. > > I know we all know this. > > Similar sized projects under the Apache banner must have the same > issue, what is the best way to gather experience of these projects? > See how they handle these growing pains. > > A cloudstack foundation entity funded by companies earning from > cloudstack seems a good way forward. > > Another tuppence, this is getting expensive. > > > > > On 29 Jun 2017, at 18:18, Ron Wheeler > > > wrote: > > > > I understand that it is a volunteer organization. > > I do not know how many (if any) of the committers and PMC members > > are > funded by their organizations (allowed or ordered to work on > Cloudstack during company time) which is often the way that Apache > projects get staffed. > > > > Clearly it is hard to tell someone who is being funded by a company > > to > fix a problem or who is working on their own time, to do or not do > something. > > > > On the other hand, the PMC has to build a community culture that is > good for the project. > > That means describing a vision, planning and enforcing a roadmap, > > and > maintaining a focused project "marketing" effort. > > > > There is a lot of extremely talented individuals working on > > Cloudstack > and it appears to have a very strong and valuable code-base. > > > > To me the key question is about the PMC and the core committers' > > ability > to make Cloudstack a "product" that can compete for market share and > acceptance. > > > > Is Cloudstack at a point in its development where it should be > > treated > like a product? > > - sufficient functionality to compete > > - sufficient user base to be a competitor in the market > > - production reliability and stability > > - business model for supporting companies to justify their continued > > support > > > > This may not require more effort but requires different policies and > different activities. > > > > There has to be someone or a PMC that can say "No". > > - This change can not be included in this release because it will > > delay > the release. > > - This change adds an unacceptable level of complexity > > - This bug fix will have to wait for the next release because it is > > too > late to test it and fix the docs. > > - This fix breaks the docs > > - The release can not be made until this doc is updated. > > > > Doe
Re: JIRA - PLEASE READ
ACS is an Apache project, not a foundation per se; donation goes to Apache. I know that there is some discussion/work to create a way for donating things (not just money) to projects, but I do not know how that is going. I do not think we need to create other foundation and move away from Apache (because that is what this move would look like) But still, I wonder, even if we had a CloudStack foundation, would that make organizations that rely on it to donate/contribute more actively? Is that the real problem? On Thu, Jun 29, 2017 at 3:20 PM, Marty Godsey wrote: > Alex, > > I agree.. The only "good" way that we will get more adoption is to treat > it like an Enterprise product. But that would require investment. > Investment with money, not just time. > > As an example, I use pfSense alot in my projects. If I put in a pfSense > router, I take 2-5% (depends on scope) of the GDM and donate to the pfSense > project. I do this because pfSense makes me a lot of money and I want it to > get better.. The only way it will get better is by supporting it. And even > if I was a coder, "supporting" it with code only goes so far. > > And as mentioned, we create a CloudStack Foundation that is a 501C corp so > it's a non-profit and tax deductible for people donating. > > So the next question is who would we speak with to get this ball rolling > or even a discussion started? > > Regards, > Marty Godsey > Principal Engineer > nSource Solutions, LLC > > -Original Message- > From: Alex Hitchins [mailto:a...@alexhitchins.com] > Sent: Thursday, June 29, 2017 1:49 PM > To: dev@cloudstack.apache.org > Subject: Re: JIRA - PLEASE READ > > If it isn't being treated as a product it will be very impossible to > market it as enterprise ready. > > I know we all know this. > > Similar sized projects under the Apache banner must have the same issue, > what is the best way to gather experience of these projects? See how they > handle these growing pains. > > A cloudstack foundation entity funded by companies earning from cloudstack > seems a good way forward. > > Another tuppence, this is getting expensive. > > > > > On 29 Jun 2017, at 18:18, Ron Wheeler > wrote: > > > > I understand that it is a volunteer organization. > > I do not know how many (if any) of the committers and PMC members are > funded by their organizations (allowed or ordered to work on Cloudstack > during company time) which is often the way that Apache projects get > staffed. > > > > Clearly it is hard to tell someone who is being funded by a company to > fix a problem or who is working on their own time, to do or not do > something. > > > > On the other hand, the PMC has to build a community culture that is > good for the project. > > That means describing a vision, planning and enforcing a roadmap, and > maintaining a focused project "marketing" effort. > > > > There is a lot of extremely talented individuals working on Cloudstack > and it appears to have a very strong and valuable code-base. > > > > To me the key question is about the PMC and the core committers' ability > to make Cloudstack a "product" that can compete for market share and > acceptance. > > > > Is Cloudstack at a point in its development where it should be treated > like a product? > > - sufficient functionality to compete > > - sufficient user base to be a competitor in the market > > - production reliability and stability > > - business model for supporting companies to justify their continued > > support > > > > This may not require more effort but requires different policies and > different activities. > > > > There has to be someone or a PMC that can say "No". > > - This change can not be included in this release because it will delay > the release. > > - This change adds an unacceptable level of complexity > > - This bug fix will have to wait for the next release because it is too > late to test it and fix the docs. > > - This fix breaks the docs > > - The release can not be made until this doc is updated. > > > > Does the core group want to make it a competitive product or is it > sufficient for the interested players to continue in its current form? > > > > Ron > > > > > > > >> On 29/06/2017 9:42 AM, Will Stevens wrote: > >> I personally don't know how Jira solves any of this, but assuming it > >> does, fine... > >> > >> The bigger problem which you have raised is that CloudStack has zero > >> funding. So we can't hire a project manager, or a releas
RE: JIRA - PLEASE READ
Alex, I agree.. The only "good" way that we will get more adoption is to treat it like an Enterprise product. But that would require investment. Investment with money, not just time. As an example, I use pfSense alot in my projects. If I put in a pfSense router, I take 2-5% (depends on scope) of the GDM and donate to the pfSense project. I do this because pfSense makes me a lot of money and I want it to get better.. The only way it will get better is by supporting it. And even if I was a coder, "supporting" it with code only goes so far. And as mentioned, we create a CloudStack Foundation that is a 501C corp so it's a non-profit and tax deductible for people donating. So the next question is who would we speak with to get this ball rolling or even a discussion started? Regards, Marty Godsey Principal Engineer nSource Solutions, LLC -Original Message- From: Alex Hitchins [mailto:a...@alexhitchins.com] Sent: Thursday, June 29, 2017 1:49 PM To: dev@cloudstack.apache.org Subject: Re: JIRA - PLEASE READ If it isn't being treated as a product it will be very impossible to market it as enterprise ready. I know we all know this. Similar sized projects under the Apache banner must have the same issue, what is the best way to gather experience of these projects? See how they handle these growing pains. A cloudstack foundation entity funded by companies earning from cloudstack seems a good way forward. Another tuppence, this is getting expensive. > On 29 Jun 2017, at 18:18, Ron Wheeler wrote: > > I understand that it is a volunteer organization. > I do not know how many (if any) of the committers and PMC members are funded > by their organizations (allowed or ordered to work on Cloudstack during > company time) which is often the way that Apache projects get staffed. > > Clearly it is hard to tell someone who is being funded by a company to fix a > problem or who is working on their own time, to do or not do something. > > On the other hand, the PMC has to build a community culture that is good for > the project. > That means describing a vision, planning and enforcing a roadmap, and > maintaining a focused project "marketing" effort. > > There is a lot of extremely talented individuals working on Cloudstack and it > appears to have a very strong and valuable code-base. > > To me the key question is about the PMC and the core committers' ability to > make Cloudstack a "product" that can compete for market share and acceptance. > > Is Cloudstack at a point in its development where it should be treated like a > product? > - sufficient functionality to compete > - sufficient user base to be a competitor in the market > - production reliability and stability > - business model for supporting companies to justify their continued > support > > This may not require more effort but requires different policies and > different activities. > > There has to be someone or a PMC that can say "No". > - This change can not be included in this release because it will delay the > release. > - This change adds an unacceptable level of complexity > - This bug fix will have to wait for the next release because it is too late > to test it and fix the docs. > - This fix breaks the docs > - The release can not be made until this doc is updated. > > Does the core group want to make it a competitive product or is it sufficient > for the interested players to continue in its current form? > > Ron > > > >> On 29/06/2017 9:42 AM, Will Stevens wrote: >> I personally don't know how Jira solves any of this, but assuming it >> does, fine... >> >> The bigger problem which you have raised is that CloudStack has zero >> funding. So we can't hire a project manager, or a release manager or >> someone whose job it is to maintain documentation. I have been trying >> to find a way to, at the very least, fund a full time release manager >> who can focus 100% on the project. As the release manager for 4.9, I >> know it is a full time job. I did my best, but it is a ton of work >> and is hard to stay on top of. >> >> Everyone contributing to CloudStack is donating their time. They >> can't make a living off supporting ACS, so every one is doing their >> best with the little time they can take away from their day job or their >> family life. >> >> Yes, having clear guidelines and sticking to them helps, but without >> a solid CI infrastructure backing the project and improved testing >> and automation, we will always struggles with release schedules and such. >> >> I have been involved in this project long enough to know
Re: JIRA - PLEASE READ
mproves code readability or future extensibility? - does not affect documentation? Apache projects that are popular and enjoy wide support do have strong management. There are other examples where great Apache software is failing to get recognized because the PMC is not paying attention to the product management side of things. I use Apache Jackrabbit which is a quality product with a strong technical team supporting it. It has very little following because the documentation and marketing collateral is very poor. It gets by because the audience for it is largely software developers who can read code and can test features to work out the functionality. It would get a lot more attention if they paid attention to the product management side of the project. Cloudstack needs to avoid this situation and unfortunately this takes effort and some discipline. Ron On 29/06/2017 8:03 AM, Will Stevens wrote: Why are we still using jira instead of the PRs for that communication? Can we not use issues in github now instead of jira if someone needs to open an issue but does not yet have code to contribute. If not, jira could still be used for that. I think duplicating data between jira and the PR is kind of pointless. I feel like the github PRs and the cide going in should be the source of truth, not a random third party tool. For the 4.9 release notes, i built a tool to generate the release notes from the PRs merged in that release. I think that is easier and more accurate than depending on jira since it does not track the actual code tree. Thats my 0.02$. On Jun 29, 2017 5:25 AM, "Paul Angus" wrote: Such a view of CloudStack is what holds CloudStack back. It stops users/operators from having any chance of understanding what CloudStack does and how it does it. Code for code's sake is no use to anyone. Jira is about communication between developers and to everyone else. 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 [mailto:daan.hoogl...@gmail.com] Sent: 29 June 2017 10:14 To: dev Subject: Re: JIRA - PLEASE READ On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus wrote: + Release notes will be impossible to create without a proper Jira history. And no one will know what has gone into CloudStack. No they are not mr Grumpy. they should be base on the code anyway, hence on git, not jira. I do not appose to the use of Jira but it is not required for good coding practices and as we are not and will not function as a corporation, jira is an extra for those that grave for it. not a requirement. -- Daan -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: JIRA - PLEASE READ
>> >>> As a real outsider, IMHO Paul is right. >>> >>> At times it seems that Cloudstack is a coding hobby rather than a project >>> or a production quality product. >>> >>> Who decides what goes into a release? How does this affect the release >>> schedule? >>> Who is responsible for meeting the "published" roadmap (of which there >>> seem to be many) of releases? >>> >>> How is a system admin that is not part of the project supposed to plan for >>> upgrade windows? >>> How does one know when a feature, bug fix or release will be available? >>> >>> How does the PMC manage function creep in a release, maintain quality >>> and consistency, reject changes that hurt the overall vision or add too >>> much complexity? >>> >>> No one seems to care about documentation but if someone did, how would >>> they stop undocumented features or features that contradict the >>> documentation from being incorporated? >>> Who makes sure that the documentation is correct at the time of the >>> release? >>> Release notes are not much help for someone doing a new install or >>> evaluating Cloudstack. >>> >>> Without a JIRA entry, how does an end-user who encounters a problem know >>> that it has been fixed already in the next release? >>> >>> Without a JIRA entry, how does the community comment on a proposed change >>> before it gets coded? >>> >>> If changes are going to be accepted without a JIRA, is there a definition >>> of a minor fix that does not require a JIRA? >>> - does not change functionality? >>> - only affects an "edge case" or cleans up an exception that is not >>> properly handled? >>> - only improves code readability or future extensibility? >>> - does not affect documentation? >>> >>> Apache projects that are popular and enjoy wide support do have strong >>> management. >>> >>> There are other examples where great Apache software is failing to get >>> recognized because the PMC is not paying attention to the product >>> management side of things. >>> I use Apache Jackrabbit which is a quality product with a strong technical >>> team supporting it. >>> It has very little following because the documentation and marketing >>> collateral is very poor. >>> It gets by because the audience for it is largely software developers who >>> can read code and can test features to work out the functionality. >>> It would get a lot more attention if they paid attention to the product >>> management side of the project. >>> >>> Cloudstack needs to avoid this situation and unfortunately this takes >>> effort and some discipline. >>> >>> >>> Ron >>> >>> >>> >>> >>> >>>> On 29/06/2017 8:03 AM, Will Stevens wrote: >>>> >>>> Why are we still using jira instead of the PRs for that communication? Can >>>> we not use issues in github now instead of jira if someone needs to open >>>> an >>>> issue but does not yet have code to contribute. If not, jira could still >>>> be >>>> used for that. >>>> >>>> I think duplicating data between jira and the PR is kind of pointless. I >>>> feel like the github PRs and the cide going in should be the source of >>>> truth, not a random third party tool. >>>> >>>> For the 4.9 release notes, i built a tool to generate the release notes >>>> from the PRs merged in that release. I think that is easier and more >>>> accurate than depending on jira since it does not track the actual code >>>> tree. >>>> >>>> Thats my 0.02$. >>>> >>>> On Jun 29, 2017 5:25 AM, "Paul Angus" wrote: >>>> >>>> Such a view of CloudStack is what holds CloudStack back. >>>> It stops users/operators from having any chance of understanding what >>>> CloudStack does and how it does it. >>>> Code for code's sake is no use to anyone. >>>> Jira is about communication between developers and to everyone else. >>>> >>>> >>>> >>>> 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 [mailto:daan.hoogl...@gmail.com] >>>> Sent: 29 June 2017 10:14 >>>> To: dev >>>> Subject: Re: JIRA - PLEASE READ >>>> >>>> On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus >>>> wrote: >>>> >>>>> + Release notes will be impossible to create without a proper Jira >>>>> >>>> history. >>>> >>>>> And no one will know what has gone into CloudStack. >>>>> >>>> No they are not mr Grumpy. they should be base on the code anyway, hence >>>> on >>>> git, not jira. I do not appose to the use of Jira but it is not required >>>> for good coding practices and as we are not and will not function as a >>>> corporation, jira is an extra for those that grave for it. not a >>>> requirement. >>>> >>>> -- >>>> Daan >>>> >>>> >>> -- >>> Ron Wheeler >>> President >>> Artifact Software Inc >>> email: rwhee...@artifact-software.com >>> skype: ronaldmwheeler >>> phone: 866-970-2435, ext 102 >>> >>> > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 >
Re: JIRA - PLEASE READ
ed already in the next release? Without a JIRA entry, how does the community comment on a proposed change before it gets coded? If changes are going to be accepted without a JIRA, is there a definition of a minor fix that does not require a JIRA? - does not change functionality? - only affects an "edge case" or cleans up an exception that is not properly handled? - only improves code readability or future extensibility? - does not affect documentation? Apache projects that are popular and enjoy wide support do have strong management. There are other examples where great Apache software is failing to get recognized because the PMC is not paying attention to the product management side of things. I use Apache Jackrabbit which is a quality product with a strong technical team supporting it. It has very little following because the documentation and marketing collateral is very poor. It gets by because the audience for it is largely software developers who can read code and can test features to work out the functionality. It would get a lot more attention if they paid attention to the product management side of the project. Cloudstack needs to avoid this situation and unfortunately this takes effort and some discipline. Ron On 29/06/2017 8:03 AM, Will Stevens wrote: Why are we still using jira instead of the PRs for that communication? Can we not use issues in github now instead of jira if someone needs to open an issue but does not yet have code to contribute. If not, jira could still be used for that. I think duplicating data between jira and the PR is kind of pointless. I feel like the github PRs and the cide going in should be the source of truth, not a random third party tool. For the 4.9 release notes, i built a tool to generate the release notes from the PRs merged in that release. I think that is easier and more accurate than depending on jira since it does not track the actual code tree. Thats my 0.02$. On Jun 29, 2017 5:25 AM, "Paul Angus" wrote: Such a view of CloudStack is what holds CloudStack back. It stops users/operators from having any chance of understanding what CloudStack does and how it does it. Code for code's sake is no use to anyone. Jira is about communication between developers and to everyone else. 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 [mailto:daan.hoogl...@gmail.com] Sent: 29 June 2017 10:14 To: dev Subject: Re: JIRA - PLEASE READ On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus wrote: + Release notes will be impossible to create without a proper Jira history. And no one will know what has gone into CloudStack. No they are not mr Grumpy. they should be base on the code anyway, hence on git, not jira. I do not appose to the use of Jira but it is not required for good coding practices and as we are not and will not function as a corporation, jira is an extra for those that grave for it. not a requirement. -- Daan -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
RE: JIRA - PLEASE READ
Hello guys.. I do work for a company in Silicon Valley. The company also uses a free project to build its commercial project to make money. This project, like ACS, has no funding. The project is FreeNAS. However, IXSystems, the company, uses FreeNAS to build a "supported, commercial version" called TrueNAS with which they sale to make money. :) In turn, IXSystems actual provides a full time PM and developers to the project. It’s a small cost to pay for a product that makes them a lot of money. So I guess where I am getting is at the CCC I had the pleasure to meet some very good people and many large companies that make a lot of money from using ACS. I know right now, comparable speaking, I am small potatoes. But some of these people I meet seemed to be pretty sizable. Have or has any of these companies thought of hiring an FTE that is committed to making the product that they use better and chalking it up as contribution? Or even jointly hiring an FTE with another company. Now I am not sure what bureaucratic BS will come with Cloudstack being in the Apache Foundation. I don’t know if what I am saying is possible or if we could even create a Cloudsatck Foundation that handles the development side of Cloudstack.. I don’t know. I also am not saying that the people on this mailing list are not already contributing time AND money to the project.. I don’t know.. I am just making my opinion from the outside looking in. I am just making a comparison to another very successful OSS project that does employee full time people to help the project grow and does so without any "public" fundraisers. So am I on the right track? Has this already been discussed and dismissed? If so what were the reasons? I am more than willing to donate to the ACS project. I am not In a position to hire a FTE for it since I am the small minnow here in a large pod but I will help all I can. Regards, Marty Godsey Principal Engineer nSource Solutions, LLC -Original Message- From: Will Stevens [mailto:williamstev...@gmail.com] Sent: Thursday, June 29, 2017 9:42 AM To: Ron Wheeler ; dev@cloudstack.apache.org Subject: Re: JIRA - PLEASE READ I personally don't know how Jira solves any of this, but assuming it does, fine... The bigger problem which you have raised is that CloudStack has zero funding. So we can't hire a project manager, or a release manager or someone whose job it is to maintain documentation. I have been trying to find a way to, at the very least, fund a full time release manager who can focus 100% on the project. As the release manager for 4.9, I know it is a full time job. I did my best, but it is a ton of work and is hard to stay on top of. Everyone contributing to CloudStack is donating their time. They can't make a living off supporting ACS, so every one is doing their best with the little time they can take away from their day job or their family life. Yes, having clear guidelines and sticking to them helps, but without a solid CI infrastructure backing the project and improved testing and automation, we will always struggles with release schedules and such. I have been involved in this project long enough to know that all the problems you point out exist, but they are also not easily solved. Obviously we have to work with the initiatives we have and take small steps towards improvement, but we also have to be realistic with our expectations because we are counting on people's generosity to move them forward. Simplifying moving parts and streamlining the process will lead to more contribution because there is less barriers to entry. This one reason why I struggle to see the value in Jira as it is used today. I personally don't understand what value it is giving us that the github PRs and Issues don't solve. I will remain open minded and will follow along with what people think is best, but I think it is worth understanding what we are trying to solve for and simplify our approach in solving it so we can get better systems in place. On Jun 29, 2017 9:17 AM, "Ron Wheeler" wrote: > As a real outsider, IMHO Paul is right. > > At times it seems that Cloudstack is a coding hobby rather than a > project or a production quality product. > > Who decides what goes into a release? How does this affect the release > schedule? > Who is responsible for meeting the "published" roadmap (of which there > seem to be many) of releases? > > How is a system admin that is not part of the project supposed to plan > for upgrade windows? > How does one know when a feature, bug fix or release will be available? > > How does the PMC manage function creep in a release, maintain > quality and consistency, reject changes that hurt the overall vision > or add too much complexity? > > No one seems to care about documentation but if someone did, how woul
Re: JIRA - PLEASE READ
icating data between jira and the PR is kind of pointless. I >> feel like the github PRs and the cide going in should be the source of >> truth, not a random third party tool. >> >> For the 4.9 release notes, i built a tool to generate the release notes >> from the PRs merged in that release. I think that is easier and more >> accurate than depending on jira since it does not track the actual code >> tree. >> >> Thats my 0.02$. >> >> On Jun 29, 2017 5:25 AM, "Paul Angus" wrote: >> >> Such a view of CloudStack is what holds CloudStack back. >> It stops users/operators from having any chance of understanding what >> CloudStack does and how it does it. >> Code for code's sake is no use to anyone. >> Jira is about communication between developers and to everyone else. >> >> >> >> 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 [mailto:daan.hoogl...@gmail.com] >> Sent: 29 June 2017 10:14 >> To: dev >> Subject: Re: JIRA - PLEASE READ >> >> On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus >> wrote: >> >>> + Release notes will be impossible to create without a proper Jira >>> >> history. >> >>> And no one will know what has gone into CloudStack. >>> >> >> No they are not mr Grumpy. they should be base on the code anyway, hence >> on >> git, not jira. I do not appose to the use of Jira but it is not required >> for good coding practices and as we are not and will not function as a >> corporation, jira is an extra for those that grave for it. not a >> requirement. >> >> -- >> Daan >> >> > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
Re: JIRA - PLEASE READ
As a real outsider, IMHO Paul is right. At times it seems that Cloudstack is a coding hobby rather than a project or a production quality product. Who decides what goes into a release? How does this affect the release schedule? Who is responsible for meeting the "published" roadmap (of which there seem to be many) of releases? How is a system admin that is not part of the project supposed to plan for upgrade windows? How does one know when a feature, bug fix or release will be available? How does the PMC manage function creep in a release, maintain quality and consistency, reject changes that hurt the overall vision or add too much complexity? No one seems to care about documentation but if someone did, how would they stop undocumented features or features that contradict the documentation from being incorporated? Who makes sure that the documentation is correct at the time of the release? Release notes are not much help for someone doing a new install or evaluating Cloudstack. Without a JIRA entry, how does an end-user who encounters a problem know that it has been fixed already in the next release? Without a JIRA entry, how does the community comment on a proposed change before it gets coded? If changes are going to be accepted without a JIRA, is there a definition of a minor fix that does not require a JIRA? - does not change functionality? - only affects an "edge case" or cleans up an exception that is not properly handled? - only improves code readability or future extensibility? - does not affect documentation? Apache projects that are popular and enjoy wide support do have strong management. There are other examples where great Apache software is failing to get recognized because the PMC is not paying attention to the product management side of things. I use Apache Jackrabbit which is a quality product with a strong technical team supporting it. It has very little following because the documentation and marketing collateral is very poor. It gets by because the audience for it is largely software developers who can read code and can test features to work out the functionality. It would get a lot more attention if they paid attention to the product management side of the project. Cloudstack needs to avoid this situation and unfortunately this takes effort and some discipline. Ron On 29/06/2017 8:03 AM, Will Stevens wrote: Why are we still using jira instead of the PRs for that communication? Can we not use issues in github now instead of jira if someone needs to open an issue but does not yet have code to contribute. If not, jira could still be used for that. I think duplicating data between jira and the PR is kind of pointless. I feel like the github PRs and the cide going in should be the source of truth, not a random third party tool. For the 4.9 release notes, i built a tool to generate the release notes from the PRs merged in that release. I think that is easier and more accurate than depending on jira since it does not track the actual code tree. Thats my 0.02$. On Jun 29, 2017 5:25 AM, "Paul Angus" wrote: Such a view of CloudStack is what holds CloudStack back. It stops users/operators from having any chance of understanding what CloudStack does and how it does it. Code for code's sake is no use to anyone. Jira is about communication between developers and to everyone else. 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 [mailto:daan.hoogl...@gmail.com] Sent: 29 June 2017 10:14 To: dev Subject: Re: JIRA - PLEASE READ On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus wrote: + Release notes will be impossible to create without a proper Jira history. And no one will know what has gone into CloudStack. No they are not mr Grumpy. they should be base on the code anyway, hence on git, not jira. I do not appose to the use of Jira but it is not required for good coding practices and as we are not and will not function as a corporation, jira is an extra for those that grave for it. not a requirement. -- Daan -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: JIRA - PLEASE READ
Agreed Alex On Jun 29, 2017 5:34 AM, "Alex Hitchins" wrote: > I've saved up enough to chip a tuppence worth of comment in. > > In any other project, you would have a project manager, someone at the > coalface ensuring there is a perfect harmony behind the chaos that is > software development. > > From the sidelines, it looks like Cloudstack really needs some project > management love and attention. > > Comment over, as you were. > > > > > On 29 Jun 2017, at 10:24, Paul Angus wrote: > > > > Such a view of CloudStack is what holds CloudStack back. > > It stops users/operators from having any chance of understanding what > CloudStack does and how it does it. > > Code for code's sake is no use to anyone. > > Jira is about communication between developers and to everyone else. > > > > > > > > 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 [mailto:daan.hoogl...@gmail.com] > > Sent: 29 June 2017 10:14 > > To: dev > > Subject: Re: JIRA - PLEASE READ > > > >> On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus > wrote: > >> + Release notes will be impossible to create without a proper Jira > history. > >> And no one will know what has gone into CloudStack. > > > > > > No they are not mr Grumpy. they should be base on the code anyway, hence > on git, not jira. I do not appose to the use of Jira but it is not required > for good coding practices and as we are not and will not function as a > corporation, jira is an extra for those that grave for it. not a > requirement. > > > > -- > > Daan > >
RE: JIRA - PLEASE READ
Why are we still using jira instead of the PRs for that communication? Can we not use issues in github now instead of jira if someone needs to open an issue but does not yet have code to contribute. If not, jira could still be used for that. I think duplicating data between jira and the PR is kind of pointless. I feel like the github PRs and the cide going in should be the source of truth, not a random third party tool. For the 4.9 release notes, i built a tool to generate the release notes from the PRs merged in that release. I think that is easier and more accurate than depending on jira since it does not track the actual code tree. Thats my 0.02$. On Jun 29, 2017 5:25 AM, "Paul Angus" wrote: Such a view of CloudStack is what holds CloudStack back. It stops users/operators from having any chance of understanding what CloudStack does and how it does it. Code for code's sake is no use to anyone. Jira is about communication between developers and to everyone else. 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 [mailto:daan.hoogl...@gmail.com] Sent: 29 June 2017 10:14 To: dev Subject: Re: JIRA - PLEASE READ On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus wrote: > + Release notes will be impossible to create without a proper Jira history. > And no one will know what has gone into CloudStack. No they are not mr Grumpy. they should be base on the code anyway, hence on git, not jira. I do not appose to the use of Jira but it is not required for good coding practices and as we are not and will not function as a corporation, jira is an extra for those that grave for it. not a requirement. -- Daan
Re: JIRA - PLEASE READ
Hi Paul On 06/29/2017 11:06 AM, Paul Angus wrote: > Hi, Mr Grumpy here! > > I was looking the commits and I'm seeing commits going in with no Jira Issue > assigned. > My understanding is that there must be a Jira ticket for EVERY > fix/enhancement/feature, so that we have a way to search and track these > things. > + Release notes will be impossible to create without a proper Jira history. > And no one will know what has gone into CloudStack. > > I know rules and procedures are a PITA, but we can't let this turn into the > wild west! I would say it depends (swiss neutral mindset) :). Sometimes you'd like to have a full description (high level view) of what changes are related to which commits. Sometimes it would be overkill to open a jira ticket for every smaller enhancement. E.g. https://github.com/apache/cloudstack/commit/d53dd0a671e635edcefcae332e1b7d428ac7600b e.g. imho there is no value in a jira ticket for this change. However, I agree that for everything "changelog" relevant, I would like to have a jira ticket for. René
Re: JIRA - PLEASE READ
I've saved up enough to chip a tuppence worth of comment in. In any other project, you would have a project manager, someone at the coalface ensuring there is a perfect harmony behind the chaos that is software development. From the sidelines, it looks like Cloudstack really needs some project management love and attention. Comment over, as you were. > On 29 Jun 2017, at 10:24, Paul Angus wrote: > > Such a view of CloudStack is what holds CloudStack back. > It stops users/operators from having any chance of understanding what > CloudStack does and how it does it. > Code for code's sake is no use to anyone. > Jira is about communication between developers and to everyone else. > > > > 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 [mailto:daan.hoogl...@gmail.com] > Sent: 29 June 2017 10:14 > To: dev > Subject: Re: JIRA - PLEASE READ > >> On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus >> wrote: >> + Release notes will be impossible to create without a proper Jira history. >> And no one will know what has gone into CloudStack. > > > No they are not mr Grumpy. they should be base on the code anyway, hence on > git, not jira. I do not appose to the use of Jira but it is not required for > good coding practices and as we are not and will not function as a > corporation, jira is an extra for those that grave for it. not a requirement. > > -- > Daan
RE: JIRA - PLEASE READ
Such a view of CloudStack is what holds CloudStack back. It stops users/operators from having any chance of understanding what CloudStack does and how it does it. Code for code's sake is no use to anyone. Jira is about communication between developers and to everyone else. 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 [mailto:daan.hoogl...@gmail.com] Sent: 29 June 2017 10:14 To: dev Subject: Re: JIRA - PLEASE READ On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus wrote: > + Release notes will be impossible to create without a proper Jira history. > And no one will know what has gone into CloudStack. No they are not mr Grumpy. they should be base on the code anyway, hence on git, not jira. I do not appose to the use of Jira but it is not required for good coding practices and as we are not and will not function as a corporation, jira is an extra for those that grave for it. not a requirement. -- Daan
Re: JIRA - PLEASE READ
On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus wrote: > + Release notes will be impossible to create without a proper Jira history. > And no one will know what has gone into CloudStack. No they are not mr Grumpy. they should be base on the code anyway, hence on git, not jira. I do not appose to the use of Jira but it is not required for good coding practices and as we are not and will not function as a corporation, jira is an extra for those that grave for it. not a requirement. -- Daan
