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 13:50:43 GMT
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/cloudstack/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/articles/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

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