cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Boris Stoyanov <boris.stoya...@shapeblue.com>
Subject Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
Date Wed, 14 Mar 2018 08:48:58 GMT
Hi all, 

I do understand your point as developers if you want to fix something just open the PR and
not deal with any extra details like JIRA tickets and etc, but I must say that JIRA tickets
are quite often looked up from users as they experience an issue. Let’s say we’ve fixed
an annoying UI 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.

Tracking every change with such tool is proven good practice in SDLC, it brings visibility
and it’s a tool meant to be used not only from developers, but from everyone involved in
the project.

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. Also I don’t think it’s
causing big overhead, since it’s being updated mostly automatically. 

Boris Stoyanov 


boris.stoyanov@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

> On 13 Mar 2018, at 17:01, Khosrow Moossavi <kmoossavi@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 <sahmed@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 <
>> rafaelweingartner@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 <
>>> rafaelweingartner@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.hoogland@gmail.com
>>>> 
>>>> wrote:
>>>> 
>>>>> right, also when an issue is created?
>>>>> 
>>>>> 
>>>>> On Tue, Mar 13, 2018 at 2:50 PM, Rafael Weingärtner <
>>>>> rafaelweingartner@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.hoogland@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 <
>>>>>>> rafaelweingartner@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 <
>>>>>> marco@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.hoogland@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
<
>>>>>>>>>> rafaelweingartner@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
<
>>>>>>> wstevens@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
<
>>>>>>>>>>>> rafaelweingartner@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
>> <
>>>>>>>>>>> marco@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.yadav@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.yadav@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
>>> 
>> 

Mime
View raw message