cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Weingärtner <rafaelweingart...@gmail.com>
Subject Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
Date Tue, 13 Mar 2018 14:03:20 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message