cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <williamstev...@gmail.com>
Subject Re: JIRA - PLEASE READ
Date Fri, 30 Jun 2017 15:06:58 GMT
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" <rwheeler@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" <alex@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: alex@alexhitchins.com
>> W: alexhitchins.com
>> M: 07788 423 969
>> T: 01892 523 587
>>
>> -----Original Message-----
>> From: Rafael Weingärtner [mailto:rafaelweingartner@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 <marty@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:rafaelweingartner@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 <marty@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:alex@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
>>>>> <rwheeler@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"
>>>>>> <rwheeler@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.angus@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.angus@shapeblue.com
>>>>>>>> www.shapeblue.com
>>>>>>>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Daan Hoogland [mailto:daan.hoogland@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.angus@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: rwheeler@artifact-software.com
>>>>>>> skype: ronaldmwheeler
>>>>>>> phone: 866-970-2435, ext 102
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>> Ron Wheeler
>>>>> President
>>>>> Artifact Software Inc
>>>>> email: rwheeler@artifact-software.com
>>>>> skype: ronaldmwheeler
>>>>> phone: 866-970-2435, ext 102
>>>>>
>>>>>
>>>>
>>> --
>>> Rafael Weingärtner
>>>
>>>
>>
>> --
>> Rafael Weingärtner
>>
>>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message