Oh boy! Where to start....

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

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



Kind regards,

Paul Angus

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


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

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

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

> Boris, I hate to be strongly opinionated but I have to violently 
> disagree with you on some things here;
>
> On Wed, Mar 14, 2018 at 9:48 AM, Boris Stoyanov < 
> boris.stoya...@shapeblue.com> wrote:
>
>> Hi all,
>>
>> I do understand your point as developers if you want to fix something 
>> just open the PR and not deal with any extra details like JIRA 
>> tickets and etc, but I must say that JIRA tickets are quite often 
>> looked up from users as they experience an issue.
>
> ​It is not more or less effort for users to look up github PRs than 
> Jira tickets. They still need to be clever about search terms and 
> still might miss out.
> ​
>
>
>> Let’s say we’ve fixed an annoying UI bug in master and there’s no 
>> ticket for it in JIRA. As a user, if you try to search for this 
>> particular issue where would you go? In JIRA or GitHub? How would you 
>> know which release to pickup if you’re just an infrastructure guy and not 
>> following Github.
>>
> ​What is following here and why not Github but Jira.​ ​
>
>
>>
>> Tracking every change with such tool is proven good practice in SDLC,
>
> ​No it is not. Absolutely not. That is what we have revision control
> systems for. Your good practice is only true for enterprise controlled
> projects. In cloudstack there are a lot of wild forks because this
> enterprisy way of controlling change has pushed people away from
> mainstream. This is a force to be reckoned with and we can not completely
> ban it, but we have to minimise it if we want to survive as project.
> ​
>
>
>> it brings visibility and it’s a tool meant to be used not only from
>> developers, but from everyone involved in the project.
>>
> ​How is this true for Jira anywhere near as much as it is true for github?​
>
>
>
>>
>> I also got the feeling that lacking a JIRA ticket could become a common
>> practice in community submission and it’s yet another reason for me to be
>> -1 on this.
>
> ​Another reason to be very much +1 on it. That is a good thing. Think
> about it. People submistting features and bugfixes instead of asking for
> them in a ticket. That is great.
> ​
>
>
>> Also I don’t think it’s causing big overhead, since it’s being updated
>> mostly automatically.
>>
> ​No it is not. What is done automatically? put in progress?? closing?
> undertest status? Only noise is added to those tickets automatically.
> ​
>
>
>>
>> Boris Stoyanov
>>
>>
>> boris.stoya...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>>
>> > On 13 Mar 2018, at 17:01, Khosrow Moossavi <kmooss...@cloudops.com>
>> wrote:
>> >
>> > I'm completely +1 on using GH as source of truth, both PR and issue
>> wise,
>> > with Daan comment regarding Apache rules in mind.
>> > At least it doesn't need to have "yet another" integration to do
>> automated
>> > actions on an issue (such as auto close an issue by "Fixes NUMBER",
>> > "Closes NUMBER") directly from commit or PR body.
>> >
>> > Khosrow Moossavi
>> > CloudOps
>> >
>> > On Tue, Mar 13, 2018 at 10:11 AM, Syed Ahmed <sah...@cloudops.com>
>> wrote:
>> >
>> >> I agree with the relaxation as Rohit pointed out. At this point we
>> should
>> >> ask if Jira is really needed. Most people here I believe agree that it
>> is
>> >> not. The only reason we have Jira is to track releases. This could
>> easily
>> >> be replicated in GitHub as I see that GitHub is the place where we all
>> >> collaborate. I would be completely in if we use GitHub issues and like
>> it
>> >> with Jira as we do with our PRs.
>> >>
>> >>
>> >> On Tue, Mar 13, 2018 at 10:03 AM Rafael Weingärtner <
>> >> rafaelweingart...@gmail.com> wrote:
>> >>
>> >>> I was checking and for some reason ACS does not have an issue tab (
>> >>> https://github.com/apache/cloudstack/issues). It might be some
>> >>> configuration in the repository.
>> >>>
>> >>> On Tue, Mar 13, 2018 at 10:54 AM, Rafael Weingärtner <
>> >>> rafaelweingart...@gmail.com> wrote:
>> >>>
>> >>>> What do you mean by issue? PR or issue (Github issue)?
>> >>>>
>> >>>> On Tue, Mar 13, 2018 at 10:53 AM, Daan Hoogland <
>> >> daan.hoogl...@gmail.com
>> >>>>
>> >>>> wrote:
>> >>>>
>> >>>>> right, also when an issue is created?
>> >>>>>
>> >>>>>
>> >>>>> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
>> >>>>> rafaelweingart...@gmail.com> wrote:
>> >>>>>
>> >>>>>> We already have. All messages on ACS' GH go to commits@c.a.o
>> >>>>>>
>> >>>>>> On Tue, Mar 13, 2018 at 10:49 AM, Daan Hoogland <
>> >>>>> daan.hoogl...@gmail.com>
>> >>>>>> wrote:
>> >>>>>>
>> >>>>>>> Ok, one issue there is Apache foundation rules. If we copy every
>> >>> thing
>> >>>>>> into
>> >>>>>>> jira or the mail list we are fine, where ever we have our
>> >>> discussions.
>> >>>>>> The
>> >>>>>>> only thing is that we need a Apache hosted record. (as in not
>> >>> github)
>> >>>>>>>
>> >>>>>>> On Tue, Mar 13, 2018 at 2:09 PM, Rafael Weingärtner <
>> >>>>>>> rafaelweingart...@gmail.com> wrote:
>> >>>>>>>
>> >>>>>>>> I prefer the workflow in Github as you guy, but to be fair with
>> >>> Jira
>> >>>>>>> ticket
>> >>>>>>>> system I mentioned it.
>> >>>>>>>>
>> >>>>>>>> @Marc, yes Jira can facilitate a lot the management. However, we
>> >>> do
>> >>>>> not
>> >>>>>>> use
>> >>>>>>>> it fully. In our workflow, there is no planning/roadmap for the
>> >>> next
>> >>>>>>>> release per se. Things seem to work in an ad-hoc fashion. On the
>> >>>>> other
>> >>>>>>>> hand, when you need to break down milestones into
>> >>>>> issues/tickets/tasks
>> >>>>>>> and
>> >>>>>>>> then divide them into sprints, and manage a team of developers,
>> >>> the
>> >>>>>>>> oversight provided by Jira system is very good; specially, when
>> >>>>> issues
>> >>>>>>>> start to take more than a single sprint to finish.
>> >>>>>>>>
>> >>>>>>>> On Tue, Mar 13, 2018 at 9:44 AM, Marc-Aurèle Brothier <
>> >>>>>> ma...@exoscale.ch
>> >>>>>>>>
>> >>>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>>> @rafael, you said: they all required Jira tickets to track the
>> >>>>>>> discussion
>> >>>>>>>>> and facilitate the management
>> >>>>>>>>>
>> >>>>>>>>> I can see the discussion happening in the PR on github, but
>> >> the
>> >>>>> Jira
>> >>>>>>>> ticket
>> >>>>>>>>> by itself doesn't do much, except copy/pasting the github
>> >>>>> discussion.
>> >>>>>>>> Then
>> >>>>>>>>> it's down to "facilitate the management", which I only see as
>> >>>>> listing
>> >>>>>>> the
>> >>>>>>>>> changes for a release as far as I know. But this can be
>> >> achieved
>> >>>>> on
>> >>>>>>>> github
>> >>>>>>>>> too.
>> >>>>>>>>>
>> >>>>>>>>> As Daan mentioned, there are those things that are not code
>> >>>>> related
>> >>>>>>> which
>> >>>>>>>>> should have a way of tracking. But what's the difference in
>> >>>>> tracking
>> >>>>>>> them
>> >>>>>>>>> as a Jira issue vs a Github issue (they can't be a PR)? Those
>> >>> are
>> >>>>>> point
>> >>>>>>>> of
>> >>>>>>>>> view exchanges with messages & links, with a final status,
>> >> most
>> >>> of
>> >>>>>> the
>> >>>>>>>> time
>> >>>>>>>>> without a strong link to a release number. If they do, they
>> >> can
>> >>> be
>> >>>>>>> added
>> >>>>>>>> to
>> >>>>>>>>> a milestone.
>> >>>>>>>>>
>> >>>>>>>>> So far I don't see how things done with Jira cannot be
>> >> achieved
>> >>> on
>> >>>>>>>> Github.
>> >>>>>>>>> It's just a matter of changing habits to simplify the workflow
>> >>> for
>> >>>>>> new
>> >>>>>>>>> comers (and old joiners too ;-) ).
>> >>>>>>>>>
>> >>>>>>>>> On Tue, Mar 13, 2018 at 1:02 PM, Daan Hoogland <
>> >>>>>>> daan.hoogl...@gmail.com>
>> >>>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Will, you are speaking my mind; any external registration
>> >> tool
>> >>>>>> should
>> >>>>>>>> be
>> >>>>>>>>>> based on the source. The only reason for having an external
>> >>> tool
>> >>>>>>>> without
>> >>>>>>>>>> relation to the code is to keep track of what is *not* (or
>> >> not
>> >>>>>> fully)
>> >>>>>>>>>> implemented.
>> >>>>>>>>>>
>> >>>>>>>>>> On Tue, Mar 13, 2018 at 12:58 PM, Rafael Weingärtner <
>> >>>>>>>>>> rafaelweingart...@gmail.com> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> I meant a way of describing them (changes/proposals)
>> >>> further.
>> >>>>>>>> Sometimes
>> >>>>>>>>>> we
>> >>>>>>>>>>> have commits only with title, and then the Jira ticket
>> >> would
>> >>>>> be a
>> >>>>>>> way
>> >>>>>>>>> of
>> >>>>>>>>>>> documenting that commit. I do prefer the idea of inserting
>> >>> the
>> >>>>>>> whole
>> >>>>>>>>>>> description in the commit body though. [for me] it looks
>> >>>>> easier
>> >>>>>> to
>> >>>>>>>> work
>> >>>>>>>>>>> directly with commits and PRs; as you said, we can
>> >> generate
>> >>>>>> release
>> >>>>>>>>> notes
>> >>>>>>>>>>> based on commits directly [and issues on GH]. However, for
>> >>>>> that,
>> >>>>>> we
>> >>>>>>>>> need
>> >>>>>>>>>> to
>> >>>>>>>>>>> fine-tune our workflow.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Tue, Mar 13, 2018 at 8:40 AM, Will Stevens <
>> >>>>>>> wstev...@cloudops.com
>> >>>>>>>>>
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> I am +1 to relaxing the requirement of Jira ticket.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Rafael, what do you mean when you say "Jira tickets are
>> >>>>> used to
>> >>>>>>>>>> register
>> >>>>>>>>>>>> changes"?
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I think ever since 4.9 the actual PRs included in the
>> >> code
>> >>>>> are
>> >>>>>>> the
>> >>>>>>>>>> source
>> >>>>>>>>>>>> of truth for the changes in the actual code (at least
>> >>> from a
>> >>>>>>>> release
>> >>>>>>>>>>> notes
>> >>>>>>>>>>>> perspective).  This is why the release notes can show
>> >>>>> changes
>> >>>>>>> that
>> >>>>>>>>> only
>> >>>>>>>>>>>> have PRs and no Jira ticket.  At least my release notes
>> >>>>>> generator
>> >>>>>>>> is
>> >>>>>>>>>>> built
>> >>>>>>>>>>>> that way.  I think Rohit has built a similar release
>> >> notes
>> >>>>>>>> generator,
>> >>>>>>>>>> so
>> >>>>>>>>>>> I
>> >>>>>>>>>>>> can't speak to his version...
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> *Will Stevens*
>> >>>>>>>>>>>> Chief Technology Officer
>> >>>>>>>>>>>> c 514.826.0190
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> <https://goo.gl/NYZ8KK>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> On Tue, Mar 13, 2018 at 6:42 AM, Rafael Weingärtner <
>> >>>>>>>>>>>> rafaelweingart...@gmail.com> wrote:
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>> Marc, yes Jira tickets are used to register changes.
>> >>>>> However,
>> >>>>>>>> what
>> >>>>>>>>>>> Rohit
>> >>>>>>>>>>>>> and others (including me) are noticing is that there
>> >> are
>> >>>>>>> certain
>> >>>>>>>>>> types
>> >>>>>>>>>>> of
>> >>>>>>>>>>>>> changes (minor/bureaucracy) that do not require Jira
>> >>>>> tickets.
>> >>>>>>> The
>> >>>>>>>>>> issue
>> >>>>>>>>>>>> is
>> >>>>>>>>>>>>> the wording “change”. What consist of a change that is
>> >>>>> worth
>> >>>>>>>>>> mentioning
>> >>>>>>>>>>>> in
>> >>>>>>>>>>>>> the release notes? Everything we do in a branch is a
>> >>>>> change
>> >>>>>>>>> towards a
>> >>>>>>>>>>>>> release, but not everything is useful for
>> >>>>>>>> operators/administrators
>> >>>>>>>>> to
>> >>>>>>>>>>>> see.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I would say that to fix bugs, introduce new features,
>> >>>>> extend
>> >>>>>>>>> existing
>> >>>>>>>>>>>>> features, introduce a major change in the code such as
>> >>>>> that
>> >>>>>>>>> standard
>> >>>>>>>>>>>> maven
>> >>>>>>>>>>>>> thing that you did, they all required Jira tickets to
>> >>>>> track
>> >>>>>> the
>> >>>>>>>>>>>> discussion
>> >>>>>>>>>>>>> and facilitate the management. On the other side of
>> >> the
>> >>>>>>> spectrum,
>> >>>>>>>>> we
>> >>>>>>>>>>> have
>> >>>>>>>>>>>>> things such as removing dead/unused code, opening a
>> >> new
>> >>>>>> version
>> >>>>>>>>>>> (creating
>> >>>>>>>>>>>>> the upgrade path that we still use for the DB), fix a
>> >>>>>>> description
>> >>>>>>>>> in
>> >>>>>>>>>> an
>> >>>>>>>>>>>> API
>> >>>>>>>>>>>>> method, and so on. Moreover, the excessive use of Jira
>> >>>>>> tickets
>> >>>>>>>>> leads
>> >>>>>>>>>> to
>> >>>>>>>>>>>>> hundreds of Jira tickets that we do not know that
>> >> status
>> >>>>> of.
>> >>>>>> We
>> >>>>>>>>> have
>> >>>>>>>>>>>> quite
>> >>>>>>>>>>>>> a big number of tickets opened that could be closed.
>> >>> This
>> >>>>> has
>> >>>>>>>> been
>> >>>>>>>>>>> worse;
>> >>>>>>>>>>>>> we are improving as time goes by.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I would say that to make this more transparent to
>> >> others
>> >>>>>>>>> (especially
>> >>>>>>>>>>>>> newcomers), we need to discuss it, then write it down
>> >> to
>> >>>>> make
>> >>>>>>> it
>> >>>>>>>>>>>>> transparent the way we are working.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> On Tue, Mar 13, 2018 at 6:59 AM, Marc-Aurèle Brothier
>> >> <
>> >>>>>>>>>>> ma...@exoscale.ch
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> That's a good idea, because people are more and more
>> >>>>> used
>> >>>>>> to
>> >>>>>>>> only
>> >>>>>>>>>>>> create
>> >>>>>>>>>>>>> PR
>> >>>>>>>>>>>>>> on github, and it would be helpful to be more
>> >>>>> explanatory
>> >>>>>> on
>> >>>>>>>> the
>> >>>>>>>>>> way
>> >>>>>>>>>>> we
>> >>>>>>>>>>>>>> work to push changes. I still think we should
>> >>> encourage
>> >>>>> the
>> >>>>>>> use
>> >>>>>>>>> of
>> >>>>>>>>>>> the
>> >>>>>>>>>>>>>> github milestone as Rohit did with the 4.11.0 (
>> >>>>>>>>>>>>>> https://github.com/apache/clou
>> >>>>> dstack/milestone/3?closed=1)
>> >>>>>>> to
>> >>>>>>>>> list
>> >>>>>>>>>>> the
>> >>>>>>>>>>>>>> changes in the release notes with the help of the
>> >>>>> labels to
>> >>>>>>> tag
>> >>>>>>>>> the
>> >>>>>>>>>>> PRs
>> >>>>>>>>>>>>>> instead of relying on the jira ticket (it requires
>> >> to
>> >>>>> have
>> >>>>>>>>> another
>> >>>>>>>>>>>>> login).
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> As far as I can remember, the JIRA tickets are used
>> >> to
>> >>>>> list
>> >>>>>>> the
>> >>>>>>>>>>> changes
>> >>>>>>>>>>>>> of
>> >>>>>>>>>>>>>> a release, but nothing else. Or am I missing
>> >>> something?
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Marc-Aurèle
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Tue, Mar 13, 2018 at 9:57 AM, Rohit Yadav <
>> >>>>>>>>>>>> rohit.ya...@shapeblue.com>
>> >>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> All,
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> To make it easier for people to contribute changes
>> >>> and
>> >>>>>>>>> encourage
>> >>>>>>>>>>>>>>> PR/contributions, should we relax the requirement
>> >>> of a
>> >>>>>> JIRA
>> >>>>>>>>>> ticket
>> >>>>>>>>>>>> for
>> >>>>>>>>>>>>>> pull
>> >>>>>>>>>>>>>>> requests that solve trivial/minor issues such as
>> >> doc
>> >>>>>> bugs,
>> >>>>>>>>> build
>> >>>>>>>>>>>> fixes
>> >>>>>>>>>>>>>> etc?
>> >>>>>>>>>>>>>>> A JIRA ticket may still be necessary for new
>> >>> features
>> >>>>> and
>> >>>>>>>>>>> non-trivial
>> >>>>>>>>>>>>>>> bugfixes or changes.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Another alternative could be to introduce a
>> >>>>>> CONTRIBUTING.md
>> >>>>>>>> [1]
>> >>>>>>>>>>> that
>> >>>>>>>>>>>>>>> explains the list of expected things to
>> >> contributors
>> >>>>> when
>> >>>>>>>> they
>> >>>>>>>>>>> send a
>> >>>>>>>>>>>>> PR
>> >>>>>>>>>>>>>>> (for example, a jira id, links to fs or other
>> >>>>> resources,
>> >>>>>> a
>> >>>>>>>>> short
>> >>>>>>>>>>>>> summary
>> >>>>>>>>>>>>>>> and long description, test results etc).
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Thoughts?
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> [1] https://help.github.com/articl
>> >>>>> es/setting-guidelines-
>> >>>>>>>>>>>>>>> for-repository-contributors/
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> - Rohit
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> <https://cloudstack.apache.org>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> rohit.ya...@shapeblue.com
>> >>>>>>>>>>>>>>> www.shapeblue.com
>> >>>>>>>>>>>>>>> 53 Chandos Place, Covent Garden, London  WC2N
>> >> 4HSUK
>> >>>>>>>>>>>>>>> @shapeblue
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> --
>> >>>>>>>>>>>>> Rafael Weingärtner
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> --
>> >>>>>>>>>>> Rafael Weingärtner
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> --
>> >>>>>>>>>> Daan
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> --
>> >>>>>>>> Rafael Weingärtner
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Daan
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> Rafael Weingärtner
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Daan
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Rafael Weingärtner
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Rafael Weingärtner
>> >>>
>> >>
>>
>>
>
>
> --
> Daan
>



-- 
Daan

Reply via email to