cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
Date Wed, 14 Mar 2018 10:05:04 GMT
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.hoogland@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.stoyanov@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.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
>> >>>
>> >>
>>
>>
>
>
> --
> Daan
>



-- 
Daan

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