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" <rwhee...@artifact-software.com> 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" <a...@alexhitchins.com> 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 me....I think we need something >> else. >> >> On Thu, Jun 29, 2017 at 3:35 PM, Marty Godsey <ma...@gonsource.com> >> 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 <ma...@gonsource.com> >>> 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 >>>>> <rwhee...@artifact-software.com> >>>>> >>>> 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 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" >>>>>> <rwhee...@artifact-software.com> >>>>>> 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 >>>>>>> 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" >>>>>>>> <paul.an...@shapeblue.com> >>>>>>>> >>>>>>> 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 <dev@cloudstack.apache.org> >>>>>>>> Subject: Re: JIRA - PLEASE READ >>>>>>>> >>>>>>>> On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus >>>>>>>> <paul.an...@shapeblue.com> >>>>>>>> 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 >>>>> >>>>> >>>> >>> -- >>> Rafael Weingärtner >>> >>> >> >> -- >> Rafael Weingärtner >> >> > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
